Re: [Flightgear-devel] Re: Speed of CVS version and flying in the Himalayas
On Donnerstag 26 Mai 2005 16:31, Melchior FRANZ wrote: > And, yes. This solves the ugly hang. But I do still not get a correct > elevation! Yes, what that does is to accept points to be inside the triangle in question which are slightly outside that triangle. By slightly I mean up to at most that eps in meters at the very beginning of that patch. The problem with that approach is that this meaning of 'being eps meter outside the triangle' is not usual geometric distance. Depending on the shape of the triangle this tolerance could be far smaller than that number given with eps. But in this case 0.1mm seem to be sufficient. And rolling on a surface which is at most 0.1mm away is not that bad anyway ... I hoped that the wrong transform coverd all problems, at least it covered the ones I have tried. But at first I searched in the area of this patch, so, I kept that one ont of the tree until somebody complains that it is still not sufficient. :) Feel free to apply. 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: Speed of CVS version and flying in the Himalayas
* Mathias Fröhlich -- Thursday 26 May 2005 15:50: > On Donnerstag 26 Mai 2005 15:10, Melchior FRANZ wrote: > > BTW: the scenery doesn't show anything unusual and suspicious. Not even the > > familiar crack line. And starting fgfs with --lon=16.5 --lat=48.5833 works > > flawlessly. > Hmm, that did not for me ... > But with the attached patch it did, at least for me ... ?!! Dang. You got me. I lied. I hadn't used the correct coords when I tried that (whereas all other tests were correct!). :-) Right. This hangs completely. I haven't seen that before. No wonder that the telnet method doesn't deliver a useful elevation. > > > I have something in my tree which could help, if the problem is at the > > > point I expecte it to be ... > > > > Cool. (It's not that I'm unwilling to find the bug myself. It just got in > > my way when I was working on something else, and I didn't want to get > > distracted by that. A workaround was preferable at that time.) > Does this attached patch help for you? And, yes. This solves the ugly hang. But I do still not get a correct elevation! m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Speed of CVS version and flying in the Himalayas
Hi,
On Donnerstag 26 Mai 2005 15:10, Melchior FRANZ wrote:
> BTW: the scenery doesn't show anything unusual and suspicious. Not even the
> familiar crack line. And starting fgfs with --lon=16.5 --lat=48.5833 works
> flawlessly.
Hmm, that did not for me ...
But with the attached patch it did, at least for me ... ?!!
> > I have something in my tree which could help, if the problem is at the
> > point I expecte it to be ...
>
> Cool. (It's not that I'm unwilling to find the bug myself. It just got in
> my way when I was working on something else, and I didn't want to get
> distracted by that. A workaround was preferable at that time.)
Does this attached patch help for you?
Greetings
Mathias
--
Mathias Fröhlich, email: [EMAIL PROTECTED]
Index: src/Scenery/hitlist.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Scenery/hitlist.cxx,v
retrieving revision 1.11
diff -u -r1.11 hitlist.cxx
--- src/Scenery/hitlist.cxx 26 May 2005 08:13:06 - 1.11
+++ src/Scenery/hitlist.cxx 26 May 2005 13:45:38 -
@@ -124,20 +124,23 @@
{
sgdVec3 dif;
+// Some tolerance in meters we accept a point to be outside of the triangle
+// and still return that it is inside.
+SGDfloat eps = 1e-4;
SGDfloat 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) || (point[0] > max) )
+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) || (point[1] > max) )
+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) || (point[2] > max) )
+if( (point[2] < min - eps) || (point[2] > max + eps) )
return false;
dif[2] = max - min;
@@ -181,27 +184,30 @@
}
// check if intersection point is on the same side of p1 <-> p2 as p3
-SGDfloat tmp = (y2 - y3) / (x2 - x3);
-int side1 = SG_SIGN (tmp * (rx - x3) + y3 - ry);
-int side2 = SG_SIGN (tmp * (x1 - x3) + y3 - y1);
+SGDfloat tmp = (y2 - y3);
+SGDfloat 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) / (x3 - rx);
-side1 = SG_SIGN (tmp * (x2 - rx) + ry - y2);
-side2 = SG_SIGN (tmp * (x1 - rx) + ry - y1);
+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) / (x2 - rx);
-side1 = SG_SIGN (tmp * (x3 - rx) + ry - y3);
-side2 = SG_SIGN (tmp * (x1 - rx) + ry - y1);
+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;
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Speed of CVS version and flying in the Himalayas
* Mathias Fröhlich -- Thursday 26 May 2005 13:18:
[still problems with locations on tile^Wbucket boundaries]
> Can you send me a location where it does not work?
lon: 16.5 lat: 48.5833
Proof that it's on a bucket boundary (although obvious):
$ calc-tile 16.4 48.5833
Longitude: 16.4
Latitude: 48.5833
Tile: 3220129
Path: "e010n40/e016n48/3220129.stg"
$ calc-tile 16.5 48.5833
Longitude: 16.5
Latitude: 48.5833
Tile: 3220130
Path: "e010n40/e016n48/3220130.stg"
Proof that there's a bug (comments in curly brackets; blank lines inserted):
$ fgfs --telnet=4711 --aircraft=ufo --fdm=null >/dev/null 2>&1&
[1] 13056
$ telnet localhost 4711
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
{ setting lat/lon to some arbitrary position; reading elevation }
set /position/latitude-deg 48.5833
/position/latitude-deg = '48.583300' (double)
/> set /position/longitude-deg 15.12345
/position/longitude-deg = '15.123450' (double)
/> get /position/ground-elev-m
/position/ground-elev-m = '586.518298' (double)
{ OK; works (assuming the elevation is correct) }
{ now changing to other arbitrary position; reading elev }
/> set /position/longitude-deg 15.54321
/position/longitude-deg = '15.543210' (double)
/> get /position/ground-elev-m
/position/ground-elev-m = '566.886987' (double)
{ different elevation; looks good }
{ now going to "problem position"; reading elevation }
/> set /position/longitude-deg 16.5
/position/longitude-deg = '16.50' (double)
/> get /position/ground-elev-m
/position/ground-elev-m = '566.886987' (double)
{ huh? same elevation to the 6th digit? Can't be! }
{ adding 0.0001 to longitude; reading elevation (my workaround) }
/> set /position/longitude-deg 16.5001
/position/longitude-deg = '16.500100' (double)
/> get /position/ground-elev-m
/position/ground-elev-m = '218.889957' (double)
{ oh, yes; that works }
/> quit
Connection closed by foreign host.
$
BTW: the scenery doesn't show anything unusual and suspicious. Not even the
familiar crack line. And starting fgfs with --lon=16.5 --lat=48.5833 works
flawlessly.
> I have something in my tree which could help, if the problem is at the point
> I
> expecte it to be ...
Cool. (It's not that I'm unwilling to find the bug myself. It just got in
my way when I was working on something else, and I didn't want to get distracted
by that. A workaround was preferable at that time.)
m.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Speed of CVS version and flying in the Himalayas
On Donnerstag 26 Mai 2005 12:37, Melchior FRANZ wrote: > Hey! I update & compile in the same minute a new cvs-log commit message > comes in if I'm at my computer. Yes, this happens with CVS/HEAD as of *now* > (Thu May 26 12:36:12 CEST 2005). I had tried it as soon as I saw the fix > because I had *hoped* that it would fix it. :) Sorry ... Can you send me a location where it does not work? I have something in my tree which could help, if the problem is at the point I expecte it to be ... 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: Speed of CVS version and flying in the Himalayas
* Mathias Fröhlich -- Thursday 26 May 2005 12:29:
> On Donnerstag 26 Mai 2005 12:21, Melchior FRANZ wrote:
> > Unfortunately, a similar bug showed up recently for *bucket* boundaries.
> > If you set /position/{latitude,longitude}-deg to a bucket boundary, fgfs
> > refuses to set /position/elevation-m accordingly.
> From what you tell, this might be fixed with the change to hitlist.cxx from
> today morning.
> Have you retried with this recent version?
Hey! I update & compile in the same minute a new cvs-log commit message comes in
if I'm at my computer. Yes, this happens with CVS/HEAD as of *now* (Thu May 26
12:36:12 CEST 2005). I had tried it as soon as I saw the fix because I had
*hoped*
that it would fix it.
m.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Speed of CVS version and flying in the Himalayas
On Donnerstag 26 Mai 2005 12:21, Melchior FRANZ wrote:
> Unfortunately, a similar bug showed up recently for *bucket* boundaries.
> If you set /position/{latitude,longitude}-deg to a bucket boundary, fgfs
> refuses to set /position/elevation-m accordingly. It simply lets the old
> elevation in the property system. Annoying for scripts that read out
> elevation. (I work around that by adding 0.0001 now in [1]). :-(
From what you tell, this might be fixed with the change to hitlist.cxx from
today morning.
Have you retried with this recent version?
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: Speed of CVS version and flying in the Himalayas
* Mathias Fröhlich -- Thursday 26 May 2005 12:01:
> On Dienstag 03 Mai 2005 14:17, Melchior FRANZ wrote:
> > > > Try adding --log-level=info for a possible hint,
> > >
> > > ./fgfs --lat=87 --long=28 --altitude=3 --log-level=info
> >
> > That's an old, well known bug. If you position fgfs exactly on the tile
> > boundaries (*integer* lon/lat), the intersection code somehow falls through
> > between the tiles. Try this:
> >
> >
> > $ ./fgfs --lat=87.001 --long=28.001 --altitude=3
> >
> >
> > I wouldn't be surprised if someone fixed that bug within ... the next
> > twenty years? ;-)
> Is fixed now in current cvs ...
Unfortunately, a similar bug showed up recently for *bucket* boundaries.
If you set /position/{latitude,longitude}-deg to a bucket boundary, fgfs
refuses to set /position/elevation-m accordingly. It simply lets the old
elevation in the property system. Annoying for scripts that read out
elevation. (I work around that by adding 0.0001 now in [1]). :-(
m.
[1] http://members.aon.at/mfranz/flightgear/getelev
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Speed of CVS version and flying in the Himalayas
On Dienstag 03 Mai 2005 14:17, Melchior FRANZ wrote: > > > Try adding --log-level=info for a possible hint, > > > > ./fgfs --lat=87 --long=28 --altitude=3 --log-level=info > > That's an old, well known bug. If you position fgfs exactly on the tile > boundaries (*integer* lon/lat), the intersection code somehow falls through > between the tiles. Try this: > > > $ ./fgfs --lat=87.001 --long=28.001 --altitude=3 > > > I wouldn't be surprised if someone fixed that bug within ... the next > twenty years? ;-) Is fixed now in current cvs ... Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Speed of CVS version and flying in the Himalayas
On Tue, 2005-05-03 at 14:17 +0200, Melchior FRANZ wrote: > That's an old, well known bug. If you position fgfs exactly on the tile > boundaries > (*integer* lon/lat), the intersection code somehow falls through between the > tiles. Try this: > > > $ ./fgfs --lat=87.001 --long=28.001 --altitude=3 > Thanks - this worked a treat. I'm now flying at 32000 feet over the breathtaking, er, sea. Oops - looks like I picked the wrong tile set :) > I wouldn't be surprised if someone fixed that bug within ... the next twenty > years? ;-) I feel an itch coming on... -- Paul Furber <[EMAIL PROTECTED]> ex tenebris lux, ex fenestris tux -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Speed of CVS version and flying in the Himalayas
* Frederic Bouvier -- Tuesday 03 May 2005 14:12: > Quoting Paul Furber: > > ./fgfs --lat=87 --long=28 --altitude=3 --log-level=info > > Classical numerical problem at tile boundary. Try that instead : > > ./fgfs --lat=87.0001 --long=28.0001 --altitude=3 ^ Hahaaa! (Never trust foreigners ;-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Speed of CVS version and flying in the Himalayas
* Paul Furber -- Tuesday 03 May 2005 14:07:
> On Tue, 2005-05-03 at 13:26 +0200, Melchior FRANZ wrote:
> > No. If you had posted a command line that exposes the problem, *hundreds*
> > of fgfs developers would have tried to reproduce it, and maybe would have
> > been able to reproduce it and to find a solution. But so ...
>
> *Smacks forehead* - ask smart questions idiot! Sorry about that - I'll
> be more informative in future :)
Hehe ... no problem. (And I swear that this retarded sentence ("would have
tried to reproduce it, and maybe would have been able to reproduce it") was
an editing accident! Sheesh ... :-)
> > Try adding --log-level=info for a possible hint,
>
> ./fgfs --lat=87 --long=28 --altitude=3 --log-level=info
That's an old, well known bug. If you position fgfs exactly on the tile
boundaries
(*integer* lon/lat), the intersection code somehow falls through between the
tiles. Try this:
$ ./fgfs --lat=87.001 --long=28.001 --altitude=3
I wouldn't be surprised if someone fixed that bug within ... the next twenty
years? ;-)
m.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Speed of CVS version and flying in the Himalayas
Quoting Paul Furber: > On Tue, 2005-05-03 at 13:26 +0200, Melchior FRANZ wrote: > > * Paul Furber -- Tuesday 03 May 2005 12:50: > > > it's just the Himalayas region which doesn't work. (doesn't work on 0.9.8 > > > either) I'm running CVS versions from last night on amd64 Gentoo Linux. > > > Any ideas? > > > > No. If you had posted a command line that exposes the problem, *hundreds* > > of fgfs developers would have tried to reproduce it, and maybe would have > > been able to reproduce it and to find a solution. But so ... > > *Smacks forehead* - ask smart questions idiot! Sorry about that - I'll > be more informative in future :) > > > Try adding --log-level=info for a possible hint, > > ./fgfs --lat=87 --long=28 --altitude=3 --log-level=info Classical numerical problem at tile boundary. Try that instead : ./fgfs --lat=87.0001 --long=28.0001 --altitude=3 -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Speed of CVS version and flying in the Himalayas
On Tue, 2005-05-03 at 13:26 +0200, Melchior FRANZ wrote: > * Paul Furber -- Tuesday 03 May 2005 12:50: > > it's just the Himalayas region which doesn't work. (doesn't work on 0.9.8 > > either) I'm running CVS versions from last night on amd64 Gentoo Linux. > > Any ideas? > > No. If you had posted a command line that exposes the problem, *hundreds* > of fgfs developers would have tried to reproduce it, and maybe would have > been able to reproduce it and to find a solution. But so ... *Smacks forehead* - ask smart questions idiot! Sorry about that - I'll be more informative in future :) > Try adding --log-level=info for a possible hint, ./fgfs --lat=87 --long=28 --altitude=3 --log-level=info seems to initialise everything, including the splash screen, then gets stuck in the terrain loading. I get thousands of: no terrain intersection messages interspersed with: Updating Sun position Gst = 0.824526 t->cur_time = 1115114851 Sun Geodetic lat = 0.275179 Geocentric lat = 0.273428 sun angle relative to current location = 1.24501 Updating Moon position t->cur_time = 1115114851 Moon Geodetic lat = -0.184198 Geocentric lat = -0.182992 moon angle relative to current location = 1.7246 Updating light parameters. Sun angle = 71.3338 ambient = 0.2 diffuse = 0.968597 specular = 0.5 sky = 0.953064 Corrupt scenery data perhaps? -- Paul Furber <[EMAIL PROTECTED]> ex tenebris lux, ex fenestris tux -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Speed of CVS version and flying in the Himalayas
* Paul Furber -- Tuesday 03 May 2005 12:50: > I compiled the CVS versions of SimGear and FlightGear last night and > they were roughly 40% faster than 0.9.8 - which is very impressive. ] Very strange. I'm not aware of any performance improvements since 0.9.8. (While there were a few very effective ones right before 0.9.8.) > fgfs just sits there for ages with the occasional disk access. "sits there"? On its butt? Can you be more specific? Does it only show a black screen, or only sea, does it freeze, or what? > it's just the Himalayas region which doesn't work. (doesn't work on 0.9.8 > either) I'm running CVS versions from last night on amd64 Gentoo Linux. > Any ideas? No. If you had posted a command line that exposes the problem, *hundreds* of fgfs developers would have tried to reproduce it, and maybe would have been able to reproduce it and to find a solution. But so ... Try adding --log-level=info for a possible hint, or (assuming that you compiled with debugging symbols --> gcc's -g flag) run fgfs in gdb and hit Ctrl-C when it hangs. Then type "bt" and see where it is. Then type "cont" to continue, let it run for a few seconds, hit Ctrl-C again and see again where it is. If it's always in the same area, post the relevant lines of the backtrace (bt). $ gdb --args fgfs --your-secret-himalaya-command-line ... press Ctrl-c (gdb) bt ... marvel at beautiful backtrace (gdb) cont press Ctrl-c again (gdb) bt ... marvel at beautiful backtrace (gdb) q m. ;-) ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
