Re: [Flightgear-devel] apt.dat changes ?
On Fri, 9 Jun 2006 22:35:02 -0400 Tony Pelton wrote: > > not sure if folks on this list care, or are aware ... but Ben Supnik > has made a couple of RFC type posts to one of the x-plane lists, > talking about a new design for the airport data coming from Robin > Peel. > > This is apparently the spec that is emerging from those conversations. > > http://www.x-plane.org/home/robinp/Apt850.htm Yeah, Robin's been discussing doing this for quite some time; it's good to see it coming closer to fruition. Curt, have you been following this? Maybe it'd be good if folks here who work on apps that read/work with apt.dat were involved in the RFC's discussion? -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear signature.asc Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hi Tony, From my limited knowledge of how these are used (within the FG environment) they appear to be a positive evolutionary step. I like the idea of curves being corporated. Until tools like TaxiDraw integrate these changes there will be a gap but backward compatibiltiy appears catered for, so great. TerraGear will need to incorporate these changes for the full effect to be felt in the resulting btg files for FGFS. I like the concept of these changes, and look forward to these changes being rippled through to TaxiDraw and TerraGear. Thanks for the heads up :-D ene From: "Tony Pelton" <[EMAIL PROTECTED]> Reply-To: FlightGear developers discussions To: "FlightGear developers discussions" Subject: [Flightgear-devel] apt.dat changes ? Date: Fri, 9 Jun 2006 22:35:02 -0400 not sure if folks on this list care, or are aware ... but Ben Supnik has made a couple of RFC type posts to one of the x-plane lists, talking about a new design for the airport data coming from Robin Peel. This is apparently the spec that is emerging from those conversations. http://www.x-plane.org/home/robinp/Apt850.htm fwiw. Tony -- X-SA user ? 0.5.1 is out ! XData 0.1 for X-SA is out ! http://x-plane.dsrts.com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel _ Shop til you drop at XtraMSN Shopping http://shopping.xtramsn.co.nz/home/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] apt.dat changes ?
not sure if folks on this list care, or are aware ... but Ben Supnik has made a couple of RFC type posts to one of the x-plane lists, talking about a new design for the airport data coming from Robin Peel. This is apparently the spec that is emerging from those conversations. http://www.x-plane.org/home/robinp/Apt850.htm fwiw. Tony -- X-SA user ? 0.5.1 is out ! XData 0.1 for X-SA is out ! http://x-plane.dsrts.com ___ 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] FlightGear on Softpedia
On Friday 09 June 2006 05:32, Christian Mayer wrote: > Perhaps - but then only with our own watermark, so that everybody who > finds them knows where they are from. > > I suggest that the watermark contains the logo, the used version and the > URL. > > CU, > Christian Will these be of use? http://www.cs.yorku.ca/~cs233144/logo2.xcf http://www.cs.yorku.ca/~cs233144/logo2.png 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 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] FGLive, etc (was configurable HUD colors)
Not too late to join our happy band, plenty of work for all ;-D :-D ene From: Pigeon <[EMAIL PROTECTED]> Reply-To: FlightGear developers discussions To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] FGLive, etc (was configurable HUD colors) Date: Sat, 10 Jun 2006 09:02:01 +1000 > ..I have done a few custom Knoppix and Damnsmalllinux live cd's and > Pigeon initially disagreed to make one for AirVenture, so I decided to > do it myself, even if he beats me to it again. ;o) This far we 4 > people contributing on "my" KOSH cd. Whoops, sorry, did I? I must have missed/misunderstood you at some point. I didn't realized I have rejected such a request. I think I did disagree on what you've suggested in terms of approach of doing FGLive (and your GRUB thing :). Perhaps there was a time that I didn't know what AirVenture is :( (Re-reading your e-mail now, and yes, I didn't go to your link to airventure.org :( ) My apologies. Pigeon. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel _ Shop til you drop at XtraMSN Shopping http://shopping.xtramsn.co.nz/home/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear on Softpedia
Martin Spott wrote: > Christian Mayer wrote: > >> Perhaps - but then only with our own watermark, so that everybody who >> finds them knows where they are from. > > Hehe, good idea ! Do you know a method how to place such a watermark > without requiring Curt to open every single screenshot in Gimp (did I > hear "Photoshop" ;-) and merging the watermark manually ? > I know, you can easily batch-modify images with ImageMagick/convert, > but that doesn't allow you to adjust the placement of the watermark for > every single image. > > Cheers, > Martin. Gimp is pretty scriptable. See http://www.xcf.berkeley.edu/~gimp/script-fu/script-fu.html I'm sure there is a way to point a script-fu extension at a list of files and have it present you with images and a watermark to just place and click, one after another. Josh ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGLive, etc (was configurable HUD colors)
> ..I have done a few custom Knoppix and Damnsmalllinux live cd's and > Pigeon initially disagreed to make one for AirVenture, so I decided to > do it myself, even if he beats me to it again. ;o) This far we 4 > people contributing on "my" KOSH cd. Whoops, sorry, did I? I must have missed/misunderstood you at some point. I didn't realized I have rejected such a request. I think I did disagree on what you've suggested in terms of approach of doing FGLive (and your GRUB thing :). Perhaps there was a time that I didn't know what AirVenture is :( (Re-reading your e-mail now, and yes, I didn't go to your link to airventure.org :( ) My apologies. Pigeon. ___ 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] FGLive, etc (was configurable HUD colors)
On Fri, 9 Jun 2006 11:26:58 + (UTC), Martin wrote in message <[EMAIL PROTECTED]>: ..with Reply-To set to both himself and the list, so I honor it. > Arnt Karlsen wrote: > > On Fri, 9 Jun 2006 11:29:20 +1000, Pigeon wrote in message > > >> Currently I'm revising the building process so that it can be fully > >> automated, > > > > ..url? (Yeah I know it's all pre-alpha etc ideas.) > > Arnt, would you please, PLEASE stop permanently annoying people by the > request of download-URL's ? If I were Pigeon, I wouldn't even THINK of > posting such an URL on this list because I'd certainly have to fear > that you'll bomb me with support questions, deliberately crossing the > line where 'good taste' (TM) ends. ..this was meant as an invitation to share ideas and help make a few better LiveCD's. ..I have done a few custom Knoppix and Damnsmalllinux live cd's and Pigeon initially disagreed to make one for AirVenture, so I decided to do it myself, even if he beats me to it again. ;o) This far we 4 people contributing on "my" KOSH cd. ..our approaches on the LiveCD's are different to warrant both, he wants to keep it simple stupid(KISS) for dimwit windroids, I also wanna attract new developers (say to do EAA planes) adding some tools and making transition to Debian GNU/Linux, _easy_, and potent, to satisfy the "Show me!" and "Show us!", with enough authority so they stay with us. ..the best way I see doing this, is show the procedures in this years AirVenture NOTAM in FG scenarios in a new Scenery showing KOSH as it is set up during AirVenture, and simply show'em. > Do you know that people already share a noticeable amount of developer > information off-list, simply because they're fed up getting annoyed by > you with requests to explain every single step for stuff that's still > being worked on - information that _usually_ would show up on such a > developer list. ..pity. I apologise, I usually manage to build stuff out of source code, on TerraGear I assumed _I_ did something wrong, rather than assume TerraGear was broken. ..I'm trying Ralf's Makefiles this weekend and he asked me to give feedback and I like what I've seen this far, so we'll see this or next weekend, there's http://energex2006.com/ too on my list. ..chances are I may have learn to use these CXXFLAGS etc to point builds to specific plib etc installs for TG etc builds, so pointers to learn this is welcome. > Please keep in mind that this is still the "FlightGear Developers > Mailing List", not the "Arnt Karlsen's Private FlightGear Support > List". ..aye. -- ..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 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
[Flightgear-devel] Impact of texturing objects on performance?
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? 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? Roberto -- Echte DSL-Flatrate dauerhaft für 0,- Euro*! "Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flight Gear source code
Hi viper (Zaroug) and Sid, You might try my 'unofficial', personal, flightgear build center at - http://www.geoffmclane.com/fg/ I have not built FG for a few months with MSVC7, but there are some pages there with lots of pointers and comments ... a many-steps by many-steps approach ... this was without threads, or freeglut ... It is worth also reading the latest MSVC8 build, 2006/06/06, - with threads and freeglut - as many 'common errors' are the same ... especially getting the runtime libraries = ALL THE SAME = ... Keep trying ... eventually the 'zillions' will become ZERO ;=)) most of your efforts will be in the additional include directories ... Regards, Geoff. _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear on Softpedia
On Fri, 9 Jun 2006 13:38:07 +0200, Melchior wrote in message <[EMAIL PROTECTED]>: > * Martin Spott -- Friday 09 June 2006 13:30: > > Let me guess, do we know the author of this article by name ? ;-) > > I was already wondering why the author of such a publication has so > > detailed insight into the inner workings of FlightGear > > Heh, no! I know that article since a while, but I have not the least > to do with it. Honestly! What really happened: I told them that their > EU membership talks would immediately be stopped ..heh, try the EU membership talk approach on me and watch the oceans rise 25 ft before my "huh?". ;o) > (the page is hosted in Bucharest/Romania) if they wouldn't remove the > watermarks. The Romanian ambassador stopped by with a bottle of potato > distillate and apologized ... the rest is history. > > Ok, ok. I just wrote a complaint and they fixed it. .. :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] FlightGear on Softpedia
* Martin Spott -- Friday 09 June 2006 13:30: > Let me guess, do we know the author of this article by name ? ;-) > I was already wondering why the author of such a publication has so > detailed insight into the inner workings of FlightGear Heh, no! I know that article since a while, but I have not the least to do with it. Honestly! What really happened: I told them that their EU membership talks would immediately be stopped (the page is hosted in Bucharest/Romania) if they wouldn't remove the watermarks. The Romanian ambassador stopped by with a bottle of potato distillate and apologized ... the rest is history. Ok, ok. I just wrote a complaint and they fixed it. m. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear on Softpedia
Melchior FRANZ wrote: > * Martin Spott -- Friday 09 June 2006 11:07: >> Unfortunately they took the screenshots from the FlightGear gallery and >> put their watermark on it, > > Fixed. Stay cool. :-) Let me guess, do we know the author of this article by name ? ;-) I was already wondering why the author of such a publication has so detailed insight into the inner workings of FlightGear Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGLive, etc (was configurable HUD colors)
Arnt Karlsen wrote: > On Fri, 9 Jun 2006 11:29:20 +1000, Pigeon wrote in message >> Currently I'm revising the building process so that it can be fully >> automated, > > ..url? (Yeah I know it's all pre-alpha etc ideas.) Arnt, would you please, PLEASE stop permanently annoying people by the request of download-URL's ? If I were Pigeon, I wouldn't even THINK of posting such an URL on this list because I'd certainly have to fear that you'll bomb me with support questions, deliberately crossing the line where 'good taste' (TM) ends. Do you know that people already share a noticeable amount of developer information off-list, simply because they're fed up getting annoyed by you with requests to explain every single step for stuff that's still being worked on - information that _usually_ would show up on such a developer list. Please keep in mind that this is still the "FlightGear Developers Mailing List", not the "Arnt Karlsen's Private FlightGear Support List". Thanks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear on Softpedia
* Martin Spott -- Friday 09 June 2006 11:07: > Unfortunately they took the screenshots from the FlightGear gallery and > put their watermark on it, Fixed. Stay cool. :-) m. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGLive, etc (was configurable HUD colors)
On Fri, 9 Jun 2006 11:29:20 +1000, Pigeon wrote in message <[EMAIL PROTECTED]>: > > > Or I have to wait for the next relese of FGLive... > > > > ..Unless Pigeon beats me to it, about 2 more weeks. He used Morphix > > as the base, I'm checking ParallelKnoppix, but with grub, "is > > _made_ for formation flight". ;o) > > Well, releasing a new FGLive with a newer version of FG is a no > brainer. But then I haven't thought of when to make another release > yet. > > Currently I'm revising the building process so that it can be fully > automated, ..url? (Yeah I know it's all pre-alpha etc ideas.) Some of my, Dene, Roberto and Georg's stuff is at http://80.239.32.252/ ..did you chk out Ralf's ftp://ftp.ihg.uni-duisburg.de/FlightGear/Misc_rag/fgfs-build.tgz and ftp://ftp.ihg.uni-duisburg.de/FlightGear/Misc_rag/new_builder.tar.gz Me, I was about to piece together a bash script doing something similar. > and also anyone can build their own customizable FGLive at mimimium > effort. Hopefully the same framework could be used for FG > installation in general, too. .. :o) > I wanted to setup an autobuild system to build FG binaries, as well > as packages. Along with this we can have a build script which you > could easily select what to be included. ..debs from cvs too? I too prefer the aptitude route myself, over stuffing things in /opt or /usr/local, one of those I like to share across clusters. > So hopefully one day you could pick a version of FG from a list, pick > some aircraft you want to be included, pick some sceneries, then ...scenarios ;o) and... > "build FGLive" or "install on my machine". We could have a GUI > aircraft/sceneries picker/installer which uses the same > info/framework. > > All these are pretty much in the "thinking" stage, I could be just day > dreaming with all this sounded-good ideas. We'll see. > > > P.S. Arnt: You and your GRUB :P ..aye. ;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] FlightGear on Softpedia
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Spott schrieb: > Christian Mayer wrote: > >> Perhaps - but then only with our own watermark, so that everybody who >> finds them knows where they are from. > > Hehe, good idea ! Do you know a method how to place such a watermark > without requiring Curt to open every single screenshot in Gimp (did I > hear "Photoshop" ;-) and merging the watermark manually ? > I know, you can easily batch-modify images with ImageMagick/convert, > but that doesn't allow you to adjust the placement of the watermark for > every single image. I'd try to add a semi transparent watermark in some corner (bottom left?). This can be done automatically w/o any interaction and it should work for most screenshots. A manual screening can show problematic pictures that might be redone manually for a better placement. CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFEiUlBlhWtxOxWNFcRAnaaAJ9YEoQOA3pY+8+KdJeWZn5dkgjvHQCgk9jx qHeugeM1FkgXNMf+PWQHguI= =7xLz -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configurable HUD colors [breaks backward compatibility]
On Thu, 8 Jun 2006 17:10:08 -0700 (PDT), Isao wrote in message <[EMAIL PROTECTED]>: > Since Melchior just checked in the HUD color feature, I have to > compile from the CVS. > > Also with Debian, I always have a difficulty with apt-get installing ..aye. Use aptitude. If need be, " apt-get install aptitude ". ;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] FlightGear on Softpedia
Am Freitag, 9. Juni 2006 11:50 schrieb Martin Spott: > Christian Mayer wrote: > > Perhaps - but then only with our own watermark, so that everybody who > > finds them knows where they are from. > > Hehe, good idea ! Do you know a method how to place such a watermark > without requiring Curt to open every single screenshot in Gimp (did I > hear "Photoshop" ;-) and merging the watermark manually ? > I know, you can easily batch-modify images with ImageMagick/convert, > but that doesn't allow you to adjust the placement of the watermark for > every single image. How do you want to do interactive placement without interaction? ;-) I think there's no way other than gimp, if the placement of the watermark must be adjusted for every single image... Thomas ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear on Softpedia
Christian Mayer wrote: > Perhaps - but then only with our own watermark, so that everybody who > finds them knows where they are from. Hehe, good idea ! Do you know a method how to place such a watermark without requiring Curt to open every single screenshot in Gimp (did I hear "Photoshop" ;-) and merging the watermark manually ? I know, you can easily batch-modify images with ImageMagick/convert, but that doesn't allow you to adjust the placement of the watermark for every single image. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear on Softpedia
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erik Hofman schrieb: > Martin Spott wrote: >> Unfortunately they took the screenshots from the FlightGear gallery and >> put their watermark on it, > > The watermark is a pity but it might be good for FlightGear to put the > screenshots that end up in the gallery in the public domain. Perhaps - but then only with our own watermark, so that everybody who finds them knows where they are from. I suggest that the watermark contains the logo, the used version and the URL. CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFEiUAXlhWtxOxWNFcRAkG0AJ9K6GDs6IUpQRFTxR8112ezcDHRtQCfabif yqZGhx63gNjKFCkeM8x61qE= =J+au -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear on Softpedia
Martin Spott wrote: > Unfortunately they took the screenshots from the FlightGear gallery and > put their watermark on it, The watermark is a pity but it might be good for FlightGear to put the screenshots that end up in the gallery in the public domain. Erik -- http://www.ehtw.info (Dutch)Future of Enschede Airport Twente http://www.ehofman.com/fgfs FlightGear Flight Simulator ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FlightGear on Softpedia
Hi, I don't know if the article is really 'fresh', as they don't have a date printed on their page. At least it's new to _me_ and I think they did a pretty good job of advertizing FlightGear: http://games.softpedia.com/get/Freeware-Games/FlightGear.shtml Unfortunately they took the screenshots from the FlightGear gallery and put their watermark on it, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
