Roberto Inzerillo wrote : > I am not shure I did understand what you mean. > > Anyway, I try explaining my point of view and share my opinion. Maybe I am > wrong, maybe I miss something. Please comment it. > > Let's say I fly above an airport. Let's say the airport ground is filled with > a 100 3d objects (I am not exagerating) each one consisting of a .ac file > which includes two versions (high res and low res) of the same object. > > Flying high above the ground I have a wide visual, it means I see a lot of > the underlaying terrain, complete with all of the 100 objects above > mentioned. From that point of view I find useless to let the GPU display all > the details of the buldings because of the distance, hence I let the GPU > render the lowres versions only and its memory does not need to be filled > with all the higres versions (complete with textures). > > As soon as I fly down, I come closer to those buildings, untill a point where > I wish I see more details of some of them (the closer ones), so I let the > .xml 'range' animation display the highres texturized version of those closer > buildings. That will use more memory then the lowres non texturized ones, and > that will need more GPU calculation because of the increased geometry > details. But still I don't see _all_ the 100 buildings at the same distance, > the most will stay out of sight, or at least distant enough not to be > rendered at high quality. So I will accept the low res versions to be shown. > > Loading and unloading a 3d object from the GPU memory will let the GPU > optimize its memory usage and the processor workload. Loading all the objects > into GPU memory at once will fill it quick, and could be a waste in case I > will not fly down untill the point I really need to see all those details. > > E.g. I fly near EDDF airport (which is huge) but don't want to land on it, in > this case I really don't need all of EDDF highres buildings to be loaded into > GPU memory, as long I stay at high altitude. It's enough to me to see a bunch > of lowres buildings which let me perceive their shape from a distance. That > memory could be used for Wiesbaden airport buildings' objects instead, where > I will land after short time. > Of course, those airport buildings could not be OBJECT_SHARED since they are > not shared at all, every airport has its own hangars, terminals, fire > stationa and so on. > > What's your opinion about that? >
That doesn't work like that. All the bits found in a .ac file is loaded in memory, as well as referenced texture files. Then uncompressed bitmap ( for now - S3 Texture compression can/could improve that ) are stored in the GPU memory. Geometry of all objects in the .ac file are compiled into display lists and also stored in GPU memory. This is done at load time. At run-time, the range animation, as well as frustum culling, determines what is displayed ( the low-res geometry, the hi-res geometry or nothing because it is not in the field of view ), or what display list and what textures are sent to the framebuffer after transformations. Only static objects and terrain tiles are removed from memory when the tile manager decide they are beyond the horizon. When doing that, the GPU memory used for model textures and display list are returned to the GPU heap. Shared objects stay in memory, and their textures and display lists are not released until the halt of FG. -Fred -- Frédéric Bouvier http://frfoto.free.fr Photo gallery - album photo http://www.fotolia.fr/p/2278 Other photo gallery http://fgsd.sourceforge.net/ FlightGear Scenery Designer _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
