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.


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
Flightgear-devel mailing list

Reply via email to