Re: [Flightgear-devel] Default 3d clouds in Local Weather
Hi Stuart, I'd really like the 3D cloud infrastructure to be used for all the clouds, so if there are features missing we should address them. Would it be possible to modify the 3D clouds so that they can be used for the rain texture as well? For example, I could provide a sprite distribution on the surface of a cylinder rather than a sphere if that would help. Just a short answer to this part: All these objects (rain textures, Cirrus clouds,...) do not use the 3d cloud infrastructure because they are not 3d clouds. Cirrus and Cirrocumulus clouds are textures projected on a non-rotated but cruved surface (a bit like a saddle) - I see no straightforward way to get that with a shader, and I've never made any attempt work to render them as true 3d objects. (Technically, the reason is that they show fine detail with large variation, so cloudlets need to be large, and a preferred direction for the feathers - so whenever you rotate them, it shows immediately). Also in the literature, I haven't seen anyone who claimed to have generated true, rotating 3d Cirrus clouds). Cirrostratus and the larger Cirrocumulus don't have that problem, as they don't show preferred direction and have less fine detail - for those I needed z-scaling. Rain doesn't use a 3d but a 2d cylinder billboard rotation - I suppose that can be adapted to use with the shader easily enough by passing a parameter that tells which rotation is to be used if we want to do that. * Thorsten -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
Hi Mathias, On 10 Sep 2011, at 10:57, Mathias Fröhlich wrote: Hi, Ok, then it's probably best to deinstall the distros cmake and install cmake from sources. Or may be cmake has some binary distributions that fits your needs. Thanks for your suggestion (and to Fred as well). All things considered, I decided that it would be time to bite the bullet and to a full system upgrade from opensuse 10.0 to 11.4. The upgrade is proceeding smoothly, and I'm currently compiling OpenSceneGraph SVC/trunk. I hope that FlightGear will behave nicely with the xinerama xserver configuration, because I'm running kde4, which apparently doesn't like multiple monitor configurations that much (last time I checked there were some performance / stability issues, but that was 3 years ago...). I'm also taking this opportunity to try out a few new things. A couple of years ago I had already switched from emacs to kdevelop for editing, but now with cmake, it looks like it's also very easy to generate kdevelop compatible project files. Maybe that was already possible with autoconf, but I never really tried it. Cheers, Durk -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
Hello,
Am 11.09.2011 09:57, schrieb Durk Talsma:
[..] I hope that FlightGear will behave nicely with the
xinerama xserver configuration, because I'm running kde4, which
apparently doesn't like multiple monitor configurations that much
I'm using a double monitor setup here with 11.4/KDE4 configured via
xrandr without any problems, so that looks stable by now.
I'm also taking this opportunity to try out a few new things. A
couple of years ago I had already switched from emacs to kdevelop for
editing, but now with cmake, it looks like it's also very easy to
generate kdevelop compatible project files. Maybe that was already
possible with autoconf, but I never really tried it.
one problem I noticed with that is that the headers aren't added to the
project in SimGear. At least Codeblocks is not able to add them
automatically parsing the includes, so the attached patch does that
explicitly. This allows things like jump to definition also for
header-only classes, which up to now produces errors. Apart from that,
I'm doing fairly well with the generated CB projects. Haven't tried
kdevelop, though.
While we're at it, FindOpenSceneGraph.cmake claims it was added in CMake
2.6.3, while SimGear's CMakeList only has cmake_minimum_required(VERSION
2.6) , so this should be updated (maybe directly to 2.8?).
Yet another thing: when trying to build with CMAKE_BUILD_TYPE
RelWithDebInfo or MinSizeRel, the FlightGear build will fail unless you
have SimGear libraries in Release configuration still around (against
which it will link, but not against the matching configuration). This is
because SelectLibraryConfigurations.cmake only knows about Debug and
Release. Fixing this might however be a bit tricky, and I don't know how
many people are actually going to use these build types. Maybe a warning
about an unsupported build type is sufficient. As a fallback it is
always possible to alter CMAKE_CXX_FLAGS directly.
Best regards,
Andreas
commit 8334007d6a1f7b9831fd1fd8813dc6752f042c10
Author: Andreas Gaeb a.g...@web.de
Date: Fri Sep 9 21:28:37 2011 +0200
Add headers to library components
so that they get included into the IDE project files
diff --git a/CMakeModules/SimGearComponent.cmake b/CMakeModules/SimGearComponent.cmake
index 3eb5740..7dbf5f1 100644
--- a/CMakeModules/SimGearComponent.cmake
+++ b/CMakeModules/SimGearComponent.cmake
@@ -14,7 +14,7 @@ macro(simgear_component name includePath sources headers)
else()
set(libName sg${name})
-add_library(${libName} STATIC ${sources} )
+add_library(${libName} STATIC ${sources} ${headers})
install (TARGETS ${libName} ARCHIVE DESTINATION lib${LIB_SUFFIX})
install (FILES ${headers} DESTINATION include/simgear/${includePath})
--
Using storage to extend the benefits of virtualization and iSCSI
Virtualization increases hardware utilization and delivers a new level of
agility. Learn what those decisions are and how to modernize your storage
and backup environments for virtualization.
http://www.accelacomm.com/jaw/sfnl/114/51434361/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
Christian Schmitt wrote: I have used CMake in the Gentoo packages pretty much from the start, but right now I'm experiencing some problems: all is good as long as I have libsvn support enabled in SG and FG. When I disable it in SG and want to recompile FG afterwards (also disabled, of course), I get a linking error for Terrasync: This is now solved with the latest FG git version. Thanks! -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] substantial base package size increase
Curt, We could retire the old .png textures where these have been replaced by .dds. That would more or less restore the old package size. However, unless the issue is really pressing I would recommend waiting a while until it's all thoroughly bedded in. I also see that new aircraft have been added to fgdata. Tim requested a while back that new aircraft should be placed in their own repo. Doing this should prevent the data from growing significantly. We could move existing aircraft to their own repos bit by bit which will significantly reduce the size of fgdata. Vivian -Original Message- From: Curtis Olson [mailto:curtol...@gmail.com] Sent: 10 September 2011 15:39 To: FlightGear developers discussions Subject: [Flightgear-devel] substantial base package size increase I just noticed when I pushed out the latest developer snapshot build that our setup.exe size has grown from about 410 Mb to 500+ Mb. I think (?) this may be the new dds textures? I'm not making a judgement, or calling for a particular action here, but it might be worth thinking/discussing if there is a way to push the size back down, or are we ok with 500Mb+ (1/2 a Gb) on our setup.exe size? Thanks, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CHMOD 0755 on some files
On Sun, 2011-09-11 at 12:13 +0200, Roland Häder wrote: Hi, with recent commit there have been changed CHMOD from 0644 to 0755 on some files. Here is the full list I have seen: I seem to recall this happened to me before, how does that happen? I've just copied them from the JSBSim source files and would have expected the mode to be unchanged. Erik -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
Hi, On Sunday, September 11, 2011 12:55:33 Christian Schmitt wrote: This is now solved with the latest FG git version. Thanks! Ok, thanks, I was on the way asking for that :) Mathias -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CHMOD 0755 on some files
2011/9/11 Erik Hofman e...@ehofman.com: On Sun, 2011-09-11 at 12:13 +0200, Roland Häder wrote: Hi, with recent commit there have been changed CHMOD from 0644 to 0755 on some files. Here is the full list I have seen: I seem to recall this happened to me before, how does that happen? I've just copied them from the JSBSim source files and would have expected the mode to be unchanged. Erik The script admin/jsb2fg uses the unix command 'cp -p' that preserves the chmod of the source file. Since these files have the incorrect chmod in JSBSim CVS, then it affects FlightGear as well. Execution flags have been corrected in the git repositories of JSBSim but it seems nobody knows how to fix that in CVS ? Bertrand. -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CHMOD 0755 on some files
On Sun, 2011-09-11 at 13:16 +0200, Erik Hofman wrote: I seem to recall this happened to me before, how does that happen? I've just copied them from the JSBSim source files and would have expected the mode to be unchanged. Hi, do you use Windozer or so? If yes, that might be the reason. When Windows copies, creates or just saves files, the permissions got set to 0755 on files and 0777 for directories. I know a way for Subversion to prevent this. It is called 'auto-properties', maybe also GIT provide this? Okay, I have to go now. Ice hockey is starting in one hour and I want to meet my friends before it. Regards, Roland signature.asc Description: This is a digitally signed message part -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] In air and on ground start-ups. (JSBSIM)
Does anyone have a simple recipe or set of rules for making a JSBsim turbine engine set running for an in-air start and not-running for an on-ground start? The in-air trim works fine, but it takes a long time to start the engines once the aircraft is released. I have been able to make my engines running at start-up, but don´t want this to be the case when FG is initialised, or re-set, on the ground. Any clues, or a pointer to an example aircraft, would be welcome. TIA Alan-- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RE : Cmake
Oops. - Mail original - The Cmake build for windows with VS2010 is now operational on jenkins. I am not interested in speed comparisions between the build created by Err (embarassing) : I am noW interested in speed comparisons ... 'Win32-installer' (vs2008) and 'Win32-installer-Cmake' (vs2010). The current vs2008 build and project will live until 2.6 is released, which should be based on the new build/compiler. After that it will be deprecated and removed from the repository. Regards, -Fred Le 05/09/2011 18:31, Frederic Bouvier a écrit : My intention is, with the help of James and Gene, to convert the current Jenkins build to VS2010 and Cmake in the next few weeks. Cmake and VS2010 combinaison has always worked for me, and I am interested to here about issues. Regards, -Fred Alan Teeder ajtee...@v-twin.org.uk a écrit : Please don´t. I reverted from VC100 to VC90 as the Cmake process was always failing. There is a difference between Hudson saying that all is OK with Cmake and Visual Studio VC100 producing working executables. This was all with the de-facto standard 3rd party package from ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/MSVC/. I could get the system to work, but then it would all go wrong after a few days or weeks. On the other hand the current VC90 project files seem quite robust. Just my experience. -- Frédéric Bouvier http://www.youtube.com/user/fgfred64 Videos -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Links for new FlightGear pilots
Hi Stuart Thanks - that offer was a nice surprise Surely I want to work together with all of you to get the best, up to date Manual/PDF possible. And surely I am highly interested in integrating what I have into any company-wide release system. joacher@gm.. now proposed the link to www.lyx.org and I had a short look: - seems you can even import HTML into that system - and sftw.-download for UBUNTU is available (ver.2.0.0) So I will have a closer look next week and try what I can do with it. In parallel I am still in the final review of my proposal (wording, spelling, comparing EN/DE, links, etc) - hope to have that done within the next 2 weeks - and surely you can help improving - I will check how to grant excess (either on my UBUNTU-cloud or homepage). Pls see my answers to your points inserted in the following. I am positive we can arrange a common understanding and work-line. I am looking forward to it! joe On Sat, 2011-09-10 at 00:05 +0100, Stuart Buchanan wrote: On Mon, Sep 5, 2011 at 2:45 PM, I wrote: More comments when I get the time once I'm back. Hi Jomo, I finally got the time to look at your work in detail. I think there's a lot of really good work here, and it obviously represents a lot of time and effort. Thanks again. I _really_ like a number of things you've done with the structure. The following comments look at what you've done as a contrast to the existing Manual, and with a view to changing The Manual: 1) The Briefing section (which covers some of the Take-off and In-Flight sections of the existing manual) looks like it is designed to get the first time FGer up and running quickly. I really like it as a concept, and it's something that the existing Manual doesn't provide. I think it goes into a bit too much detail (e.g. covering the keyboard XML format), and could be cut down still further to provide a simple introduction to choosing and aircraft, airport and setting the time/weather for a flight, along with an introduction to the controls. My basic thought was indeed (see Start - For the most impatient (uuups: I just notice: My wording there is not perfect)): If the new guy has installed FlightGear by whatever means - let him start exercising it - and have the referencing system explain him any questions popping up. i.e. start with SOLO Flight as a first introduction. That way I hope to keep his attention - which i am afraid will not last long when I first try to explain all the Basics. I am even thinking about putting the Installation + Briefing into the Appendix and just start with Solo! That other stuff is boring - let him start with using and then explain him what he then, later may want to know! The whole FlightGear principle is like that: Start with one small area and a few aircraft - he will then develop his appetite for more some time - for sure! And then he will look for those infos! I know: That is not how you (should) study something - but most of our customers are young and want to fly - not study! And somehow I understand those people: I always was more the trying then the theory guy! So I could imagine to structure like: 1) Start as is 2) Flight-Manuals (Solo up to Features + Briefing 1st part Starting Up only 3) Technical References (Installation + Briefing-rest) 4) Appendix mostly as is Did I shock you now ??? 2) The First Solo complements the existing tutorials well. Nice work! 3) Moving some of the detailed reference material (e.g. command-line options) to an appendix makes a lot of sense. 4) Your work highlights the importance of providing better navigation between sections. We should certainly be looking at how we can improve navigation within the HTML version of The Manual. It would be great if we could have each chapter in the bar on the top, along with a section drop-down to provide straightforward navigation. Taking a step back, IMO there should be three separate sections to The Manual: a) A Getting Started Guide b) A Reference Guide c) Tutorials In fact I think that was the plan ages ago, but initially only the first was created (hence the filename - getstart.pdf), and over time its scope expanded to cover all three. At present the first two are combined, but your work shows that we really should be separating them more, so that the first Getting Started section covers the basics, and provides references to the detailed documentation in the Reference Guide. I am not sure what those initially thought areas actually should have covered, seeing it from today i would suggest 3 FlighTgear-Manuals 1) Flying: We are working on it. Here I would suggest a Manual! 2) Designing and modeling: I could see it going through some modeling-examples and by that introducing the existing programs, procedures, books and wikis. It should cover the whole design aspects and may even include the Program itself. Not a programming manual - but something showing the major tools in action - and where to start and
[Flightgear-devel] Display existing path?
Is there any easy way to show a prior route in Flightgear? In other words, if I have a set of recorded GPS points (lat,long, alt) in a text file can I display them in 3-D space, as I am flying in flightgear? Ideally I would like points (some box or sphere icon?) connected with line segments. There are three different approaches that occur to me, so I figured I would check if anyone has done anything like this, and see if anyone can offer any guidance. 1) It is probably possible to generate some custom scenery that has my desired path as custom made objects. But this seems like it is likely the most difficult approach? 2) It seems likely that it could be done with nasal, but I have really not done any nasal coding. One approach might be to hard code a bunch of objects, representing points, in the right locations into a nasal file. This is not very flexible, as each nasal script would be for a given single path. 3) Finally, what seems most general would be to write some code in nasal that can read in a csv file, and then to display objects in those locations. Is this feasible? Can nasal import a csv file or other general file format that could contain points? If any of you have any existing code, or suggestions, I would love to hear it. Thanks, --Adam -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
Hi Andreas, On 11 Sep 2011, at 12:18, Andreas Gaeb wrote: one problem I noticed with that is that the headers aren't added to the project in SimGear. At least Codeblocks is not able to add them automatically parsing the includes, so the attached patch does that explicitly. This allows things like jump to definition also for header-only classes, which up to now produces errors. Apart from that, I'm doing fairly well with the generated CB projects. Haven't tried kdevelop, though. Thanks for sharing your experiences. After having played with the new kdevelop, my first impression is leaning toward the positive side, but not completely positive. I like the enhanced editing, and online syntax checking. Particularly, the context sensitve list of suggested completions is really handy. But, some other options, like the kdevelop definition of a current project selection is slightly awkward, and I also found that the integrated cmake is slightly awkward when you choose a build location other than the default. But, given that I have been learning as I went, it's probable that I left a trail of garbage behind. So, I might restart from scratch and take it from there. While we're at it, FindOpenSceneGraph.cmake claims it was added in CMake 2.6.3, while SimGear's CMakeList only has cmake_minimum_required(VERSION 2.6) , so this should be updated (maybe directly to 2.8?). I thought that Fred mentioned on the mailing list the we only officially support cmake 2.8.0 and higher. Yet another thing: when trying to build with CMAKE_BUILD_TYPE RelWithDebInfo or MinSizeRel, the FlightGear build will fail unless you have SimGear libraries in Release configuration still around (against which it will link, but not against the matching configuration). This is because SelectLibraryConfigurations.cmake only knows about Debug and Release. Fixing this might however be a bit tricky, and I don't know how many people are actually going to use these build types. Maybe a warning about an unsupported build type is sufficient. As a fallback it is always possible to alter CMAKE_CXX_FLAGS directly. Which actually brings me to the next question: I'm currently trying to build a heavily optimized version of FlightGear, and want to pass a number of options cmake. I got the basic mechanism to work; i.e. -D CMAKE_CXX_FLAGS=-O3 -Wall. But, in my autoconf based compile script, I pass an option containing an equals character (i.e. =_). When I try to pass that to cmake, using for example: -D CMAKE_CXX_FLAGS=-O3 -Wall -march=native, if found that the entire token containing the = character, as well as all the tokens following it, are ignored. I've tried most of the known unix tricks to escape the = character, but to no avail. Any ideas? Cheers, Durk -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
2011/9/11 Durk Talsma durkt...@gmail.com: Which actually brings me to the next question: I'm currently trying to build a heavily optimized version of FlightGear, and want to pass a number of options cmake. I got the basic mechanism to work; i.e. -D CMAKE_CXX_FLAGS=-O3 -Wall. But, in my autoconf based compile script, I pass an option containing an equals character (i.e. =_). When I try to pass that to cmake, using for example: -D CMAKE_CXX_FLAGS=-O3 -Wall -march=native, if found that the entire token containing the = character, as well as all the tokens following it, are ignored. I've tried most of the known unix tricks to escape the = character, but to no avail. Any ideas? Cheers, Durk Have you tried to append your flag with :STRING ? It should look like -D CMAKE_CXX_FLAGS:STRING=-O3 -Wall -march=native. Cheers, Bertrand. -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
On 11 Sep 2011, at 20:25, Bertrand Coconnier wrote: Have you tried to append your flag with :STRING ? It should look like -D CMAKE_CXX_FLAGS:STRING=-O3 -Wall -march=native. Not yet, but I'll certainly give it a try. Thanks! Cheers, Durk -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
On 11 Sep 2011, at 13:18, Mathias Fröhlich wrote: Hi, On Sunday, September 11, 2011 12:15:42 Durk Talsma wrote: -- Configuring incomplete, errors occurred! I don't get that hard error, but I have checked in something that fixes similar symptoms. So, could you retry? Hi Mathias, My error was in SimGear, and your fix was for FlightGear, it I'm correct. So, I'm not sure if that would fix it. Cheers, Durk -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Display existing path?
Hi Adam, This has been something I thought would be a nice feature too. It should be possible. I've placed other models using nasal to create interesting scenes. It would be kind of cool for simulated UAV work to see your exact waypoint target in 3d space. Curt. On Sun, Sep 11, 2011 at 12:30 PM, Adam Dershowitz, Ph.D., P.E. wrote: Is there any easy way to show a prior route in Flightgear? In other words, if I have a set of recorded GPS points (lat,long, alt) in a text file can I display them in 3-D space, as I am flying in flightgear? Ideally I would like points (some box or sphere icon?) connected with line segments. There are three different approaches that occur to me, so I figured I would check if anyone has done anything like this, and see if anyone can offer any guidance. 1) It is probably possible to generate some custom scenery that has my desired path as custom made objects. But this seems like it is likely the most difficult approach? 2) It seems likely that it could be done with nasal, but I have really not done any nasal coding. One approach might be to hard code a bunch of objects, representing points, in the right locations into a nasal file. This is not very flexible, as each nasal script would be for a given single path. 3) Finally, what seems most general would be to write some code in nasal that can read in a csv file, and then to display objects in those locations. Is this feasible? Can nasal import a csv file or other general file format that could contain points? If any of you have any existing code, or suggestions, I would love to hear it. Thanks, --Adam -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
On Monday 05 September 2011 10:10:27 Curtis Olson wrote: Are there any cmake based build instructions available anywhere? I'm not seeing them. I'm just hoping the cmake jocks will put themselves in the position of non-cmake jocks and help ease the transition from multiple fronts for many of our different classes of users/developers. Thanks! Curt. Let me echo what Curt said. I don't like CMake that much, because it seems overly complicated. HOW DO I BUILD FLIGHTGEAR NOW? Thank you, Ron -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [OT] B-29 touring Oklahoma and Texas
I've been travelling on business for a while and have one week more on the road, so I was both excited and distressed to see and email from my boss that said the only flying B-29 will be in Stillwater, OK on Tues Sept 13. Why they chose a stop in Stillwater, I'm not sure. Maybe because of its history as an air depot in WWII and a place where some 470-something WWII warbirds were parted out for scrap after the war (google Searcy Field). Or maybe it's just a convenient stopover on the way from Nebraska to Texas. Their continuing schedule takes them to various cities in Texas over this month. Seats are available for flying tours (I can't afford them). See the link below: http://www.cafb29b24.org/rides/ride-in-the-only-b-29.html -Reagan -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New experimental mapserver
On Friday 09 September 2011 11:33:17 Curtis Olson wrote: Hi Yves, The general approach that genapts uses this. ... We get to pick the order we process the airport surface objects, so we pick the runways first, and probably the biggest runways before the smaller runways. Then the bigger taxiways before the littler taxiways, etc. Biggest/most important to smallest, least important. ... This is actually incorrect handling. Taxiways should be processed in order they appear in the 8.10 data file. I believe it has been fixed in Terragear-cs to behave this way. A heuristic approach based on size prevents an airport artist from using the taxidraw ordering feature from hinting at the correct orientation. You don't always want the longest taxiway on top. Ron -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
On Sun, Sep 11, 2011 at 7:47 AM, Thorsten Renk wrote: I'd really like the 3D cloud infrastructure to be used for all the clouds, so if there are features missing we should address them. Would it be possible to modify the 3D clouds so that they can be used for the rain texture as well? For example, I could provide a sprite distribution on the surface of a cylinder rather than a sphere if that would help. Just a short answer to this part: All these objects (rain textures, Cirrus clouds,...) do not use the 3d cloud infrastructure because they are not 3d clouds. Thanks for the explanation. Doesn't look like there's much benefit from hacking the 3D clouds system to do something it's not intended to. So... that leaves fixing the underlying problem. The problem definitely seems to be that any other objects in the scenery with an alpha layer are rendered after the clouds, so are rendered in front of them, irrespective of the viewpoint and their relative positions. By removing the alpha layer from the texture of the stratosphere-tower in Las Vegas, I was able to work around the problem. Unfortunately, fixing this is going to require someone with more knowledge of OSG than I have. The problem is that the 3D clouds are in an earlier rendering bin from the scenery models with transparent textures, which means that the clouds are rendered first in their entirety, and then the scenery models, with no consideration of the relative position (i.e. depth) compare with the clouds. This was done for perf reasons. Putting the clouds in the same rendering bin (i.e. TRANSPARENT_BIN) halves the framerate on my system. I'm not sure there is a fix for this that doesn't massively impact performance, unless we add some of these objects to the CLOUDS_BIN and then depth-sort them within the cloud code itself which depth-sorts slowly across multiple frames to avoid exactly the performance hit from depth sorting the entire TRANSPARENT_BIN in each frame. Tim/Matthias - care to comment? Thorsten - FYI I've committed an update the README.3DClouds which documents the recent changes (z-scaling, changed defaults etc.) I've also got a merge request in to fix the flat field cloud placement bug. -Stuart -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Frame rates in git version?
Sometime in the last week I noticed the Flightgear frame rates on my machine went to about 1/3 of what they were previously. I haven't worked super hard on this, but here's what I can say. When I fire up the Cub at --airport=KANE with clear skies I get: v2.4 = 90 fps (bounces around a bit but usually 90 or above) git = 20-25 fps (same options, same aircraft, same clear skies.) This gets even worse when I fly the f-14b off the Vinson ... even out at sea with just a few clouds it seems like my frame rates are usually less than 20 (12-17 range) with the git version. Has anyone else noticed this or should I be looking for a local build problem? It doesn't seem to be related to my video driver update since v2.4 runs with the frame rates I expect. I recently moved over to trying to build with cmake by default, but cmake hides the compile options so I honestly don't know how to even check what compile options I'm building with now that I switched to cmake. Can anyone tell me how to figure that out? Is there a detailed build log that gets saved somewhere? Thanks, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Frame rates in git version?
Curtis Olson wrote: I recently moved over to trying to build with cmake by default, but cmake hides the compile options so I honestly don't know how to even check what compile options I'm building with now that I switched to cmake. Can anyone tell me how to figure that out? Is there a detailed build log that gets saved somewhere? Add -D CMAKE_VERBOSE_MAKEFILE=TRUE and you'll get verbose output, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Frame rates in git version?
Hi Curt, based on my experience with building FlightGear from yesterday, I'd say that cmake is a great tool and most likely a step forward. But. it does take a little getting used to, in particular the finer details of compiler optimizations, etc etc. I'll try to post my more details about my experiences this evening (I'm not in front of my development machine right now). FWIW, after my initial build, I also got very disappointing performance, but after running a second build with all the settings right, I did got performance levels that I think were even better than what I had before (note, that in addition to switching for cmake, I also installed a complete new distributions) Cheers, Durk On 12 Sep 2011, at 05:07, Curtis Olson wrote: Sometime in the last week I noticed the Flightgear frame rates on my machine went to about 1/3 of what they were previously. I haven't worked super hard on this, but here's what I can say. When I fire up the Cub at --airport=KANE with clear skies I get: v2.4 = 90 fps (bounces around a bit but usually 90 or above) git = 20-25 fps (same options, same aircraft, same clear skies.) This gets even worse when I fly the f-14b off the Vinson ... even out at sea with just a few clouds it seems like my frame rates are usually less than 20 (12-17 range) with the git version. Has anyone else noticed this or should I be looking for a local build problem? It doesn't seem to be related to my video driver update since v2.4 runs with the frame rates I expect. I recently moved over to trying to build with cmake by default, but cmake hides the compile options so I honestly don't know how to even check what compile options I'm building with now that I switched to cmake. Can anyone tell me how to figure that out? Is there a detailed build log that gets saved somewhere? Thanks, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
