At 09:48 PM 24/07/2002 -0400, you wrote: >Christian Stock writes: > > > I was following the discussion on the random placed 3D objects. I have > one > > comment after having seen it in action. It seems as if there is a > threshold > > for distance, and if an object is close enough it gets rendered. I don't > > know how it's done in detail, but it seems to be computationally > expensive. > > FS2K2 uses a quadtree and renders whole blocks or not. This approach > should > > be much faster, but then again maybe something similar is done here > already. > >There's a two-level approach: > >1. There is an ssgRangeSelector for every group of objects on every > triangle; for example, all of the trees in one triangle will be > under the same selector, even if the triangle is many kilometers > wide and/or long.
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, I get quite a big framerate drop on my system (AMD1.4 GF3). 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... Anyway, I'm talking about things I don't understand that well because I actually haven't implemented them myself. I should really get going with the CLOD and do some of my own experiments before I voice my opinion here loudly :) Cheers, Christian _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
