Re: [Flightgear-devel] Release candidates
Are the Winter textures still needed? In a sense they were never really needed... for instance I have never used them. Just to summarize the options we have to generate snow: 1) Winter textures They are base texture sheets with snow painted on, which means they have a fixed snowcover and no simulation of a snowline is possible. On the good side, they do not need any shader technology and render with some margin fastest of all snow options. 2) Snow texture overlay This uses shader technology to overlay a snow texture on the terrain, and is the snow feature implemented in the default rendering scheme (I don't know about Rembrandt, maybe also there?). This has a fixed snow coverage but variable snowline and uses significantly more resources than 1) (needs to read a second texture, needs to read noise textures, needs to compute the local amount of snow based on terrain gradient). 3) Procedural snow This is a white base color modified by several noise functions. It has variable snow coverage, i.e. can change from thin patches of snow to a thick layer, and has a variable snowline. It is implemented in Atmospheric Light Scattering at the higher quality levels. This needs about as much performance as 2) and much more than 1) (evaluates terrain gradient and several noise functions, but doesn't read any texture). If we want to have a CD-sized base package, and if we're fine with not supporting snow on less powerful hardware, then we can remove the snow textures. If we want to support snow on weak hardware, then they are needed. A (more complicated) option would be to offer only one set of terrain textures in the base package and offer the others as additional downloads. Both the dds and the winter textures are probably relatively clean to separate - as far as I know they're not shared across different schemes. My private opinion is that aiming for CD-size isn't that important and I would leave everything in. * 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_d2d_jan ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Release candidates
On 31 Jan 2013, at 08:00, Renk Thorsten thorsten.i.r...@jyu.fi wrote: A (more complicated) option would be to offer only one set of terrain textures in the base package and offer the others as additional downloads. Both the dds and the winter textures are probably relatively clean to separate - as far as I know they're not shared across different schemes. My libSVN replacement is getting closer to the top of my TODO list, at which point identifying chunks of the base package which can be optional / on-demand downloads would be very doable. I was thinking the the 'high-res' textures, but the winter textures would certainly fit too. (I haven't yet figured out what other suitable chunks there are) James -- 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_d2d_jan ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Release candidates
Thorsten wrote Are the Winter textures still needed? In a sense they were never really needed... for instance I have never used them. Just to summarize the options we have to generate snow: 1) Winter textures They are base texture sheets with snow painted on, which means they have a fixed snowcover and no simulation of a snowline is possible. On the good side, they do not need any shader technology and render with some margin fastest of all snow options. 2) Snow texture overlay This uses shader technology to overlay a snow texture on the terrain, and is the snow feature implemented in the default rendering scheme (I don't know about Rembrandt, maybe also there?). This has a fixed snow coverage but variable snowline and uses significantly more resources than 1) (needs to read a second texture, needs to read noise textures, needs to compute the local amount of snow based on terrain gradient). 3) Procedural snow This is a white base color modified by several noise functions. It has variable snow coverage, i.e. can change from thin patches of snow to a thick layer, and has a variable snowline. It is implemented in Atmospheric Light Scattering at the higher quality levels. This needs about as much performance as 2) and much more than 1) (evaluates terrain gradient and several noise functions, but doesn't read any texture). If we want to have a CD-sized base package, and if we're fine with not supporting snow on less powerful hardware, then we can remove the snow textures. If we want to support snow on weak hardware, then they are needed. A (more complicated) option would be to offer only one set of terrain textures in the base package and offer the others as additional downloads. Both the dds and the winter textures are probably relatively clean to separate - as far as I know they're not shared across different schemes. My private opinion is that aiming for CD-size isn't that important and I would leave everything in. I'm not sure if I'm doing something wrong here: we now have so many different options, but getting snow by method 2 or 3 results in deciduous trees in full leaf with snow coverage on the ground. Not an impossible scenario, but bare trees are more likely. Is this a bug? So at least for now we need at least some winter textures and the ability to select to select them. Vivian -- 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_d2d_jan ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Release candidates
I'm not sure if I'm doing something wrong here: we now have so many different options, but getting snow by method 2 or 3 results in deciduous trees in full leaf with snow coverage on the ground. Not an impossible scenario, but bare trees are more likely. Is this a bug? It's actually... pretty complicated to address that properly. Early snow in fall would have the mountain-tops covered, and the deciduous trees down in the valley would often be bright orange-red whereas the higher trees would start being dull brown. Later in the year, all deciduous trees regardless of altitude would be leafless, but in mixed forest the needle trees (on the same texture sheet) would remain green. In early spring, you can have no snow, but still leafless trees. So a plausible model for trees in different seasons requires the ability * to distinguish needle and deciduous trees on the same texture sheet (we're probably going to do that by using the index number) * to color-rotate the deciduous trees from green via yellow to red, dull brown and finally transparent based on the selected season and altitude Note that trees usually evolve according to season, not according to snow cover, so we really need a season slider to simulate that properly - it doesn't do to just remove leaves from snow-covered trees and keep trees below the snowline in bright green. I have made some progress with an autumn-color model for the terrain which can probably be extended to spring http://www.flightgear.org/forums/viewtopic.php?f=47t=18580 and there are some ideas both by Stuart and Emilian how to tackle the trees, but it still requires a bit of RD to make this work. I would think that we have continuous season model by the next release which includes trees. So at least for now we need at least some winter textures and the ability to select to select them. Well, one could drop the terrain winter textures and keep the tree winter textures and just make trees selectable - that would also allow to access autumn tree texture sheets which currently isn't done. But for the proper solution, see above. * 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_d2d_jan ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Release candidates
On 01/31/2013 09:17 AM, James Turner wrote: My libSVN replacement is getting closer to the top of my TODO list, at which point identifying chunks of the base package which can be optional / on-demand downloads would be very doable. I was thinking the the 'high-res' textures, but the winter textures would certainly fit too. (I haven't yet figured out what other suitable chunks there are) There's also ATC chatter sound files for different part of the world. 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_d2d_jan ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Winter Textures ( was Re: Release candidates)
On Thu, Jan 31, 2013 at 9:05 AM, Vivian Meazza wrote: I'm not sure if I'm doing something wrong here: we now have so many different options, but getting snow by method 2 or 3 results in deciduous trees in full leaf with snow coverage on the ground. Not an impossible scenario, but bare trees are more likely. Is this a bug? I'll claim it's a limitation of the current scheme rather than a bug :). As it happens I've got a fix/enhancements for this sitting on my computer right now that's just about ready to push, but which I need to discuss. Basically, at present the trees are represented by a 512x128 texture containing 8 trees in row. My enhancement is to change this to a 512x512 texture containing 4 rows or tree, representing summer, summer+snow, winter and winter+snow. I then have a small change to the shader (that doesn't use an if test :) ) to shift the texture to the correct row depending on the snow level and whether we think it's winter or not. We need both snow and winter as separate states as with snow alone you'd end up with deciduous trees with leaves below the snowline and bare branches above - acid snow ? There are a couple of problems I'd like advice on: 1) (pre-existing) Under rembrandt, the winter deciduous tree texture suffers as it has significant alpha but isn't registered as a transparent object. 2) It's not clear to me that we want to display trees with snow on them above the snowline. In my experience, trees very quickly lose their snow cover after snow-fall if there's any wind. So perhaps the snow-covered trees should only be used if snow is actually falling, and what we really need is a simple way to change from summer to winter tree textures? 3) We use /sim/startup/season to indicate whether it is summer or winter. That's a string (summer, winter) that I need to map into an integer to pass down the stack to a uniform in the shader. There's no obvious way to do this mapping, so I'm thinking of changing the property we currently use (/sim/startup/season) globally to /environment/winter or somesuch, with type integer. And, to go back to the original point about winter textures I agree that we need to keep them. -Stuart -- 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_d2d_jan ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Release candidates
On 31 Jan 2013, at 10:06, Erik Hofman e...@ehofman.com wrote: There's also ATC chatter sound files for different part of the world. Oh, that's a good point indeed. AI models is another one, but also more tricky. Personally I'd like AI aircraft to be downloaded on demand, but only from a trusted/safe repository, which needs some thought. And I realise some people would definitely *not* want that feature. James -- 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_d2d_jan ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Model shader for Atmospheric Light Scattering
I've just pushed the first version of the model shader for Atmospheric Light Scattering. It should do random buildings with reflections and all aircraft using the model-combined.eff without normal mapping. The shader still has some quirks, but they're hard to spot if you don't look for them ;-) As illustration of how the full effect looks, I have touched the IAR-80 and inserted the required declaration to get the tangent and binormal to the shaders there. Look at the bare metal livery in sunrise conditions - looks simply awesome. As I said previously, aircraft maintainers, please consider using this effect/inserting the attributes to get the normal map right. With my best wishes to Heiko (who has been asking for this for a whle) and a big thanks to Emilian! * 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_d2d_jan ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Release candidates
Hi Curt, Downloaded 2.10 RC1 - Wow over a 20 minutes even at about 550 MB/s, but I guess all good things come with a little pain ;=)) But noted you 'forgot' to adjust the default install folder - it still reads C:\PF\FlightGear-2.8.0.4 as the default install folder. And likewise the name for the default desktop icon. After manually changing those to 2.10.0.1, fgrun loaded fine with the correct paths, and fgfs ran fine in the first quick test using the 777-200... Will naturally report any bugs found... The 740 MB setup exe expands to 1.4 GB on disk... Since I am also interested in producing a RC from my own build curious how you 'separate' the RC data from the git master fgdata. Checked fg/fgmeta but could not find any 'script' to do this... Can you add your 'scripts' to there? Or did I miss something? And in checking your installed data, note the biggest dozen or so folders that are over a MB are - AI- 375 MB Aircraft - 275 MB Textures.high - 230 MB Models- 229 MB Textures - 82 MB ATC - 73 MB Scenery - 21 MB Docs - 17 MB Sounds- 6 MB Timezone - 6 MB Airports - 5 MB Navaids - 4 MB Fonts - 2 MB Nasal - 1 MB Note, these are size estimates based on a disk sector size of 4096 bytes, thus things like Timezone is only a total of 815 KB in file size, but is 1,542 small files so climbs to 6 MB of disk space. From what I have read, it seems we have reduced Aircraft to the bare minimum of about 15 so seems little can be done there... But why does AI top the size list for a bare-bones release? In there the top is - Aircraft - 235 MB Traffic - 136 MB Airports - 3 MB Could we not reduce the AI Aircraft and/or Traffic? At least for an initial BASE release... From feedback here it seems removing Textures.high maybe out of the question? But maybe not... In Models, the majority is in Weather - 76 MB, and do note that most of the 'big' files are duplicated as dds and rgb. I tried to follow some of the discussion here on this, but is it necessary to have both? In ATC I see Chatter 61 MB - Again is this required, desired for a bare-bones release? Scenery is already at a minimum, so do not see any reduction there... Docs is only 17 MB, but given that most, all of this would also be online, should this be included in a base download package? The top sizes in Docs are - getstart-fr.pdf- 5.4 MB getstart.pdf - 5.4 MB fschool_0.0.3.pdf - 2.9 MB README.YASim.rotor.xls - 337 KB README.YASim.rotor.ods - 236 KB And I guess Sounds, Timezone, Airports, Navaids, Fonts and Nasal are all essential. Anyway, just some thoughts on trying to reduce the initial 'pain' of a new user to be able to quickly get and try FG! And Curt, I hope you can 'publish' your 'scripts' somewhere, to help others like me generate a Windows setup install exe... Regards, Geoff. On Wed, 2013-01-30 at 07:20 -0600, Curtis Olson wrote: FYI, the first windows 2.10 release candidate has been posted. It hits the ibiblio.org and kingmont.com mirrors first and then propagates as the other mirrors run their scheduled syncs. http://www.flightgear.org/news/flightgear-v2-10-release-candidates/ James, let me know when there's something ready to go on the MacOS side and I'll update the 2.10 RC info page. Thanks! Curt. On Wed, Jan 30, 2013 at 4:11 AM, Erik Hofman e...@ehofman.com wrote: On 01/30/2013 08:10 AM, Renk Thorsten wrote: It does run on my Win 7 laptop with nvidia graphics hardware (and nvidia graphics drivers installed.) I will get it uploading ... 740Mb! So much for the CD distribution. :-) Didn't Bill Gates famously say 640Mb should be enough for anyone? Um... which reminds me - I had on my old computer a bunch of obsolete cloud models and textures flagged and done long-term testing that they really aren't used - that's probably 20-30 MB worth of files that can go. In all the confusion migrating to a new machine I forgot about that - do you want me to look for that list? Doesn't really get us to CD size, but still... Are the Winter textures still needed? Erik -- http://www.adalin.com - Hardware accelerated AeonWave and OpenAL for Windows and Linux -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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_d2d_jan ___ Flightgear-devel mailing list
Re: [Flightgear-devel] Model shader for Atmospheric Light Scattering
Hi Thorsten, I've just pushed the first version of the model shader for Atmospheric Light Scattering. Nice job, looking forward to some morning/evening flights! :-) As I said previously, aircraft maintainers, please consider using this effect/inserting the attributes to get the normal map right. Could you please add some instructions to http://wiki.flightgear.org/Aircraft_maintenance? Cheers, Gijs -- 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_d2d_jan___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Release candidates
On Thu, 31 Jan 2013 13:49:18 +0100, Geoff wrote in message 1359636558.2578.5.camel@DELL02: Hi Curt, Downloaded 2.10 RC1 - Wow over a 20 minutes even at about 550 MB/s, but I guess all good things come with a little pain ;=)) ..here, you build on your own makefg script? (http://geoffair.org/tmp/makefg ) But noted you 'forgot' to adjust the default install folder - it still reads C:\PF\FlightGear-2.8.0.4 as the default install folder. And likewise the name for the default desktop icon. After manually changing those to 2.10.0.1, fgrun loaded fine with the correct paths, and fgfs ran fine in the first quick test using the 777-200... Will naturally report any bugs found... The 740 MB setup exe expands to 1.4 GB on disk... ..the 800MB CDs works on Microsoft boxes? Since I am also interested in producing a RC from my own build curious how you 'separate' the RC data from the git master fgdata. Checked fg/fgmeta but could not find any 'script' to do this... Can you add your 'scripts' to there? Or did I miss something? ... Anyway, just some thoughts on trying to reduce the initial 'pain' of a new user to be able to quickly get and try FG! ..possibly getting your script working in a fresh tree? New people will start with a blank fresh brand new tree, go in there, DL your makefg and run it. ..I tried that with Francesco Brisa's download_and_compile.sh which failed for me, and then I tried your script in that same tree with sh ./makefg -h and found it gets most things right: makefg: Some _VERY_ important 'prefix' items for 'configure'. makefg: *** CHECK THEM CAREFULLY! *** and the FG data path. makefg: PLIB: /usr - version [1.8.5] SKIP ..makefg finds and uses system plib ok, but ignores system OSG, I have: arnt@celsius:~/FG-git$ dpkg -l |grep libplib |fmt -tu ii libplib-dev 1.8.5-6 amd64 Portability Libraries: Development package ii libplib1 1.8.5-6 amd64 Portability Libraries: Run-time package arnt@celsius:~/FG-git$ dpkg -l |grep openscenegraph |fmt -tu ii libopenscenegraph-dev 3.0.1-4 amd64 3D scene graph, development files ii libopenscenegraph80 3.0.1-4 amd64 3D scene graph, shared libs ii openscenegraph 3.0.1-4 amd64 3D scene graph, utilities and examples (binaries) ii openscenegraph-doc 3.0.1-4 all 3D scene graph, documentation ii openscenegraph-examples 3.0.1-4 all 3D scene graph, examples (sources) ii openscenegraph-plugin-citygml-shared 0.14+svn128-1+3p0p1 amd64 libcitygml OpenSceneGraph plugin (shared version) arnt@celsius:~/FG-git$ makefg: OSG:/home/arnt/FG-git/install/OSG301 - *NEW INSTALLATION* to OSG301 ... makefg: BOOST: /usr - version [1.49.00] OK makefg: SG: /home/arnt/FG-git/install/simgear - version [2.11.0] ... makefg: FG: /home/arnt/FG-git/install/flightgear - *NEW INSTALLATION* to flightgear Francesco's download_and_compile.sh uses /home/arnt/FG-git/fgfs makefg: FGRUN: /home/arnt/FG-git/install/fgrun - *NEW INSTALLATION* to fgrun/fgrun makefg: TG: /home/arnt SKIP makefg: ATLAS: /home/arnt/FG-git/install/Atlas SKIP makefg: FGDATA: /home/arnt/FG-git/fgdata - version [2.11.0] SKIP And Curt, I hope you can 'publish' your 'scripts' somewhere, to help others like me generate a Windows setup install exe... ..hear, hear. ;o) One way this could be done, is set up an .exe that installs a build script, or some FG-builder program. Being able to make newbie Windroids Simply click the button, would make Wintendo support _much_ easier. -- ..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. -- 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_d2d_jan ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Release candidates
On Thu, Jan 31, 2013 at 6:49 AM, Geoff McLane ubu...@geoffair.info wrote: Hi Curt, Downloaded 2.10 RC1 - Wow over a 20 minutes even at about 550 MB/s, but I guess all good things come with a little pain ;=)) But noted you 'forgot' to adjust the default install folder - it still reads C:\PF\FlightGear-2.8.0.4 as the default install folder. And likewise the name for the default desktop icon. I believe Fred intentionally chose to use the same registry key from one version to the next. Thus if you install a new version over the top of an existing version it will end up in the same path under C:\PF If you uninstall the old version first (maybe?) or are installing from scratch on a new system, it should pick the expected install directory. Since I am also interested in producing a RC from my own build curious how you 'separate' the RC data from the git master fgdata. There is a make target in the flightgear top level make that cherry picks all the pieces we want to go into the distributed 'data' package. Regards, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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_d2d_jan___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] fgviewer preview
Hi, I've just pushed some model-loader tweaks, to support the same 'no preview' tags which FGRun supports, for viewing models. Currently only 'fgfs --fgviewer' mode sets the requisite flag, 'fgviewer' probably should but I need to check with Mathias what's a suitable way to control it, since I guess always-on may not be desired. The changes hide / omit mesh objects which are tagged 'nopreview'; especially, Rembrandt-related lighting volumes are skipped. This is important since otherwise the light volumes confuse osgViewer's bounding-box computation, and hence the rotation centre and initial scale of the model are very wrong. With the changes, --fgviewer mode is usable again with the c172p, f-14b at least. Now, the big question - I was looking at this to restore the Mac launcher's preview mode. I could cherry pick these commits to the release branch, but I want to be cautious, since the model loader is kind of fundamental :) All the code is guarded with an 'if (previewMode)', so I am reasonably confident it can't regress anything else. Or I can wait until 2.10 is out, and then cherry pick to the branch to make a 2.10.1 for Mac with working preview mode - that would be the paranoid solution! Comments / feedback? James -- 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_d2d_jan ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Release candidates
Hi Curt, Thanks for the reply. I believe Fred intentionally chose to use the same registry key from one version to the next. Ok, that's understandable... my last install was 2.8.0.4, but I wanted them separated... not over-written... But then not sure why not choose just C:\PF\FlightGear which is where an earlier version was put... But maybe you are right, if I uninstall the current FOUR(4) versions I have installed, it may choose just '/FlightGear/'... So please forget that I used the word 'forgot' ;=)) There is a make target in the flightgear top level ... And assume the 'make' target is $ make package, or $ make package_source which seem to be the only possible targets shown for $ make help But running the first with -n seemed only to do the binaries, no data, and the second seemed to only be regarding fg source, again not fgdata... So maybe I do not quite understand ;=(( Regards, Geoff. -- 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_d2d_jan ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Release candidates
On Thu, 31 Jan 2013 19:07:25 +0100, Geoff wrote in message 1359655645.2578.10.camel@DELL02: Hi Curt, Thanks for the reply. I believe Fred intentionally chose to use the same registry key from one version to the next. Ok, that's understandable... my last install was 2.8.0.4, but I wanted them separated... not over-written... But then not sure why not choose just C:\PF\FlightGear which is where an earlier version was put... But maybe you are right, if I uninstall the current FOUR(4) versions I have installed, it may choose just '/FlightGear/'... ..one of the things I suggested waaay back, before cmake, is: On Sun, 1 Feb 2009 21:30:20 +0100, Arnt wrote in message 20090201213020.29336...@a45.fmb.no: On Sun, 1 Feb 2009 16:41:40 +0100, Melchior wrote in message 200902011641.41...@rk-nord.at: * Curtis Olson -- Friday 30 January 2009: The traditional unix scheme, and most linux packaging schemes, assume only one version of the software at one time. [...] ..name caller idea from brlcad-7.14.0's ./configure --help: Program names: --program-prefix=PREFIXprepend PREFIX to installed program names --program-suffix=SUFFIXappend SUFFIX to installed program names --program-transform-name=PROGRAM run sed PROGRAM on installed program names ..these differ from its path names: Installation directories: --prefix=PREFIX install architecture-independent files in PREFIX [/usr/brlcad] --exec-prefix=EPREFIX install architecture-dependent files in EPREFIX [PREFIX] ..if this is possible with cmake, you could put all your binaries in the same tree and use names like e.g. /usr/bin/arnt's-git-fgfs-with-wood-gasifier-in-the-An2 and /usr/bin/2.10-fgfs-with-charcoal-gasifier-in-the-An2 and use any combination of this and other name schemes with distro packaging to keep things out of each others way, e.g. most people might wanna keep e.g. fgfs-2.0, fgfs-2.4, non-OSG-fgfs-2.4, fgfs-2.6, fgfs-2.8 and a bunch of their latest FG-git builds handy, both for user support and for their own reasons, e.g. to compare new work with older builds. So please forget that I used the word 'forgot' ;=)) There is a make target in the flightgear top level ... And assume the 'make' target is $ make package, or $ make package_source which seem to be the only possible targets shown for $ make help But running the first with -n seemed only to do the binaries, no data, and the second seemed to only be regarding fg source, again not fgdata... So maybe I do not quite understand ;=(( Regards, Geoff. -- ..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. -- 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_d2d_jan ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Release candidates
On Thu, Jan 31, 2013 at 12:07 PM, Geoff McLane ubu...@geoffair.info wrote: There is a make target in the flightgear top level ... And assume the 'make' target is $ make package, or $ make package_source which seem to be the only possible targets shown for $ make help But running the first with -n seemed only to do the binaries, no data, and the second seemed to only be regarding fg source, again not fgdata... So maybe I do not quite understand ;=( My bad, I checked out the wrong revision of that memory from my brain's repository. More recently there is a script in $(FGSRC)/package/ called make-base-package.no-arch.sh Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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_d2d_jan___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] ..cmake macro to find and set up OSG, was: ..subversive ; o) patch, was: OT: makefg and finding OSG in linux
On Fri, 1 Feb 2013 04:19:31 +0100, Arnt wrote in message
20130201041931.748e1...@celsius.lan:
On Fri, 1 Feb 2013 02:28:40 +0100, Arnt wrote in message
20130201022840.5e985...@celsius.lan:
On Thu, 31 Jan 2013 22:05:02 +0100, Arnt wrote in message
20130131220502.2537d...@celsius.lan:
second, you require svn (and cvs?) to do
svn co, that can be done with git svn clone -s, for cvs et
al I'll need to chk, I guess you want your Windroid script
kiddies ;oD to use the one git, not 3 different kindsa svn,
cvs etc to build (the) _one_ Flight Sim.
..subversive ;o) patch:
arnt@celsius:~/FG-git$ ll su* md5sum su*
-rw-r--r-- 1 arnt arnt 4311 Feb 1 00:40
subversion-of-svn-4-makefg-1.3.12a.patch
d02880ea23df9bd982f4f778aa7accc8
subversion-of-svn-4-makefg-1.3.12a.patch
arnt@celsius:~/FG-git$
..motivation, background and recipe ideas:
http://trac.parrot.org/parrot/wiki/git-svn-tutorial
http://stackoverflow.com/questions/3239759/checkout-remote-branch-using-git-svn
http://git.or.cz/course/svn.html
http://www.kernel.org/pub/software/scm/git/docs/git-svn.html
..cvs is a _lot_ messier...
..and I'm still stuck on discovering system OSG.
..I got one step further:
arnt@celsius:~$ osgversion --version-number
3.0.1
arnt@celsius:~$ which osgversion
/usr/bin/osgversion
arnt@celsius:~$
...and found this: ;o)
http://svn.tevs.eu/osgPPU/trunk/CMakeModules/OsgPPUMacroUtils.cmake
..now, where do I the _total_ cmake newbie stick up this?
--
..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.
--- makefg-1.3.12 2013-02-01 00:07:53.196781629 +0100
+++ makefg-1.3.12a 2013-02-01 00:34:16.456595377 +0100
@@ -85,8 +85,9 @@
# 2012-08-07 - Fix to build TG - added SG directory export
# 2012-10-31 - Some fixes to run in fgx.ch - if PLIB_PATH=, set ADDPLIBDIRS
# 2013-01-02 - Fix SG libraries names, and adjust FGRUN cmake step
-SCDATE=2013-01-02
-SCVERSION=1.3.12
+# 2013-02-01 - ..ditch subversion and svn co for git svn clone -s
+SCDATE=2013-02-01
+SCVERSION=1.3.12a
#
# 2009-10-31 - allow option to use alternate OpenAL sources
# OpenAL-Soft 1.9.563 compiled from source from http://kcat.strangesoft.net/openal.html
@@ -460,7 +461,7 @@
install_svn_boost()
{
-svn co http://svn.boost.org/svn/boost/trunk boost-trunk
+git svn clone -s http://svn.boost.org/svn/boost/trunk boost-trunk
if [ -d boost-trunk ]; then
cd boost-trunk
if [ -f bootstrap.sh ]; then
@@ -482,8 +483,8 @@
pgm_exit
fi
cd $CBD/install
- echo2 $BN: Running svn co http://svn.boost.org/svn/boost/trunk boost
- svn co http://svn.boost.org/svn/boost/trunk boost
+ echo2 $BN: Running git svn clone -s http://svn.boost.org/svn/boost/trunk boost
+ git svn clone -s http://svn.boost.org/svn/boost/trunk boost
if [ -d boost ]; then
cd boost
echo2 $BN: Moving boost headers to an 'include' directory...
@@ -2988,7 +2989,7 @@
LIST2=libglut3-dev libopenal-dev libalut-dev libalut0 libfltk1.1-dev
LIST3=libfltk1.1 zlib1g-dev zlib1g libwxgtk2.8-0 libwxgtk2.8-dev
LIST4=libjpeg62-dev libjpeg62 libxi-dev libxi6 libxmu-dev libxmu6
- LIST5=fluid gawk gettext gcc g++ cmake cvs subversion
+ LIST5=fluid gawk gettext gcc g++ cmake cvs
LIST6=git-core curl xlibmesa-gl-dev freeglut3-dev glutg3-dev libglut3-dev xorg-dev
LIST7=libalut-dev zlib1g-dev libtiff4 libtiff4-dev libtiff-tools libtiff-opengl
if [ $DISTRIB_RELEASE = 8.04 ]; then
@@ -3057,7 +3058,7 @@
# PLIB_SOURCE_DIR=plib-1.8.5 OR plib, depending on PLIBTRUNK
# INSTALL_DIR_PLIB=$INSTALL_DIR/$PLIB_SOURCE_DIR
cd $CBD
-#svn co http://plib.svn.sourceforge.net/svnroot/plib/trunk plib
+#git svn clone -s http://plib.svn.sourceforge.net/svnroot/plib/trunk plib
#cd plib
if [ $PLIBADD = 1 ] [ `is_in_args PLIB` -gt 0 ] ; then
echo2 $BN: Processing PLIB ...
@@ -3076,9 +3077,9 @@
fi
else
# need to do a CHECKOUT
- echo2 $BN: PLIB checkout with svn co http://plib.svn.sourceforge.net/svnroot/plib/trunk $PLIB_SOURCE_DIR
+ echo2 $BN: PLIB checkout with git svn clone -s http://plib.svn.sourceforge.net/svnroot/plib/trunk $PLIB_SOURCE_DIR
echo2 $BN: Doing PLIB checkout of trunk ... moment...
- svn co http://plib.svn.sourceforge.net/svnroot/plib/trunk $PLIB_SOURCE_DIR
+ git svn clone -s http://plib.svn.sourceforge.net/svnroot/plib/trunk $PLIB_SOURCE_DIR
PLIBCO=1
echo2 $BN: Done plib checkout. Force SG/FG AUTO and CLEAN
SGAUTO=1
@@ -3215,11 +3216,11 @@
fi
if [ ! -d $OSG_SOURCE_DIR ]; then
echo2 This is a NEW svn download of OSG...
- echo2 CMD: svn co $OSG_SVN $OSG_SOURCE_DIR
+ echo2 CMD: git svn clone -s $OSG_SVN $OSG_SOURCE_DIR
ask
echo2 Doing svn download of OSG ... moment ...
-
Re: [Flightgear-devel] fgviewer preview
Hi, On Thursday, January 31, 2013 17:13:46 James Turner wrote: I've just pushed some model-loader tweaks, to support the same 'no preview' tags which FGRun supports, for viewing models. Currently only 'fgfs --fgviewer' mode sets the requisite flag, 'fgviewer' probably should but I need to check with Mathias what's a suitable way to control it, since I guess always-on may not be desired. You can currently set arbitrary osg loader options by -O 'string option'. Greetings Mathias -- 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_d2d_jan ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear Multiplayer jitter using Matlab/Simulink
Hi, On Monday, January 21, 2013 12:01:54 Yingcai Bi wrote: I am a starter here.I'm doing a university project. I need to control two aircrafts for close formation with two Simulink at the same time. I do as vbnhu's post in viewtopic.php?f=4t=3165p=174710#p174710http://www.flightgear.org/forums/v iewtopic.php?f=4t=3165p=174710#p174710, and met the same jitter problem. One plane flies well and another jitters. fgfs --aircraft=c172p --fdm=network,localhost,5501,5502,5503 --multiplay=in,25,localhost,5701 --multiplay=out,25,localhost,5702 fgfs --aircraft=c172p --fdm=network,localhost,5507,5508,5509 --multiplay=in,25,localhost,5702 --multiplay=out,25,localhost,5701 Then, I tried the LAN fgms, There are two computers for two simulink controlled fgfs, one computer as the fgms. There is still the jitter problem. Now, I find the implementation of network control with simulink in viewtopic.php?f=36t=16200http://www.flightgear.org/forums/viewtopic.php?f= 36t=16200 . I wonder if I must implement the multiplayer protocol in simulink and if the jitter problem can be avoided. Any suggestion from anybody? Thank you,all. If you relay one aircraft by the net fdm and then the multiplayer you will add some latency just by that store and forward. This is then made worse and jittery by the main loop doing this store and forward controled by the independent frame rates of those both simulations and not by any simulation time slices. The input of the net fdm is also not time slice synchronized - at least if I remember right. Then on top of that the incomming multiplayer code tries to even out jitter in the incomming multiplayer packets which accounts for some extra latency that will probably hurt your application too. I am currently working on something that will probably arrive too late for you if you need that about now. The hla components will enable correct time slicing over more participants and components. May be for your particular case: If your simulink models live in the same matlab, it could help if the data for both aircraft is sent by the same atomic network packet. But that also involves hackery in matlab as well as in flightgear. Greetings Mathias -- 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_d2d_jan ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
