Re: [Flightgear-devel] Impact of texturing objects on performance?
On Sun, 11 Jun 2006 14:53:13 -0400, Ampere wrote in message <[EMAIL PROTECTED]>: > On Friday 09 June 2006 21:50, Arnt Karlsen wrote: > > ..Roberto _ is_ stretching understatement as concept, last years > > AirVenture put over 10 000 planes on KOSH. My initial idea > > was "paint parked planes" with copies of one texture. Textures is > > what we "see out the window" in FG and it works on my old junk. > > > > ..you're saying "using 20 different a few hundred times each > > is gonna work better than textures??? "Bring it on!" 8o) > > Textures would work if all those planes are of one type and have the > same livery, which is an unrealistic scenario. ..or if the textures covers a row bit of planes. > A more realistic scene that a user would see (hopefully) in FG is a > dozen different types of planes belonging to a dozen different > airlines. Using textures for details would require huge textures per > aircraft-type per airline, and would result in performance cost going > through the roof; and that's excluding the textures that would be > already presented in the airports. ..ok, we're talking "grass with rows of parked planes as seen from the pattern", nothing fancy. > Performance would still degrade if all those aircraft and buildings > have high geometric details, but geometries wouldn't eat up memory as > quick as textures would. Beside, one could always turn off a portion > of the geometries when they aren't needed. > > Anyway, I think we are getting a bit ahead of ourselves here. > FlightGear starts to struggle/struggles with merely 10 aircraft on > the scene. I don't think users would be able to see 100 planes in > the same scene anytime soon. :P ..hmmm. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Impact of texturing objects on performance?
On Friday 09 June 2006 21:50, Arnt Karlsen wrote: > ..Roberto _ is_ stretching understatement as concept, last years > AirVenture put over 10 000 planes on KOSH. My initial idea > was "paint parked planes" with copies of one texture. Textures is > what we "see out the window" in FG and it works on my old junk. > > ..you're saying "using 20 different a few hundred times each > is gonna work better than textures??? "Bring it on!" 8o) Textures would work if all those planes are of one type and have the same livery, which is an unrealistic scenario. A more realistic scene that a user would see (hopefully) in FG is a dozen different types of planes belonging to a dozen different airlines. Using textures for details would require huge textures per aircraft-type per airline, and would result in performance cost going through the roof; and that's excluding the textures that would be already presented in the airports. Performance would still degrade if all those aircraft and buildings have high geometric details, but geometries wouldn't eat up memory as quick as textures would. Beside, one could always turn off a portion of the geometries when they aren't needed. Anyway, I think we are getting a bit ahead of ourselves here. FlightGear starts to struggle/struggles with merely 10 aircraft on the scene. I don't think users would be able to see 100 planes in the same scene anytime soon. :P Ampere ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Impact of texturing objects on performance?
On Thu, 8 Jun 2006 20:40:19 -0400, Ampere wrote in message <[EMAIL PROTECTED]>: > On Friday 09 June 2006 12:06, Roberto Inzerillo wrote: > > > Texture size has a litle impact on filtering time and a huge one > > > when card memory is completely filled. In that situation, swapping > > > begins and very low fps are encountered. > > > > I have to conclude that adding details to an object using textures > > is much better (from a performance point of view) then adding > > details to the geometry. Correct? > > Performance impacts from geometry is very minimal compared to that > from textures. You could degrade performance very quickly if you are > not careful with textures, but A LOT of vertices would be needed to > result in the same kind of performance loss. > > Another problem from using textures is that the details would > eventually turn blur when the camera is close enough to the object. > This is especially a problem for buildings -- particularly buildings > inside an airport, since the users could observe them very closely. > You would never get this problem if you use geometries for details. > > In conclusion, spend freely on polycount, but be very conservative > with textures. > > > 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) ..Roberto _ is_ stretching understatement as concept, last years AirVenture put over 10 000 planes on KOSH. My initial idea was "paint parked planes" with copies of one texture. Textures is what we "see out the window" in FG and it works on my old junk. ..you're saying "using 20 different a few hundred times each is gonna work better than textures??? "Bring it on!" 8o) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Impact of texturing objects on performance?
On Friday 09 June 2006 12:06, Roberto Inzerillo wrote: > > Texture size has a litle impact on filtering time and a huge one when > > card memory is completely filled. In that situation, swapping begins > > and very low fps are encountered. > > I have to conclude that adding details to an object using textures is much > better (from a performance point of view) then adding details to the > geometry. Correct? Performance impacts from geometry is very minimal compared to that from textures. You could degrade performance very quickly if you are not careful with textures, but A LOT of vertices would be needed to result in the same kind of performance loss. Another problem from using textures is that the details would eventually turn blur when the camera is close enough to the object. This is especially a problem for buildings -- particularly buildings inside an airport, since the users could observe them very closely. You would never get this problem if you use geometries for details. In conclusion, spend freely on polycount, but be very conservative with textures. > 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. > Instead of two versions, I would suggest you to create one very-high-detail model using geometries instead. You could divide the details in such a way so that they can be removed as the camera moves away. Ampere ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Impact of texturing objects on performance?
On Fri, 09 Jun 2006 20:49:06 +0200, Robicd wrote in message <[EMAIL PROTECTED]>: > Arnt Karlsen wrote: > > ..an idea: Can an hangar model be used to make the EAA Museum at > > KOSH http://sleepyhollowfarm.com/OshkoshAerialLarge.jpg by using the > > hangar model several times and overlapping at corners to produce the > > EAA Museum model? Is this a bad idea? > > Of course it can be and it's not a bad idea, but it wont look good. I > prefer modelling those peculiar buildings from scratch 'cause that > technique gets much better visual results. Take a look at > http://fgfsdb.stockill.org/modeledit.php?id=277 and > http://fgfsdb.stockill.org/modeledit.php?id=263 , you will get what I > mean. Modelling something that look close to reality makes much more > fun to me :-) .."sustained!" :o) > And I've found a few nice picks of that Museum in the meanwhile. That > will help me in modelling that in a manner which will not look > completely different from reality. > > Your idea is quick and easy, and can be applied when no other solution > is at hand IMHO. ..agreed, and precisely what I meant. > With such an approach I wouldn't care about z-buffer flickering, it > would be the latest visual imperfection people will notice at all. .."overruled!", flickering is acceptable _only_ when you model a candle flame. :o) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Impact of texturing objects on performance?
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
Re: [Flightgear-devel] Impact of texturing objects on performance?
On Friday 09 June 2006 20:50, Mathias Fröhlich wrote: > Well, all that Fred writes is true as long as the sum of all textures used > for the scene fits into texture memory of your graphics card. So using many > huge textures will hurt users of small graphics cards. Maybe it's time someone clever adds some code to adjust FG's graphics quality based on performance like is done in lots of games and MSFS. i.e. If a user has a graphics card with 64MB of VRAM and we want to load 80MB or textures then downscale some of the textures or use texture compression automatically in the background. Using a brute force approach like we do in FG only really works well for things like game consoles where all the user's hardware is 100% identical and you can tweak the software to run within the system specs. PC platforms are too diverse for the brute force approach to work very well. Paul ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Impact of texturing objects on performance?
On Friday 09 June 2006 17:03, Frederic Bouvier wrote: > Graphic cards are optimized to texture objects. The greatest penalty is > when you do state changes. A state is all attributes that affect the > rendering of a primitive ( point, line or triangle ). A color change is > heavy as well as a texture change. The new Paris Scenery can display lots > of identical building just because they use the same texture. That way, you > can draw hundreds of building with a single state change. If these > buildings where designed using 2 textures, there will be 2 state changes > for each building, so hundreds of state changes, and that wouldn't be > playable. > > Texture size has a litle impact on filtering time and a huge one when card > memory is completely filled. In that situation, swapping begins and very > low fps are encountered. > > > There's another question. I am used to creating high detailed objects for > > low distance view and a second low detailed copy for high distance view. > > That speeds up the simulator when the object is distant but ... does FGFS > > unload the unused high detailed 3d object (and its texture file) from the > > graphic cards memory? > > The complete model stay in memory, as well as textures. There is a gain > because less primitives and less state changes are processed by the GPU. > LOD has also an effect on the visual because displaying sub pixel features > usually creates flickers. > > Using Shared models helps saving memory. That way, only one model is > loaded, and it is displayed multiple times. With static objects, every > instance is loaded in memory, with duplicates on geometry and textures. > Changing OBJECT_STATIC to OBJECT_SHARED helped having a decent fps over > Paris, as well as reducing texture size to avoid GPU memory saturation. Well, all that Fred writes is true as long as the sum of all textures used for the scene fits into texture memory of your graphics card. So using many huge textures will hurt users of small graphics cards. So, looking at the size of the textures used for the models might be a good idea anyway. Also unused areas of testures should be avoided since this also takes memory on the graphics card even if that is not mapped to triangles. ... just don't waste graphics card memory for textures not really required. Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Impact of texturing objects on performance?
>>Using Shared models helps saving memory. That way, only one model is >>loaded, and it is displayed multiple times. With static objects, every >>instance is loaded in memory, with duplicates on geometry and >>textures. Changing OBJECT_STATIC to OBJECT_SHARED helped having a >>decent fps over Paris, as well as reducing texture size to avoid GPU >>memory saturation. Arnt Karlsen wrote: > ..an idea: Can an hangar model be used to make the EAA Museum at KOSH > http://sleepyhollowfarm.com/OshkoshAerialLarge.jpg by using the hangar > model several times and overlapping at corners to produce the EAA Museum > model? Is this a bad idea? Of course it can be and it's not a bad idea, but it wont look good. I prefer modelling those peculiar buildings from scratch 'cause that technique gets much better visual results. Take a look at http://fgfsdb.stockill.org/modeledit.php?id=277 and http://fgfsdb.stockill.org/modeledit.php?id=263 , you will get what I mean. Modelling something that look close to reality makes much more fun to me :-) And I've found a few nice picks of that Museum in the meanwhile. That will help me in modelling that in a manner which will not look completely different from reality. Your idea is quick and easy, and can be applied when no other solution is at hand IMHO. With such an approach I wouldn't care about z-buffer flickering, it would be the latest visual imperfection people will notice at all. Roberto ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Impact of texturing objects on performance?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Arnt Karlsen schrieb: > On Fri, 09 Jun 2006 17:03:58 +0200, Frederic wrote in message > <[EMAIL PROTECTED]>: > >> Using Shared models helps saving memory. That way, only one model is >> loaded, and it is displayed multiple times. With static objects, every >> instance is loaded in memory, with duplicates on geometry and >> textures. Changing OBJECT_STATIC to OBJECT_SHARED helped having a >> decent fps over Paris, as well as reducing texture size to avoid GPU >> memory saturation. > > ..an idea: Can an hangar model be used to make the EAA Museum at KOSH > http://sleepyhollowfarm.com/OshkoshAerialLarge.jpg by using the hangar > model several times and overlapping at corners to produce the EAA Museum > model? Is this a bad idea? If all models have the same elevation you might get problems due to z-buffer fighting (it'll flicker). You also need to draw more triangles (= slower) but you'll send less data through the bus to the card (= faster). So, IMHO, just try it and have a look at the result (especially with a 16bit colour setting as it might produce increased z-buffer fighting) CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFEialGlhWtxOxWNFcRAvDrAJ4v/K1Dhpk1DNhiSe0LIVQ2iDSF6QCgiWMd FIgyD4VybWeB/md/68q96Mo= =aQu/ -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Impact of texturing objects on performance?
On Fri, 09 Jun 2006 17:03:58 +0200, Frederic wrote in message <[EMAIL PROTECTED]>: > Using Shared models helps saving memory. That way, only one model is > loaded, and it is displayed multiple times. With static objects, every > instance is loaded in memory, with duplicates on geometry and > textures. Changing OBJECT_STATIC to OBJECT_SHARED helped having a > decent fps over Paris, as well as reducing texture size to avoid GPU > memory saturation. ..an idea: Can an hangar model be used to make the EAA Museum at KOSH http://sleepyhollowfarm.com/OshkoshAerialLarge.jpg by using the hangar model several times and overlapping at corners to produce the EAA Museum model? Is this a bad idea? -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Impact of texturing objects on performance?
> Graphic cards are optimized to texture objects. The greatest penalty is > when you do state changes. A state is all attributes that affect the > rendering of a primitive ( point, line or triangle ). A color change is > heavy as well as a texture change. The new Paris Scenery can display > lots of identical building just because they use the same texture. > That way, you can draw hundreds of building with a single state change. > If these buildings where designed using 2 textures, there will be 2 > state changes for each building, so hundreds of state > changes, and that wouldn't be playable. I think I will use just one texture for every object. My first thought was to build a low res object (without texture) for high distance view and a high res texturized object for small distance view. Id est I will have a single .ac file with two objects inside, and a .xml 'range' animation which switches between them regarding the distance of the viewer. That way I will achieve acceptable quality and speed when the viewer is far away and very accurate visual quality (at the cost of some lower performance) when the observer is very close to the obejct. But I really don't want visual quality at heavy expense of rendering speed. > Texture size has a litle impact on filtering time and a huge one when > card memory is completely filled. In that situation, swapping begins > and very low fps are encountered. I have to conclude that adding details to an object using textures is much better (from a performance point of view) then adding details to the geometry. Correct? > The complete model stay in memory, as well as textures. There is a gain > because less primitives and less state changes are processed by the GPU. > LOD has also an effect on the visual because displaying sub pixel > features usually creates flickers. > > Using Shared models helps saving memory. That way, only one model is > loaded, and it is displayed multiple times. With static objects, every > instance is loaded in memory, with duplicates on geometry and textures. > Changing OBJECT_STATIC to OBJECT_SHARED helped having a decent fps over > Paris, as well as reducing texture size to avoid GPU memory saturation. 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? Roberto -- "Feel free" – 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Impact of texturing objects on performance?
Quoting Roberto Inzerillo: > I wonder how do textures impact on fps against simply colored 3d objects. > > I have a bunch of raw 3d objects to put into a scenery, they look very rough > because of lack of details. Fps performance is very good. Well, I could make > them look much nicer by applying textures to them. This will eat graphic > card's memory of course, but I really don't know if that will impact on > graphic performance as well. Will I get a drop down performance just by > applying textures? Or the only effect will consist in eating up all the AGP > card memory? Graphic cards are optimized to texture objects. The greatest penalty is when you do state changes. A state is all attributes that affect the rendering of a primitive ( point, line or triangle ). A color change is heavy as well as a texture change. The new Paris Scenery can display lots of identical building just because they use the same texture. That way, you can draw hundreds of building with a single state change. If these buildings where designed using 2 textures, there will be 2 state changes for each building, so hundreds of state changes, and that wouldn't be playable. Texture size has a litle impact on filtering time and a huge one when card memory is completely filled. In that situation, swapping begins and very low fps are encountered. > There's another question. I am used to creating high detailed objects for low > distance view and a second low detailed copy for high distance view. That > speeds up the simulator when the object is distant but ... does FGFS unload > the unused high detailed 3d object (and its texture file) from the graphic > cards memory? The complete model stay in memory, as well as textures. There is a gain because less primitives and less state changes are processed by the GPU. LOD has also an effect on the visual because displaying sub pixel features usually creates flickers. Using Shared models helps saving memory. That way, only one model is loaded, and it is displayed multiple times. With static objects, every instance is loaded in memory, with duplicates on geometry and textures. Changing OBJECT_STATIC to OBJECT_SHARED helped having a decent fps over Paris, as well as reducing texture size to avoid GPU memory saturation. -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
