Christian Stock writes: > I think this is the way to go for CLOD. Once we have CLOD, the triangle > size will depend on distance, so this should be good enough (ie triangle > number will be lower). Maybe when I program CLOD, I add a 3rd > ssgRangeSelector based on quadtrees which should be even better. I suppose > you use frustrum culling before the ssgRangeSelector (no use testing for > distance when the object isn't visible anyway).
Yes, we get that for free from plib's. Every node in the scene graph has a bounding sphere, and plib uses it for fast culling. > Yes, I get quite a big framerate drop on my system (AMD1.4 GF3). Norm Vine sees the same thing. > Not that it makes much of a difference, it's still quite > smooth. Given the low polygon count of the added 3D objects my GF3 > should take virtually no performance hit. That's why I'd assume > it's the range selection causes the drop. Using a quad based > approach, you'd discard most of the trees in one go and only look > for trees in the closer quads... It might also be the fact that the trees are billboarded. As an easy experiment, make a backup copy of $FG_ROOT/materials.xml, then replace every instance of <heading-type>billboard</heading-type> with <heading-type>fixed</heading-type>. Is your framerate better? If so, then we might want to use static polys for trees rather than billboards. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
