On 3 Oct 2008, at 14:01, Tim Moore wrote: > Working with OSG does require basic knowledge of computer graphics, > OpenGL and > C++, but otherwise it is not mysterious. So if anyone wants to pitch > in, please do.
I'm torn on this front - OpenGL is something I've done lots with, and I've used OSG before, but equally I was hoping not to get sucked into it for FG, since there's other areas that I really want to concentrate on. Equally, it does seem as if a push to get the OSG version in a releasable state would be a Very Good Thing(TM). > Stuart has run into a bug in OSG with respect to Imposters, which > manage the > cached rendering of the individual cloud sprites. It's unclear if > this ever > worked well in OSG. Unfortunately I haven't had the chance to really > look at the > problem. Yeah, his comments about crashes in a (modified) osgimpostor example make me very nervous. I am going to look at the code anyway, and test the osgimpostor issue locally (on Mac) to see if it behaves any differently from GLX. > I think this code is "original." At one point Mark Harris' clouds > were in the > tree, but they proved to be to expensive for the machines of the > day, AIUI; the > current code is a simplification of that. Okay, that's not my recollection of the early history of this code, but it was a long time ago. I've actually grabbed Mark Harris' code as well, just out of curiosity, because my suspicion is that it might be very amenable to a pixel shader implementation, and that the OSG community would be interested in a stand-alone cloudKit. The machines listed in his paper and docs are extremely moderate by today's standards - eg he mentions a P3/geforce2 configuration as being able to run the demo acceptably. Of course that's just the clouds alone I suspect :) > The problem is that our vast scene overwhelms most shadowing > techniques. When I > turned my attention to this subject I decided not to use the "shadow > volumes" > technique used in plib. This is CPU-expensive and has a lot of > special cases > that don't work well. The alternative is shadow maps, and there are > several > implementations in OSG. The only ones that have a chance of working > well are > Parallel Split Shadow Maps (PSSM) and a new addition, View Dependent > Shadow > Maps. The former has always been complicated and buggy. OSG users > are excited > about the latter, which warps the shadow map based on the extents of > the scene, > and I have been working on getting it going with fg. Unfortunately, > very few > (perhaps no) people use these techniques with geocentric databases. > I'm > currently working through a large bug that I believe is related to > that. Okay, just knowing that you're actively working on it is valuable. It does feel like a multi-level approach is going to be necessary regardless, with coarse maps for terrain-self-shadowing, and then a higher-resolution (but limited scale) pass for buildings and vehicles. However, my knowledge of shadowing techniques is out of date (and probably wrong to start with) so I'll stop there. James ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
