[Flightgear-devel] Texturing - some opinions please
I have two questions to which I'd like to gather a few opinions: 1) Emilian pointed out here http://www.flightgear.org/forums/viewtopic.php?f=68&t=17114&hilit=procedural+texturing&start=30#p165312 that terrain textures are a fair share of memory consumption and concluded that we shouldn't use multiple choices of textures in the materials file - for instance we assign sand1.png, sand2.png and sand3.png to the same landclass). I don't know what the original rational for this was. It leads to a modest reduction in tiling since the base texture is changed every 10 km or so, but all in all I don't see dramatic visual improvements. It also leads to some more variety in the textures encountered. Both advantages seem increasingly obsolete to me, so I largely agree with Emilian. Procedural texturing allows to suppress tiling much more efficiently, and regional texturing exposes the user to a great variety of different textures in various places of the world. Hence my question - are there objections against phasing out the use of multiple textures per landclass in my future modifications of /regions/materials.xml, or are there reasons to keep them I haven't seen? /default/materials.xml will still be left untouched for anyone who prefers the old style. 2) There has been a discussion here http://www.flightgear.org/forums/viewtopic.php?f=47&t=17879 to try to get the shader to do autumn colors automatically. The most efficient way I can see to do that without significant extra cost is to use the texture alpha channel (terrain textures are never transparent, so that is freely available) to encode which parts of the texture should be color-rotated how much (it doesn't do to get bright red needle-cover...). The advantage is that this is a fast and efficient scheme because no extra texture sheets need to be loaded or prepared. The disadvantage is that it will make our terrain textures look odd and not very user-friendly to edit. Any opinions on if we should try to test this or not? Thanks, * Thorsten -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Physics engine of Flightgear
Thank you Jon for your reply. I am still a bit confused. Which one of the two is correct ? 1) YAsim or JSBsim is used to specify only aircraft flight model parameters and the physics flight dynamics engine is a separate component that uses these parameters. In this case, what physics-based Flight Dynamics Engine (FDE) is used ? 2) YAsim/JSBsim is to be considered an integrated systems that utilizes aircraft flight model parameters given by the user in conjunction with an internal FDE. My interest is in the physics-based FDE. If there is information about the FDE used in FlightGear, please give me some references.-- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Texturing - some opinions please
On 10/19/2012 09:05 AM, Renk Thorsten wrote: > > I have two questions to which I'd like to gather a few opinions: > > 1) Emilian pointed out here > http://www.flightgear.org/forums/viewtopic.php?f=68&t=17114&hilit=procedural+texturing&start=30#p165312 > that terrain textures are a fair share of memory consumption and concluded > that we shouldn't use multiple choices of textures in the materials file - > for instance we assign sand1.png, sand2.png and sand3.png to the same > landclass). I don't know what the original rational for this was. It leads to > a modest reduction in tiling since the base texture is changed every 10 km or > so, but all in all I don't see dramatic visual improvements. It also leads to > some more variety in the textures encountered. Correct, they were introduced to reduce tiling artefacts. > Both advantages seem increasingly obsolete to me, so I largely agree with > Emilian. Procedural texturing allows to suppress tiling much more > efficiently, and regional texturing exposes the user to a great variety of > different textures in various places of the world. > > Hence my question - are there objections against phasing out the use of > multiple textures per landclass in my future modifications of > /regions/materials.xml, or are there reasons to keep them I haven't seen? > /default/materials.xml will still be left untouched for anyone who prefers > the old style. I see no reason to include multiple options of the same texture if one could do just fine. It's just a matter of removing them from the xml file (or comment hem out). I also noticed you effectively removed the need for winter textures, nice! Erik -- http://www.adalin.com - Hardware accelerated AeonWave and OpenAL for Windows and Linux -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-commitlogs] SimGear branch, next, updated. f191b4f35c26d38cf856a9ea0e69706d2167396b
Hi, > - > commit f191b4f35c26d38cf856a9ea0e69706d2167396b > Author: Thomas Geymayer > Date: Fri Oct 19 11:48:39 2012 +0200 > > Move FGODGauge from FlightGear to SimGear. ... > +// Written by Harald JOHNSEN, started May 2005. ... > +// This program is free software; you can redistribute it and/or > +// modify it under the terms of the GNU General Public License as > +// published by the Free Software Foundation; either version 2 of the > +// License, or (at your option) any later version. > http://gitorious.org/fg/simgear/blobs/next/COPYING License mismatch ? -Fred -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-commitlogs] SimGear branch, next, updated. f191b4f35c26d38cf856a9ea0e69706d2167396b
Hi, my fault. I've somehow missed that SimGear and FlightGear use different licenses. A GPL -> LPGL transition should only be possible with agreement of all authors. If applying git blame on the latest version in FlightGear (https://gitorious.org/fg/flightgear/blobs/blame/b22ede2fd57e689fdf791950528588421a5b4b3f/src/Cockpit/od_gauge.cxx) it can be seen that nearly the whole file was written by me, apart from some comments and includes. The reason is that I've completely rewritten the original FGODGauge class and only kept the interfaces for backward compatibility. I'm not a lawyer to tell if we really need the agreement of every author, even if the contribution left is just an include statement or bracket. Tom -- Thomas Geymayer www.tomprogs.at / C-Forum und Tutorial: www.proggen.org Student of Computer Science @ Graz University of Technology --- Austria -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Physics engine of Flightgear
On Friday 19 October 2012 04:37:50 kunai...@yahoo.co.jp wrote: > Thank you Jon for your reply. > I am still a bit confused. Which one of the two is correct ? > > 1) YAsim or JSBsim is used to specify only aircraft flight model > parameters and the > physics flight dynamics engine is a separate component that uses these > parameters. In this case, > what physics-based Flight Dynamics Engine (FDE) is used ? > > 2) YAsim/JSBsim is to be considered an integrated systems that utilizes > aircraft flight > model parameters given by the user in conjunction with an internal FDE. > > My interest is in the physics-based FDE. If there is information about > the FDE used in FlightGear, > please give me some references. Neither. YASim and JSBSim are separate choices for the physics of flight modeling. There is no underlying "FDE" as you put it. http://wiki.flightgear.org/JSBSim http://wiki.flightgear.org/YASim Ron -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
