Hello Erik,
sorry for the late reply.
I'm trying to get this included in CVS but it is a bit out of sync.
yep, I'm really getting a bad conscience about posting an unsync'ed patch :-)
I'm a bit busy at the moment, but I'll try to find some time to get the
flightgear modifications sorted out
Manuel Massing wrote:
Hello Erik,
I'm trying to get this included in CVS but it is a bit out of sync.
yep, I'm really getting a bad conscience about posting an unsync'ed patch
:-)
I'm a bit busy at the moment, but I'll try to find some time to get the
flightgear modifications sorted out (if you
HI Manuel,
Manuel Massing wrote:
Hi Mathias,
this reminds me that I had implemented the attached cleanup-patch for
SGLocation (as part of the abstract terrain API). I currently don't have the
time to finish the API, so the patch is a bit out of context (requires some
small changes in
Paul Kahler wrote:
What's wrong with just using double precision? If it's because this math
is done on the video card then fine. In ray tracing I switched to
doubles over 5 years ago and measured only a tiny penalty which was more
than made up for by the reduction of artifacts. Single precision is
Hi Jim,
On Freitag 29 April 2005 02:16, Jim Wilson wrote:
This sounds great. In a few days I should be able to get this and test it.
In the meanwhile, please double check that you can do resets and multiple
teleports. I think your changes will improve the situation, but those
have
Hi,
On Freitag 29 April 2005 01:33, Paul Kahler wrote:
What's wrong with just using double precision? If it's because this math
is done on the video card then fine. In ray tracing I switched to
doubles over 5 years ago and measured only a tiny penalty which was more
than made up for by the
Mathias Fröhlich wrote:
With teleporting I am not shure what you mean.
By teleporting I think Jim means selecting different airports across the
world (one after another), i.e. KSFO, CYYR, EHAM, etc.
Erik
___
Flightgear-devel mailing list
Mathias Fröhlich wrote:
I have done a patch to eliminate the jitter of 3D-objects near
the viewpoint (for example 3D cockpit objects).
Excellent. This bug has been annoying me for a long, long time.
I think the solution should be simpler, though. Right now, the
scene graph looks (from
Hi Mathias,
this reminds me that I had implemented the attached cleanup-patch for
SGLocation (as part of the abstract terrain API). I currently don't have the
time to finish the API, so the patch is a bit out of context (requires some
small changes in flightgear), but if you are currently
Hi,
On Donnerstag 28 April 2005 17:03, Andy Ross wrote:
Excellent. This bug has been annoying me for a long, long time.
Me too.
I think the solution should be simpler, though. Right now, the
scene graph looks (from memory) like this:
Root/Eye - Scenery Centroid - Aircraft Origin -
Hi Manuel,
On Donnerstag 28 April 2005 17:55, Manuel Massing wrote:
this reminds me that I had implemented the attached cleanup-patch for
SGLocation (as part of the abstract terrain API). I currently don't have
the time to finish the API, so the patch is a bit out of context (requires
some
On Thu, 2005-04-28 at 08:03 -0700, Andy Ross wrote:
So the local cockpit coordinates get double-transformed to the
centroid and back, losing precision in the process. That comes
out to roughly 1 part in a million at single precision, which
over a ~1km tile can be as much as a few
From: Mathias Fröhlich
I have done a patch to eliminate the jitter of 3D-objects near the viewpoint
(for example 3D cockpit objects).
The problem is the roundoff accuracy of the float values used in the
scenegraph together with the transforms of the eyepoint relative to the
scenery
13 matches
Mail list logo
