Curtis L. Olson wrote: > One thing we'd need to think about before we got too far down this > path is the texture RAM requirements of such a scheme.
That's a manageable problem. If you think about it, the amount of impostor texture memory required is exactly that required to draw the tiles on the screen -- it's bounded by screen area. Clearly there will be a significant amount of overdraw. But there's no need for a 256x256 texture for an impostor that only subtends 20-30 pixels on the screen. The bigger problem, I suspect, will be main memory (or maybe disk bandwidth). An impostor scheme is going to be really tile hungry -- constantly dragging tiles off of disk, rendering them into textures, and forgetting about them. You're no longer limited by texture memory here, but you're still trying to cram huge datasets into a finite resource. This is the reason I'm still a CLOD bigot at heart -- with really huge datasets like terrain, any LOD scheme really needs to be done top-down (mip-mapped heightfields, for example), rather than bottom up (assembling huge terrains from huge numbers of maximum-LOD tiles). Andy -- Andrew J. Ross NextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
