Re: [Flightgear-devel] Re: FDM freeze
(2) I don't allow multiloop to become higher than, currently, 80.
diff -u -p -r1.20 flight.cxx
--- flight.cxx 22 Nov 2004 10:10:33 - 1.20
+++ flight.cxx 26 May 2005 05:07:44 -
@@ -83,7 +83,13 @@ FGInterface::_calc_multiloop (double dt)
// ... ok, two times the roundoff to have enough room.
int multiloop = int(floor(ml * (1.0 + 2.0*DBL_EPSILON)));
remainder = (ml - multiloop) / hz;
- return (multiloop * speedup);
+
+ int result = multiloop * speedup;
+ if (result 80) {
+ fprintf(stderr, \033[31;1m_calc_multiloop=%d\033[m\n, result);
+ return 80;
+ }
+ return result;
}
I tried your fix above and it didn't work for me :(
Here's a fix that I just tried and it works for me. In JSBSim.cxx, line about
number 423, I just commented out the return statement, so the FDM can
continue no matter what happens with the ground cache.
if (!cache_ok) {
SG_LOG(SG_FLIGHT, SG_WARN,
FGInterface is beeing called without scenery below the
aircraft!);
//return;
}
No more freezes now :)
Dave
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: FDM freeze
* Dave Culp -- Thursday 26 May 2005 09:00: (2) I don't allow multiloop to become higher than, currently, 80. I tried your fix above and it didn't work for me :( Oh. I had only observed the problem with YASim aircraft so far, and there it helped. But there's no reason why it wouldn't happen with JSBSim, and it doesn't surprise me that one needs a different fix for it. Here's a fix that I just tried and it works for me. In JSBSim.cxx, line about number 423, I just commented out the return statement, [...] No more freezes now :) So we need both workarounds for now!? MATHAS! :-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FDM freeze
Hi,
On Donnerstag 26 Mai 2005 09:00, Dave Culp wrote:
I tried your fix above and it didn't work for me :(
Yes, because Melchiors beacon stuff is different from that one you describe.
Especially, if AI aircraft keep on moving it sounds like something different.
I have thought about that and wanted to send a test patch to somebody with
that problems at sunday, but by internet connection stopped working at that
evening
For everybody experiencing these freezes with 'no ground below aircraft'.
Could you try the patch I have attached below?
Greetings
Mathias
--
Mathias Fröhlich, email: [EMAIL PROTECTED]
Index: src/FDM/groundcache.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/groundcache.cxx,v
retrieving revision 1.6
diff -u -r1.6 groundcache.cxx
--- src/FDM/groundcache.cxx 29 Apr 2005 14:38:24 - 1.6
+++ src/FDM/groundcache.cxx 26 May 2005 07:23:48 -
@@ -25,6 +25,7 @@
#include plib/sg.h
+#include simgear/sg_inlines.h
#include simgear/constants.h
#include simgear/debug/logstream.hxx
#include simgear/math/sg_geodesy.hxx
@@ -37,6 +38,131 @@
#include flight.hxx
#include groundcache.hxx
+// #define method1
+#define method2
+
+#if defined(method1)
+static inline bool fgPointInTriangle(sgVec3 point, sgVec3 tri[3])
+{
+ sgVec3 trip[3];
+ sgSubVec3(trip[0], tri[0], point);
+ sgSubVec3(trip[1], tri[1], point);
+ sgSubVec3(trip[2], tri[2], point);
+ sgVec3 s[3];
+ sgVectorProductVec3(s[0], trip[0], trip[1]);
+ sgVectorProductVec3(s[1], trip[1], trip[2]);
+ sgVectorProductVec3(s[2], trip[2], trip[0]);
+
+ if (sgScalarProductVec3(s[0], s[1]) -FLT_EPSILON)
+return false;
+ if (sgScalarProductVec3(s[1], s[2]) -FLT_EPSILON)
+return false;
+
+ return true;
+}
+#elif defined(method2)
+static inline bool fgPointInTriangle( sgVec3 point, sgVec3 tri[3] )
+{
+sgVec3 dif;
+
+// Some tolerance in meters we accept a point to be outside of the triangle
+// and still return that it is inside.
+SGfloat eps = 10*FLT_EPSILON;
+SGfloat min, max;
+// punt if outside bouding cube
+SG_MIN_MAX3 ( min, max, tri[0][0], tri[1][0], tri[2][0] );
+if( (point[0] min - eps) || (point[0] max + eps) )
+return false;
+dif[0] = max - min;
+
+SG_MIN_MAX3 ( min, max, tri[0][1], tri[1][1], tri[2][1] );
+if( (point[1] min - eps) || (point[1] max + eps) )
+return false;
+dif[1] = max - min;
+
+SG_MIN_MAX3 ( min, max, tri[0][2], tri[1][2], tri[2][2] );
+if( (point[2] min - eps) || (point[2] max + eps) )
+return false;
+dif[2] = max - min;
+
+// drop the smallest dimension so we only have to work in 2d.
+SGfloat min_dim = SG_MIN3 (dif[0], dif[1], dif[2]);
+SGfloat x1, y1, x2, y2, x3, y3, rx, ry;
+if ( fabs(min_dim-dif[0]) = FLT_EPSILON ) {
+// x is the smallest dimension
+x1 = point[1];
+y1 = point[2];
+x2 = tri[0][1];
+y2 = tri[0][2];
+x3 = tri[1][1];
+y3 = tri[1][2];
+rx = tri[2][1];
+ry = tri[2][2];
+} else if ( fabs(min_dim-dif[1]) = FLT_EPSILON ) {
+// y is the smallest dimension
+x1 = point[0];
+y1 = point[2];
+x2 = tri[0][0];
+y2 = tri[0][2];
+x3 = tri[1][0];
+y3 = tri[1][2];
+rx = tri[2][0];
+ry = tri[2][2];
+} else if ( fabs(min_dim-dif[2]) = FLT_EPSILON ) {
+// z is the smallest dimension
+x1 = point[0];
+y1 = point[1];
+x2 = tri[0][0];
+y2 = tri[0][1];
+x3 = tri[1][0];
+y3 = tri[1][1];
+rx = tri[2][0];
+ry = tri[2][1];
+} else {
+// all dimensions are really small so lets call it close
+// enough and return a successful match
+return true;
+}
+
+// check if intersection point is on the same side of p1 - p2 as p3
+SGfloat tmp = (y2 - y3);
+SGfloat tmpn = (x2 - x3);
+int side1 = SG_SIGN (tmp * (rx - x3) + (y3 - ry) * tmpn);
+int side2 = SG_SIGN (tmp * (x1 - x3) + (y3 - side1*eps - y1) * tmpn);
+if ( side1 != side2 ) {
+// printf(failed side 1 check\n);
+return false;
+}
+
+// check if intersection point is on correct side of p2 - p3 as p1
+tmp = (y3 - ry);
+tmpn = (x3 - rx);
+side1 = SG_SIGN (tmp * (x2 - rx) + (ry - y2) * tmpn);
+side2 = SG_SIGN (tmp * (x1 - rx) + (ry - side1*eps - y1) * tmpn);
+if ( side1 != side2 ) {
+// printf(failed side 2 check\n);
+return false;
+}
+
+// check if intersection point is on correct side of p1 - p3 as p2
+tmp = (y2 - ry);
+tmpn = (x2 - rx);
+side1 = SG_SIGN (tmp * (x3 - rx) + (ry - y3) * tmpn);
+side2 = SG_SIGN (tmp * (x1 - rx) + (ry - side1*eps - y1) * tmpn);
+if ( side1 != side2 ) {
+// printf(failed side 3 check\n);
+return false;
+}
+
+return true;
+}
+#else
+static inline bool
Re: [Flightgear-devel] Re: FDM freeze
Hi, On Donnerstag 26 Mai 2005 09:20, Melchior FRANZ wrote: So we need both workarounds for now!? MATHAS! :-) Sorry for that long time ... I lost my internet connection at sunday evening. The guys from the telephone company found out that there is significant noise in the cable (?, that is what he told me!). I now found out that unpluging my telephone helps my adsl connection to be reliably up again ... Ok, now many mails to read ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: FDM freeze
Just out of curiosity I removed the three tall scenery objects I had placed at Sembach, then flew around there for 30 minutes with no more ground cache errors. I think the problem comes from overflying the edge of a tall scenery object. Just a guess. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: FDM freeze
* Dave Culp -- Thursday 26 May 2005 02:56:
The user airplane is frozen, but other things keep running fine. The AI
aircraft keep going, as does the clock, frame rate, GUI, key bindings, mouse.
It looks like just the FDM froze. Anyone else getting this?
Yes. If it's the same that I got regularly when landing on KSFO/R28. The reason
turned out to be a beacon that the object database weirdly put shortly before
the runway. One had to overfly it. I talked with Mathias and we know now that
this is a bug in the ground cache code. The quite expensive beacon made the
ground cache too busy for too long (dt raised for FGInterface::_calc_multiloop
which results in a big multiloop value), and when the ground cache handler was
finally done, it had to catch up a lot of passed scenery, which made
dt/multiloop
even higher etc. It's positive feedback and basically keeps the FDM in a sort of
endless loop. Mathias is working on it. And I worked around it for now:
(1) I removed the beacon (which is silly there, anyway). It wouldn't stand there
longer than a day in real life. But the hang also happened on other places,
so:
(2) I don't allow multiloop to become higher than, currently, 80.
diff -u -p -r1.20 flight.cxx
--- flight.cxx 22 Nov 2004 10:10:33 - 1.20
+++ flight.cxx 26 May 2005 05:07:44 -
@@ -83,7 +83,13 @@ FGInterface::_calc_multiloop (double dt)
// ... ok, two times the roundoff to have enough room.
int multiloop = int(floor(ml * (1.0 + 2.0*DBL_EPSILON)));
remainder = (ml - multiloop) / hz;
- return (multiloop * speedup);
+
+ int result = multiloop * speedup;
+ if (result 80) {
+ fprintf(stderr, \033[31;1m_calc_multiloop=%d\033[m\n, result);
+ return 80;
+ }
+ return result;
}
This fixed the problem for me, and outputs some red warnings once in a while.
Sometimes it reports really big values (several thousands).
m.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
