Re: [Flightgear-devel] Random object/vegetation terrain masking
On Tue, Feb 7, 2012 at 9:13 PM, Stuart Buchanan wrote: > These have now been retired, so the format of materials.xml should now > be easier to understand. The format of materials.xml should be even easier to understand, as I've just committed a new fgdata/Docs/README.materials. -Stuart -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake equivalent to --with-osg=/some/path
Hi, There is a shortcut if dependencies and results are all in the same directory prefix: -DCMAKE_INSTALL_PREFIX= This may not be suitable for jenkins. Olaf Flebbe o...@oflebbe.de Am 08.02.2012 um 12:35 schrieb Jon Stockill: > I'm currently updating some jenkins build scripts for cmake rather than > autoconf, and I'm having problems getting the build to link against > local copies of all the dependencies. Is there a simple way of > specifying where to look for these rather than having to specify the > path to each individual library file (which from the cmake output seems > like it might be the only way). > -- > Jon Stockill > li...@stockill.net > > -- > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio simulation of navigational aids
On Tuesday, February 07, 2012 18:31:26 Eric van den Berg wrote: > Hi Adrian, > > Would go with 1. As you say signal strength does not have a major > influence on the functionality itself. It works or you have a flag. Only > of the very border of reception the respective indicator will wander > out. But that also is a signal strength issue and can be modelled > accordingly. > 2. is not realistic as you say yourself. Has nothing to do with those > systems functionality. > 3. would be very interesting to model, but unless it is planned to model > failures (90Hz sender out for instance), interference with other radio > sources (EMI so to say) or some other radio propagation effects I would > not bother. > > Eric Hi Eric, I agree that for now option 1 is the best. If there will be any interest in the future for a more detailed simulation, I will consider #3. Right now, I will use a generic directional antenna pattern for ILS systems, obtained with a 4nec2 generated plot for a yagi antenna. This plot could be replaced easily if the same file format is kept. I'm also willing to consider different file formats for antenna plots, as long as they are not obfuscated, if you or anyone else knows a better tool for electrical antenna analysis that I'm not yet familiar with. I'm not yet sure what to use for aircraft antennas, so I'll leave them omnidirectional for now. Cheers, Adrian -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake equivalent to --with-osg=/some/path
On Wed, 2012-02-08 at 11:35 +, Jon Stockill wrote: > I'm currently updating some jenkins build scripts for cmake rather than > autoconf, and I'm having problems getting the build to link against > local copies of all the dependencies. Is there a simple way of > specifying where to look for these rather than having to specify the > path to each individual library file (which from the cmake output seems > like it might be the only way). Hi Jon, A HOT extract from my current 1.3.8 'makefg' script ;=)) Not yet published as still testing some options like - FGCM_OPTS="$FGCM_OPTS -D JPEG_FACTORY:BOOL=ON" But for the dependencies OSG, SG, and the recently added PLIB when only installed 'locally'... ADDPLIBDIRS=0 # If PLIB is installed locally, then ADDPLIBDIRS=1 FGCM_OPTS="$FGCM_OPTS -D CMAKE_VERBOSE_MAKEFILE=TRUE" if [ "$ADDPLIBDIRS" = "1" ]; then FGCM_OPTS="$FGCM_OPTS -D PLIB_LIBRARIES=$INSTALL_DIR_PLIB/lib" FGCM_OPTS="$FGCM_OPTS -D PLIB_INCLUDE_DIR= $INSTALL_DIR_PLIB/include" fi FGCM_OPTS="$FGCM_OPTS -D CMAKE_INSTALL_PREFIX=$INSTALL_DIR_FGFS" For SG installed locally I use an export... like makefg: Done 'export SIMGEAR_DIR=/media/Disk2/FG/fg20/install/simgear' For OSG installed locally I use an export... like makefg: Done 'export OSG_DIR=/media/Disk2/FG/fg20/install/OSGtrunk' then... echo2 "$BN: Will do 'cmake $FGCM_OPTS $FGFS_SOURCE_PATH'" cmake $FGCM_OPTS $FGFS_SOURCE_PATH The actual cmake command is quite simple - makefg: Will do 'cmake -D CMAKE_VERBOSE_MAKEFILE=TRUE \ -D CMAKE_INSTALL_PREFIX=/media/Disk2/FG/fg20/install/flightgear \ /media/Disk2/FG/fg20/flightgear' I had tried setting SG LIBRARIES and INCLUDE, like PLIB, but this did not work for me - if [ "$ADDSGDIRS" = "1" ]; then FGCM_OPTS="$FGCM_OPTS -D SIMGEAR_LIBRARIES= $INSTALL_DIR_SIMGEAR/lib" FGCM_OPTS="$FGCM_OPTS -D SIMGEAR_INCLUDE_DIR= $INSTALL_DIR_SIMGEAR/include" fi Not sure why this fails... maybe it should be like - SIMGEAR_LIBRARIES:PATH=$INSTALL_DIR_SIMGEAR/lib or something... And also had some success with - FGCM_OPTS="$FGCM_OPTS -D CMAKE_PREFIX_PATH=$INSTALL_DIR_SIMGEAR" but seemed unnecessary once I do the SIMGEAR_DIR 'export'... And more or less the same for terragear-cs except no need for OSG stuff... HTH, but maybe other with more cmake savvy can do better ;=)) Regards, Geoff. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Version file check
Am 07.02.12 21:49, schrieb ThorstenB: > Am 07.02.2012 21:34, schrieb Curtis Olson: >> The main reason for a version check between the binary and the data is >> that we often make parallel changes to both (similar reason why we do a >> simgear minimum version check when compiling flightgear.) If there are >> version mismatches, things could break or act in weird or unexpected ways. >> >> A launcher might not be in the same category unless you use options that >> change between versions (this is possible, but happens a lot less often >> than other sorts of changes.) > > Right. Not sure what Yves' original intention were. I referred to the > basic check if the "version" file is there _at all_ - such a check seems > useful for a launcher. Restricting a launcher to a specific version > number inside the file indeed wouldn't be a good idea. At least I'd like > to keep using the same launcher for a variety of fgfs versions - 2.5.0, > 2.6.0, 2.7.0 :). > > cheers, > Thorsten Thanks for your comments. I will do the "basic check" for the file. Maybe later I will try to do a check for fgfs version against fgdata version, to see if both is in line before fgfs process is started (and probably fails). -Yves -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] ..fgrun, was: Version file check
On Tue, 07 Feb 2012 21:49:59 +0100, ThorstenB wrote in message <4f318e77.7070...@gmail.com>: > Am 07.02.2012 21:34, schrieb Curtis Olson: > > The main reason for a version check between the binary and the data > > is that we often make parallel changes to both (similar reason why > > we do a simgear minimum version check when compiling flightgear.) > > If there are version mismatches, things could break or act in weird > > or unexpected ways. ..yes, but we should wave big red flags warning the user "this _should_ break!", not deny him finding new ways to find bugs. > > A launcher might not be in the same category unless you use options > > that change between versions (this is possible, but happens a lot > > less often than other sorts of changes.) > > Right. Not sure what Yves' original intention were. I referred to the > basic check if the "version" file is there _at all_ - such a check > seems useful for a launcher. Restricting a launcher to a specific > version number inside the file indeed wouldn't be a good idea. At > least I'd like to keep using the same launcher for a variety of fgfs > versions - 2.5.0, 2.6.0, 2.7.0 :). ..debian's fgrun 1.6.0-1 offer those options after you pick the appropriate binaries etc, which is a nice feature. It becomes a bug as it doesn't offer any distro installed fgfs as a default, you _have_ to pick the distro's default 2.4.0-1 /usr/games/fgfs binary to have Debian's fgrun-1.6.0-1 launch Debian's fgfs-2.4.0-1. ..this wee config job should IMHO be done by the fgrun install script, _if_ it finds the distro's default fgfs. ..thenafter we can have fgfs et al's install scripts call the fgrun install script. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...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. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Cmake equivalent to --with-osg=/some/path
I'm currently updating some jenkins build scripts for cmake rather than autoconf, and I'm having problems getting the build to link against local copies of all the dependencies. Is there a simple way of specifying where to look for these rather than having to specify the path to each individual library file (which from the cmake output seems like it might be the only way). -- Jon Stockill li...@stockill.net -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader performance
After a few more tests, some more observations which seem to be right to me listed here (if that is confirmed, we may perhaps gather these and other statements to the Wiki to get some guidelines for efficient shader coding): * 'big' performance users seem to be the scientists's friends, i.e. functions like exp(x), log(x), sqrt(x) which for me make a noticeable impact :-(. I've made good experience by returning asymptotics explicitly, for instance in a light function f(x) = e / (1.0 + a * exp(-b * (x-c)) )**(1/d) simply asking if x > threshold and returning e if the condition is true before attempting to evaluate the function speeds things up quite a bit in many cases while making a tiny error (in my case, 1e-4 or so). I haven't tried it yet, but I suspect now that x*x*x*x would also evaluate much faster than pow(x,4.0) since the first is just a multiplication while the second utilizes a function which is even more general than sqrt(). * GLSL doesn't go for smartness, so it has to be coded in. In an expression like mix(cheapExp, expensiveExp, fraction) even for fraction = 0 expensiveExp is computed. So again, an if (fraction == 0) in front of this can reduce the load quite a bit to compute expensiveExp only if it is really needed. * in the shaders I have seen, usually a very physics-centered approach is taken: We first take the color of an object from the texture, then apply ambient, diffuse and specular light to see what color it takes, then go to the eye and have a look at how much of it is fogged. However, an eye-centered approach seems much better to me - the first question to be asked is 'What can we see of the object?' and if the answer is '99% fog' we don't really need to know the texture or compute specular reflections. Which is to say, in many situations I would perhaps compute the fog function first (if possible) and base my decisions what else to compute for the pixel/vertex dependent on the outcome of that. For instance, in the cloud shader fog comes pretty much last - but we probably could dispense with bottom and away side shading beyond a certain fog value, because it's useless to first compute a darkening and then brighten it to transparent/white again. So far, this hasn't been too relevant because objects which are 99% fogged are soon to be unloaded anyway, because the distance to which terrain is laoded is set by the same parameter as the fog. But this may not be how to continue. The terrain-haze shader already allows the two to be different, and it has also a lot of merit to have terrain loaded even if you can't see it - weather needs to know terrain to get cloud-terrain interactions right, any terrain radar would need it (see for instance the very interesting development 787 MFD Vertical Profile here: http://flightgear.org/forums/viewtopic.php?f=30&t=15200 this simply won't work under true IFR conditions when it is needed most because no terrain is loaded). All in all, it seems to me that making shader code efficient is just a very messy and ugly uphill battle in which lots of small effects sum up to something noticeable in the end... Cheers, * Thorsten -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
