Re: [Flightgear-devel] Ridge lift in south hemisphere
jean pellotier a écrit :
hi, yesterday we were near the Kilimanjaro (HTKJ) and up to reach the
top with a c172, we tried to use the lift given by ridge lift, but it
was always 0.
I tried to start at Quito (SEQU) and ridge lift get elevation values
only once in north hemisphere.
it seems that:
(globals->get_scenery()->get_elevation_m(SGGeod::fromGeodM(
SGGeod::fromRad(probe_lon_rad[i],probe_lat_rad[i]),
2), elevation, 0))
in environment/ridge_lift.cxx is always false in south hemisphere, an
can't report the ground elevation
The responsable was the test for the pole position, to avoid a division
by cos(lat) =0, here's a patch addressing this issue, if someone can
have a look and commit, thanks.
jano
Index: src/Environment/ridge_lift.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Environment/ridge_lift.cxx,v
retrieving revision 1.8
diff -u -r1.8 ridge_lift.cxx
--- src/Environment/ridge_lift.cxx 20 May 2009 09:24:56 - 1.8
+++ src/Environment/ridge_lift.cxx 23 May 2009 06:47:58 -
@@ -176,7 +176,7 @@
probe_lat_rad[i] = asin(sin(user_latitude_rad)*cos(probe_radius_ratio)
+cos(user_latitude_rad)*sin_probe_radius_ratio*cos(ground_wind_from_rad));
- if (probe_lat_rad[i] < SG_EPSILON ) {
+ if (abs(abs(probe_lat_rad[i]) - SG_PI / 2.0) < SG_EPSILON ) {
probe_lon_rad[i] = user_latitude_rad; // probe on a pole
} else {
probe_lon_rad[i] = fmod((user_longitude_rad+asin(sin(ground_wind_from_rad)
@@ -191,11 +191,7 @@
double elevation = 0;
if (globals->get_scenery()->get_elevation_m(SGGeod::fromGeodM(
SGGeod::fromRad(probe_lon_rad[i],probe_lat_rad[i]), 2), elevation, 0)) {
-if ( elevation > 0.1 ) {
probe_elev_m[i] = elevation;
-} else {
- probe_elev_m[i] = 0.1 ;
-}
} else {
probe_elev_m[i] = 0.1;
}
--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com ___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] New screenshots of Eurocopter EC 145
Hello, I have just uploaded some new screenshots of the EC 145: http://fgfs.i-net.hu/modules/xcgal/thumbnails.php?album=44 The instrument panels are almost finished. Only the textures are still missing. Regards Matthias -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] fgviewer
Hi all, I have now checked in a small tool in flightgear that can be used just like osgviewer. The huge difference is that it also works for btg and with some knowledge about the internals of the model loading process also for stg files. The tool is aimed at people working on scenery and willing to see how their scenery modifications will look like. The can do so now without starting flightgear. This is a basic version of that tool that might grow it there is a need. I hope to include more flightgear internal scenery loading stuff so that you can at some time also load aircraft models an see if the static parts animations/transforms/postprocessing steps are as expected without the need to start the whole simulation. So far so good. You need to set the environment variable FG_ROOT like you should have in flightgear. And then for example load a btg.gz file of your interrest :) Problems and suggestions to me :) Greetings Mathias -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Visibility and ceiling options broken?
Torsten Dreyer wrote: > Add --prop:/environment/weather-scenario=none to your command line and it > works again. > > Background: the default weather-scenario is METAR and > if --disable-real-weather-fetch, a fake, hard-coded METAR is interpreted > which overrides the given options for visibility and ceiling. > > > Hi Torsten, Thanks for the quick reply, that works and I can fly IFR now :-) However, when real weather is disabled and the user specifies weather conditions on the command line, would it not make sense to incorporate those into the fake METAR at startup? Since you say that this is a fake, hard-coded METAR, I can't see what else this could break? Cheers - Dave -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [bug?] Embedded Nasal no longer executed onmodel loading?
Hi, On Friday 22 May 2009 17:21:39 Vivian Meazza wrote: > Seems to work now - thanks. Thanks! Greetings Mathias -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [bug?] Embedded Nasal no longer executed onmodel loading?
Mathias wrote > On Thursday 21 May 2009 11:22:15 Anders Gidenstam wrote: > > Have anyone else noticed that Nasal code embedded in 3d model XML files > > (e.g. in blocks) do not execute on model > > loading anymore? > > > > Or is this a local problem with my installation (I have tried updating > to > > the latest OSG development release and rebuilt SG and FG from scratch - > > no luck). > > > > Fastest way to test: > > Go to KNUQ and click on the doors of hangar one. If they open you don't > > have the bug, if you get > > > > Nasal runtime error: undefined symbol: scenery > >at /animation[5]/action/binding, line 1 > > > > your build have the problem. > > > > This problem must have been introduced fairly recently, in the last > > week or three. I know embedded Nasal worked 2009-05-04 when MPCarrier > was > > committed (as it depends on embeddded Nasal and was working at that > point). > > May be I have found what was missing. > Can you retry please? > Seems to work now - thanks. Vivian -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Chicago O'Hare airport data
Hi Durk, Chicago O'Hare airport has just put all their current arrival/departure information online: http://www.ohare-airport.org/ Would this be useful at all for seeding our AI traffic system? Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim static friction
Hi Mathias, > I have not tested that part of the api. So testers and comments welcome. > > Hmm, ok. I see. > Does the attached patch help? > With your code, you might have a better test bed than I have. Thank you for the patch, I will be out of town this weekend so I will try it next week. > *In* *theory* the groundcache expects times that corespond to the simulation > time. FGInterface accounts for the difference between the start of the FDM > instance and the simulation time (that is the cache_time_offset in > FGInterface). > I believe that YASim did not track the simulation time itself, so I added > that? True? Also, YASim internal integration steps do not know about the exact > time they are for. You might need to take care of them. > > There should be no delay between the FDM and AI iterations. The groundcache is > valid for a specific time interval. And when you start integration, you should > be at the start of that interval. Once you are ready for that timeslice, you > should be no further than the end of the caches validity. > This is not checked. Understood, using the simulation time in the groundcache makes it much easier to track. Now it is just a matter of accounting for the FDM and the integrator iteration delays in relation to the cache_time_offset. Hopefully with you patch and this explanation I will be able to finish it next week. Thank you again. Regards, Diogo -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [bug?] Embedded Nasal no longer executed on model loading?
Hi, On Thursday 21 May 2009 11:22:15 Anders Gidenstam wrote: > Have anyone else noticed that Nasal code embedded in 3d model XML files > (e.g. in blocks) do not execute on model > loading anymore? > > Or is this a local problem with my installation (I have tried updating to > the latest OSG development release and rebuilt SG and FG from scratch - > no luck). > > Fastest way to test: > Go to KNUQ and click on the doors of hangar one. If they open you don't > have the bug, if you get > > Nasal runtime error: undefined symbol: scenery >at /animation[5]/action/binding, line 1 > > your build have the problem. > > This problem must have been introduced fairly recently, in the last > week or three. I know embedded Nasal worked 2009-05-04 when MPCarrier was > committed (as it depends on embeddded Nasal and was working at that point). May be I have found what was missing. Can you retry please? Greetings Mathias -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [bug?] Embedded Nasal no longer executedonmodel loading?
Mathias wrote > > Hi, > > On Thursday 21 May 2009 23:05:20 Vivian Meazza wrote: > > Looks very much like Mathias' updates to SG on 17 May broke embedded > Nasal. > > Haven't found out exactly which update is to blame though. > If you know which one, tell me. > > We had that 'on load callback' code spread over different locations, I had > hoped to catch them all and move them to the options class. > So is there still some callback attached as userdata? The problem is in SGReaderWriterXML.cxx, I think around line 314. I don't know how to fix it, other than by reverting the change. HTH Regards, Vivian -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim static friction
Hi Diego,
On Tuesday 19 May 2009 03:32:53 Diogo Kastrup wrote:
> I am sorry for the delay, finally I could get back to this. Besides
> moving to a new city/job, I have also bought a model airplane, so I feel
> like a child again with my new toy wasting all my free time playing.
Have fun :)
> I am changing the friction code to use the new API, but I am having some
> trouble. It looks like the velocities returned by the get_body method
> are always zero. Maybe the problem is in the
> void BodyFinder::apply(BVHMotionTransform& transform)
> method as even when it finds the right ID it returns before the
> velocities are set.
I have not tested that part of the api. So testers and comments welcome.
Hmm, ok. I see.
Does the attached patch help?
With your code, you might have a better test bed than I have.
> Also I am having some trouble to synchronize the stuck point with the
> carrier movement again. I saw that there are some changes to the time
> offset passed to the "Ground Callback" in YASim.cxx. What should I
> expect to be already taken care by get_body? Is it compensating for the
> delay between the AI update and the FDM iterations? And what about the
> Integrator iterations? This was the hardest part of the friction patch
> so any tip would be very helpful.
*In* *theory* the groundcache expects times that corespond to the simulation
time. FGInterface accounts for the difference between the start of the FDM
instance and the simulation time (that is the cache_time_offset in
FGInterface).
I believe that YASim did not track the simulation time itself, so I added
that? True? Also, YASim internal integration steps do not know about the exact
time they are for. You might need to take care of them.
There should be no delay between the FDM and AI iterations. The groundcache is
valid for a specific time interval. And when you start integration, you should
be at the start of that interval. Once you are ready for that timeslice, you
should be no further than the end of the caches validity.
This is not checked.
You may enable the ground cache debug code be defining the GROUNDCACHE_DEBUG in
groundcache.hxx. Then you can play with /fdm/groundcache-debug-level in the
property tree and see what the groundcache contains. That helped me to
understand the timeslicing in flightgear.
Greetings
Mathias
Index: groundcache.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/groundcache.cxx,v
retrieving revision 1.43
diff -u -r1.43 groundcache.cxx
--- groundcache.cxx 16 Mar 2009 09:48:18 - 1.43
+++ groundcache.cxx 22 May 2009 13:50:00 -
@@ -474,11 +474,10 @@
if (_id == transform.getId()) {
_foundId = true;
-return;
+} else {
+transform.traverse(*this);
}
-transform.traverse(*this);
-
if (_foundId) {
SGMatrixd toWorld = transform.getToWorldTransform(_time);
SGVec3d referencePoint = _bodyToWorld.xformPt(SGVec3d::zeros());
--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com ___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [bug?] Embedded Nasal no longer executed onmodel loading?
Hi, On Thursday 21 May 2009 23:05:20 Vivian Meazza wrote: > Looks very much like Mathias' updates to SG on 17 May broke embedded Nasal. > Haven't found out exactly which update is to blame though. If you know which one, tell me. We had that 'on load callback' code spread over different locations, I had hoped to catch them all and move them to the options class. So is there still some callback attached as userdata? Greetings Mathias -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
