Re: [Flightgear-devel] heads up: FlightGear release plan
Hi, since there were no major objections to the release plan, we're proceeding as proposed. Current status: * We've officially grounded the releases/2.2.0 git branches yesterday. The flightgear/simgear releases/2.2.0 branches were merged back to master (not next! master always contains the latest release). However, as proposed, we won't invest any more time into 2.2.0, so there'll be no binaries on the download page, no updated aircraft downloads, no announcements, etc. * git/next is bumped to version 2.3.0 now. Actually we should have done so when we branched releases/2.2.0 in January. Remember. it's odd minor versions for the developer version now (git/next), even minor numbers for releases. * Hudson is prepared for providing release binaries and installers (thanks James!). Once we create a new release branch, Hudson should start building the binaries/installers (see Hudson's Windows-release, Mac-release, Linux-release projects). As usual, these will be updated hourly. We'll also provide complete Win/Mac installers (including fgdata base package) regularly, maybe about weekly, so these can be used for wider beta testing. We can't include the base package in the _hourly_ installers though, due to bandwidth/size limits (almost 400MB for the fgdata base package). * We also started assessing tracker issues (thanks Gijs!). Some were already fixed in the last days. And it doesn't look too bad, few issues are highly critical. However, there are some areas where we're missing people, for example for some (new) FDM, and a number of ATI-graphics issues. Have a look at the tracker: http://code.google.com/p/flightgear-bugs/issues/list Finally, as a reminder now: Only 4 more weeks to 2.4.0 feature freeze, remember June 17th, when we'll close sg+fg next branch, and (!) fgdata master for 4 weeks. Only bug fixes should be committed after June 17th. releases/2.4.0 will be branched on July 17th, when the main developer branches will be bumped to 2.5.0 and reopen for new features. Beta testing for 2.4.0 will continue for another month after that, till August 17th. But all this was already described in the release plan http://wiki.flightgear.org/Release_Plan cheers, Thorsten On Do, 2011-05-19 at 14:29 +0200, Torsten Dreyer wrote: Hi everybody, during this year's LinuxTag, Martin Spott, Mathias Fröhlich, Thorsten Brehm and myself developed a strategy and a concept about how to kick out new releases of FlightGear on a regular schedule. Please find our first draft here: http://wiki.flightgear.org/Release_Plan For the impatient reader, this is the abstract: We plan to have two releases per year, one in February, one in August. The first scheduled release following this concept will be 2.4.0 in August this year, 2.6.0 is scheduled for February 2012. If no major objections arise, we will set the version number on the current development stream to 2.3.0 and will call out a feature freeze on June 17th. Any comment and certainly any help for actually preparing the release is welcome. Thanks, Torsten -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] fgdata merge request 91:Animated Jetways
I apologize for not raising this discussion *before* I filed that request, as I should have. From the comments on http://gitorious.org/merge_requests/91: In the past we've been struggling for more than one and a half release cycles in order to separate Scenery-specific stuff from the Base Package and to draw a clear line. Now you’re doing almost exactly the contrary: Introducing new dependencies between Scenery and Base Package by putting airport specific stuff into the FlightGear ‘Airports/’– as well as into the shared models directory. This stuff belongs into the Scenery directory structure. I can see why introducing a dependency could cause some problems. However, due to the technical details of the new jetways, it is not possible to integrate them with Terrasync/Shared models as it was previously. This is because the jetways are specified in an XML file for each airport that a Nasal script parses and loads models for via fgcommand(add-model, ...). That's how each jetway knows its independent position and its relative location to the aircraft door, unlike a static model in scenery where this is not possible. Additionally, the 3d models have to be stored somewhere. By my logic, that should be in Models/Aiport, hence the new directory. I intended this to not be synced with Terrasync (syncing won't have an effect anyway, since ATM the script always loads models from the main models directory). It would be possible to revert back to specifying jetway models in an STG file. However, that would cause a loss of features including the ability for the jetway to 'know' the position of the aircraft, and gate numbers and airline signs specific to each jetway- all of which are very well-received by end-users and I spent hours programming. Only the former can be worked around (and not very well, at that). Perhaps the directory structure needs reorganization. I would consider making a new directory under $FG_ROOT, perhaps Jetways/, but that just seems like a waste to me. Again, sorry for not raising this issue earlier. Ryan -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG + vrml plugin
Hi Curt,
On Saturday, May 21, 2011 20:19:01 Curtis Olson wrote:
Has anyone built the vrml plugin for OSG under linux (fedora). The
README.txt says I need boost and openvrml installed. I've installed
openvrml and libopenvrml{,-devel}, and rerun ./configure but the vrml
plugin still isn't getting built.
Apparently I don't know enough about cmake to trace through the scripts and
figure out what the findvrml plugin is looking for specifically. I'm not
even sure that module is getting run or how to tell cmake to even look for
openvrml?
Does anyone have any tips or suggestions?
Just a general note on the vrml plugin:
I am using this plugin at work to double check a vrml exporter on linux. It
can read many vrml files. But it fails on some. So if something does not look
as expected, you might run in one of these failures.
From what you write:
Did you remove the CMakeCache.txt file before retrying the configure step?
If not, try this and then rerun your configure script or the cmake command you
usually run.
I had some problems to detect and run the vrml stuff due to the openvrml libs
being not installed in the standard library paths. So, I needed to add some
LD_LIBRARY_PATH et al magic to get that detected and runnning. But since you
work with the distribution provided stuff, I do not exepct that this will be a
problem.
May be this helps a little?
Mathias
--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG + vrml plugin
Hi Mathias,
Thanks for the reply. It appears that removing the CMakeCache.txt file did
the trick. Now it finds the openvrml libs and builds the plugin. It turns
out I still can't view the wrl file though ... it's a whole bunch of line
segments which maybe isn't supported by the vrml plugin? I might have to
see if I can hack a script to convert it to ac3d format or find some other
tool that can import the file correctly and then export it again as
something else. Blender unfortunately only supports vrml-1.0 and the file
I'm working with is vrml-2.0.
The wrl file is CFD streamlines around a 3d model so I'm hoping it will look
really cool if I can get it to load and render in flightgear ...
Curt.
2011/5/22 Mathias Fröhlich
Hi Curt,
On Saturday, May 21, 2011 20:19:01 Curtis Olson wrote:
Has anyone built the vrml plugin for OSG under linux (fedora). The
README.txt says I need boost and openvrml installed. I've installed
openvrml and libopenvrml{,-devel}, and rerun ./configure but the vrml
plugin still isn't getting built.
Apparently I don't know enough about cmake to trace through the scripts
and
figure out what the findvrml plugin is looking for specifically. I'm
not
even sure that module is getting run or how to tell cmake to even look
for
openvrml?
Does anyone have any tips or suggestions?
Just a general note on the vrml plugin:
I am using this plugin at work to double check a vrml exporter on linux. It
can read many vrml files. But it fails on some. So if something does not
look
as expected, you might run in one of these failures.
From what you write:
Did you remove the CMakeCache.txt file before retrying the configure step?
If not, try this and then rerun your configure script or the cmake command
you
usually run.
I had some problems to detect and run the vrml stuff due to the openvrml
libs
being not installed in the standard library paths. So, I needed to add some
LD_LIBRARY_PATH et al magic to get that detected and runnning. But since
you
work with the distribution provided stuff, I do not exepct that this will
be a
problem.
May be this helps a little?
Mathias
--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
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
--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including clusters.
http://p.sf.net/sfu/intel-dev2devmay___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fog vs black sky (issue #319)
Hi Thosten,
On Saturday, May 21, 2011 13:45:50 ThorstenB wrote:
Am Freitag, den 20.05.2011, 19:06 +0200 schrieb ThorstenB:
On 19.05.2011 20:38, Lauri Peltonen wrote:
So the solution is either change the clear color to what it was, or
make it ramp linearly to black or something with altitude.
Or change simgear/scene/sky.cxx around line 117 (repaint method), there
is a
if ( effective_visibility 1000.0 ) {
...
} else {
// turn off sky
disable();
}
My suggestion: we try removing the condition now and see if anyone sees
new issues.
After looking into this more closely, I revert my suggestion. Not a good
idea to remove the condition. It's there for several reasons:
* Switches off sun/moon/stars when visibility is low. Looks odd when
there's a bright (red) sun or stars in very dense the fog - so we have
to keep this.
* Also switches off the blue (or colorful) sky dome at low visibility.
Well, I believe that the reason for that switch was, that you cannot see the
sky anymore if you have this small visibility.
Before the patch, the clear color was synchronized to the current fog
color:
SGVec4f clearColor(l-adj_fog_color());
Hence, switching off the sky dome turned all empty bits into fog -
including the entire sky.
So, we need something in the scenery which can be painted with the fog
color. For anyone interested in working on it (Lauri? ;-) ) here are
some options:
* Change the sky dome itself so its color can uniformly be switched to
fog color when visibility is low, and then (the easy part ;-) ) move
the sky dome element above the switched sky group (so it's not affected
when the other sky elements are switched off).
* Switch the sky dome off but introduce/enable a new fog dome at low
visibility (painted with the fog color).
* Or, change the implementation of FGLighting::adj_fog_color
(and ::sky_color) to return black as the current fog/sky color at high
altitudes - and keep all the other stuff.
The last option is probably the easiest. But not sure what the right
solution was - maybe an osg/scenery expert can comment? (Tim/Mathias?)
I've reverted the original patch for now, since we'll need to work on
the particular renderer.cxx lines anyway to solve the issue - and there
were also a few minor technical things (see revert-commit comment), so
we should provide a better patch once we know how to solve the fog issue
altogether.
Ok, I believe that reverting that clear color change is a good idea. So, the
current state is ok. IMO.
I tried to keep out of the scenegraph/rendering discussions lately. But for
that topic, I have some thoughts. Nothing for this current upcomming release,
but may be for the next round:
At first, I like the O'Neil sky very much. This is the easiest variant of the
scattering shader approaches. This one is a good starting point!
For something more advanced see http://hal.inria.fr/inria-00288758/en/ for
example :-)
One problem with the current view ray dependent sky colors from the O'Neil
approach is that the scattering integrals really vary with the views
direction. That means we do not have a uniform fog color over the whole scene
any more. As a result the scenery that is rendered with a static fog color
does no longer integrate seamless with the sky as it did before.
The next problem is the sky dome geometry that is somehow limiting the
possible eye points to be within the usualy flight altitudes.
Whatever we do here stays some kind of workaround for the skydome/static fog
color being something unapropriate for the job.
I think that we should at some time switch to a two pass rendering for the
scene:
At first render the scene without fog and sky and with a black clear color into
an fbo.
Then, in a second pass, use the color/depth information from this first render
pass' fbo and render the sky/fog on top of this pregenerated scenery picture.
The sky/fog is drawn using a screen aligned quad that has the sky shader
attached. Using the original projection matrix in a shader uniform and the z
values from the first render pass' depth texture, the ray of sight is computed
and used for the O'Neil sky/fog computations. If the z value is the depth
clear value, we assume that we need to intersect the ray of sight with the
atmosphere boundary as it is done for the sky colors. If we have a finite z
value, compute the scatteing from the eye to the color fragement and
underblend the fragment color from the first rendering pass.
Our depth partitioning implementation will require the first pass to happen for
two parts of our scene. One being the far part of the scene, one being the
near part of the scene. So, the composition/sky/fog shader will have two color
and two depth textures from the two depth partitioning passes as an input.
The three color values (far scene, near scene, fog) need to be blended
together in the correct order.
So, some work
Re: [Flightgear-devel] OSG + vrml plugin
Hi Curt, On Sunday, May 22, 2011 17:14:54 Curtis Olson wrote: Thanks for the reply. It appears that removing the CMakeCache.txt file did the trick. Now it finds the openvrml libs and builds the plugin. It turns out I still can't view the wrl file though ... it's a whole bunch of line segments which maybe isn't supported by the vrml plugin? I might have to see if I can hack a script to convert it to ac3d format or find some other tool that can import the file correctly and then export it again as something else. Blender unfortunately only supports vrml-1.0 and the file I'm working with is vrml-2.0. No, the line segments are not supported. At least not in the current release version. My line segment support is checked in with revision 11290. So you may backport that pach to the current release version. BTW, I needed the line segments in vrml for exported models for a cfd visualization where I could not see the streamlines with osgviewer :) The wrl file is CFD streamlines around a 3d model so I'm hoping it will look really cool if I can get it to load and render in flightgear ... What kind of CFD are you doing? Greetings Mathias -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG + vrml plugin
2011/5/22 Mathias Fröhlich No, the line segments are not supported. At least not in the current release version. My line segment support is checked in with revision 11290. So you may backport that pach to the current release version. BTW, I needed the line segments in vrml for exported models for a cfd visualization where I could not see the streamlines with osgviewer :) Hi Mathias, Sounds strangely familiar! :-) Is there a particular minimum dev version I could find this patch in? I've been hanging around with v2.9.7 of OSG here because of compatibility problems of the newer versions. It looks like there is some IndexedLineSet references in the 2.9.9 version of the code -- is that the patch you are talking about? What kind of CFD are you doing? We are using Fluent, although I'm not directly involved in the CFD portions of the project, just trying to help visualize the end result with FlightGear. What CFD are you using? It would be kind of cool to work out a generalized approach for generating streamlines around our models at different attitudes and configurations (gear up/down, flaps, etc.) and then develop some system to pick the closest streamline model. Maybe it would be a job for nasal since the conditions for each model and related sets of streamlines could be wildly different. Regards, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata merge request 91:Animated Jetways
Hi Ryan, please excuse the rather brief comment. I had been short in time and was about to leave - actually I ended up being too late for the final rehearsal before a symphony concert this morning :-(( Your submission is touching various places, therefore please expect various people (maintainers) to have their specific opinion on this. For example I could envision that those who are keeping an eye on the AI aicraft collection might appreciate the submission to be split into specific parts - as do I for the Scenery-related files. Ryan M wrote: However, due to the technical details of the new jetways, it is not possible to integrate them with Terrasync/Shared models as it was previously. This is because the jetways are specified in an XML file for each airport that a Nasal script parses and loads models for via fgcommand(add-model, ...). That's how each jetway knows its independent position and its relative location to the aircraft door, unlike a static model in scenery where this is not possible. I'm not generally against adding specific per-airport jetway definitions into FlightGear as a whole, but I think we should talk about the details of the where. Look, we're already distributing airport-specific ground networks, why not accompagny the jetway positions alongside the other airport-specific stuff instead of creating yet another, new directory. Additionally, the 3d models have to be stored somewhere. By my logic, that should be in Models/Aiport, hence the new directory. A good idea in general, but, while you are at it, please read: http://mapserver.flightgear.org/git/gitweb.pl?p=fgdata;a=blob;f=Models/00README.CONTRIBUTE [...] I intended this to not be synced with Terrasync (syncing won't have an effect anyway, since ATM the script always loads models from the main models directory). I'm a bit uncertain if I understand correctly - would you bother rephrasing in different words ? Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG + vrml plugin
On Sun, May 22, 2011 at 11:33 AM, Curtis Olson wrote: Sounds strangely familiar! :-) Is there a particular minimum dev version I could find this patch in? I've been hanging around with v2.9.7 of OSG here because of compatibility problems of the newer versions. It looks like there is some IndexedLineSet references in the 2.9.9 version of the code -- is that the patch you are talking about? Hi Mathias, For what it's worth I back ported the v2.9.9 vrml plugin code to v2.9.7 and that compiles and works well. I'm able to see the streamlines in osgviewer at least. VRML is very verbose (especially this file) so load/parse times are very slow. :-( Might still be worth converting to something else for real time rendering. Thanks, Curt -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata merge request 91:Animated Jetways
Ryan M wrote: On Sun, 2011-05-22 at 16:59 +, Martin Spott wrote: [...] Look, we're already distributing airport-specific ground networks, why not accompagny the jetway positions alongside the other airport-specific stuff instead of creating yet another, new directory. Ah, I forgot about the ground network directories. I propose the definitions be moved to $FG_ROOT/AI/Airports/ICAO/jetways.xml I see, we're getting closer :-) Now, since the most recent version of the ground network files are distributed via TerraSync, I'd propose to place the jetway files in the same directories. This would indeed require your scripts to look into the custom scenery directories as well - which would be the preferred option, because, as already mentioned, I'd like to reduce the dependency of Scenery from the Base Package. The preferred way of referencing custom scenery data would be to have some sort of variable as a reference for all subsystems/routines which would refer to these directories, but I have to admit that I'm not entirely certain about the current state. I'd say this is something worth checking before we proceed. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
