Michael Pujos writes: > You're absolutely right and IMHO it should be a long term goal to have a > terrain renderer (in a terrain interface architecture why not) that > supports long viewing distance and very detailed terrain with good > performance at high flying speeds and altitude (for example for military > aircrafts). But I agree it's no easy task at all and the current > renderer works great for 95% of uses.
Just for fun, let's say you wanted to render a scene at high speed with 200 nm visibility. Let's say we have all the LOD terrain issues worked out and we have chosen to drape textures over the top of the terrain (i.e. photo-real satellite imagery type stuff.) area of a circle = pi*r^2 So this means you have 200*200*pi square miles of potentially viewable stuff. That's about 125,000 square miles. That's about 321,689,600,000 square meters. Let's say we are shooting for 1 pixel per meter resolution on our imagery and it takes 3 bytes to represent a pixel in RGB color space. That's about 900Gb of imagery data we'd need to have loaded just to render the scene. You could probably get by with a lot less memory if you use lower mipmap levels out in the distance; well you'd have to unless someone starts marketing a video card with 1Tb of video ram on it, which I don't see on the immediate horizon. That's just to render the static scene. Actually to be fair, you would be insane if you loaded more than the lowest level mipmaps for the distant areas, but now we've racheted up the complexity of our scenery renderer/pager by a couple notches to include all the texture management. Now, let's say you are flying at 600mph and we are cutting a 400mile swath across the world (in terms of visiblity, 200miles each direction.) That means 400*600 = 240,000 square miles of data need to be loaded every hour as you fly. This is about 614400000000 square meters which means 1,843,200,000,000 bytes/hour of pixel data. That's 512,000,000 bytes per second, or about 488Mb of data per second you'd have to load off your drive. Again, you'd get a lot of savings from using the lower level mipmaps. Let's say you got a 32x savings overall by using lower level mipmaps as appropriate. Now you are down to only 15Mb per second you'd have to load off your hard drive and page into memory ... that's 15Mb of HD activity for every second you fly with 200miles visibility at 600mph ground speed. Now, assuming your computer and your IDE drive could keep up with all of that, how much CPU is going to be left for actual flight simulation? Even though you wouldn't load the the highest level mipmaps for the entire visible area, you could potentially fly to any where in that area, so you'd need the highest res data available on your drive. At 1 pixel per meter resolution, you'd need 900Gb just to cover a 200 mile radius area. That's not counting any of the terrain data, only the imagery we are laying on top. Even if I screwed up and missed a decimal someplace, it's still not good news. :-) I guess my point (if I have one) is that when people talk about 200 miles visibility as a design goal, they need to consider what goes into that and how much area/data that area actually contains. If you also add support for high speed flight on top of that, you have to consider how much data is going to need to be paged in as you fly. I'm making a lot of assumptions and picking on CLOD in this example... but the amount of data increases with the square of the radius of visibility so this will catch up quickly with just about any scheme you pick. One idea would be to generate the entire earth in different levels of detail and switch based on altitude. At higher altitudes, all your tiles will likely cover more area and contain less information, so you could make a scheme like that potentially work. However, then you'd have to think about how you might hide the transition from one global LOD to the next ... or maybe just live with a big pop at 10k, 50k, 100k, etc.??? If anyone wants to go away for a while and work on a different terrain modeling and rendering approach, please be my guest. Just do it in a way that doesn't disrupt the current scheme and I'll be happy. :-) Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities [EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
