Re: [Flightgear-devel] RFC: Eliminating jitter
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 haven't done so already)... Unfortunately, I did the necessary modifications in the same breath as the scenery API restructuring, so I don't have anything which would apply to current CVS. Anyway, I think I had that API nearly finished, maybe I'll be able to get that into a 'commitable' state instead. I think I'll wait till you get it sorted out then, I suppose you will get it finished faster than me. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RFC: Eliminating jitter
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 (if you haven't done so already)... Unfortunately, I did the necessary modifications in the same breath as the scenery API restructuring, so I don't have anything which would apply to current CVS. Anyway, I think I had that API nearly finished, maybe I'll be able to get that into a 'commitable' state instead. > Calling set_tile_center is not needed anymore, right? > How do I handle situations where get_tile_center is called? I think you can safely use globals->get_scenery()->get_center(). But IIRC, get_tile_center() was anyway mostly used as the (unnecessary) parameter for the get_absolute_view_pos() call ... Generally, relative coordinates should only be used locally, both in time (because moving reference frames invalidate the old coordinates) and scope (don't pass relative coordinates among objects or unrelated functions, which might use different reference frames). If coordinates are passed as SGLocation (i.e. absolute), there should be no problem, and I think that's warranted with the current FG implementation. The tile center can be managed outside the SGLocation class, e.g. by getting it from the scenery instance or whatever reference frame is convenient for local calculations. That's why I thought it would fit in with Mathias' patch. bye, Manuel ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RFC: Eliminating jitter
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 flightgear), but if you are currently working on the transform system you might find parts of it useful... I'm trying to get this included in CVS but it is a bit out of sync. It does take care of a few oddities in SGLocation [e.g. getAbsolutePosition() required the scenery_center as parameter (but does not depend on it), while get_relative_pos took no argument etc.]. Dunno if these oddities really manifest as bugs, but IMO they made the placement/transform system quite hard to understand and use. A couple of things; Calling set_tile_center is not needed anymore, right? How do I handle situations where get_tile_center is called? Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RFC: Eliminating jitter
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 Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RFC: Eliminating jitter
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 reduction of artifacts. Single precision is so > 20th century. :) I think the most important thing now is that plibs scenegraph is only available in single precision. I assume that your raytracing program timings runs on an i*86 type cpu without using mmx/sse extensions and not using the gpu to do computations? If so, this timings are not meaningful. An i*86 just uses the same registers and the same precision for all computations. This precision is by default even more than 64 bit double (which makes the i386 in some sense a non ieee machine and could be the reason for really strange bugs). Shure you can switch the precision to a lower datatype, but this switch is much more costly than executing one flop. As a result most programs will just leave that at the default (96 bit extendend precision) for performance reasons. The time to execute one multiplication/addision/subtraction is exactly the same for each precision (throughput is at about 1 flop per cycle), so even if you swiched the precision down to single precision at the beginning of your program, the operations which are mostly used performe exactly the same. Only divisions, sqrt, sin/cos and such more complicated assembly instructions take less computation time iff you changed the fpu control word to single precision. This situation improoves a with the vector valued fpu extensioins like sse et al ... (like mesa uses inside and very most propably are used in the closed source drivers from nvidia/ati for non gpu operations too). You can execute operations on one smid register at a clock cycle. That means either 2 doubles or 4 floats at a time, that is twice the throughput with floats. Also different cpu's like virtually nearly all non x86 (at least I know sparc, alpha and ia64 for shure) have extra assembler instructions for single and double precision floatingpoint oprerations and they perform different. Apart from that I am not shure if any of those gpu's can really compute with floats or doubles like we know them from cpu's. I expect that they support some internal format with some precision. May be a fixed point format, may be an other one. Even if the OpenGL interface will take floats and doubles, there is no guarantee that it does not use singles for all computations internally (True? Or is there a paragaph in the OpenGL standard?). That means that you might have jitter, even if all your transforms stored in the client application are in double precision. And if there are different gpu floatingpoint/fixedpoint formats available, I do not know if they will perform better or worse with different precision, which is not that unlikely. Does anybody have better knowledge about the internals of gpus? 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
Re: [Flightgear-devel] RFC: Eliminating jitter
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 historically been issues when working with the viewer code. Also > check to make sure taxing accross tile boundries works (coast most of the > way down the default runway at KSFO). Ok, I can rerset. I can taxi across tile boundaries. All with JSBSim (non groundcache) and YASim (groundcache) aircraft I can still take off and land on the carrier. With YASim aircraft. With teleporting I am not shure what you mean. Switching between views far away? I can take of from KSFO fly straight away for several minues (about 350 kts) and happily cycle through all views including the tower view. 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
Re: [Flightgear-devel] RFC: Eliminating jitter
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 so 20th century. By definition, opengl *only* does floating point. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RFC: Eliminating jitter
> 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 center. > > Appended are two patches flightgear.diff which need to be applied to > flightgear's source and SimGear.diff which needs to be applied to SimGear's > source. The two files placementtrans.[ch]xx need to be put into > SimGear/simgear/scene/model. > > If nobody objects, I would like to have these applied to CVS. > > Thanks to Melchior, who helped me testing that stuff. 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 historically been issues when working with the viewer code. Also check to make sure taxing accross tile boundries works (coast most of the way down the default runway at KSFO). Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RFC: Eliminating jitter
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 millimeters, which is > several pixels of screen space in a small cockpit. 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 so 20th century. -Paul K ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RFC: Eliminating jitter
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 small changes in flightgear), but if you are currently working on the > transform system you might find parts of it useful... > > It does take care of a few oddities in SGLocation [e.g. > getAbsolutePosition() required the scenery_center as parameter (but does > not depend on it), while get_relative_pos took no argument etc.]. Dunno if > these oddities really manifest as bugs, but IMO they made the > placement/transform system quite hard to understand and use. I remember your patch. And yes IMO this is a good idea too. I expected you to submit that at some time to the list :) 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
Re: [Flightgear-devel] RFC: Eliminating jitter
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 -> Cockpit -> ... The scene graph is a bit shorter. That first transform: 'Root/Eye -> Scenery Centroid' is not present in the scene graph as a transform node, but it is present just as viewpoint transform. The effect on roundoff is the same. > 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 millimeters, which is > several pixels of screen space in a small cockpit. > > But the solution should be as simple as reorganizing the scene > graph: > > Root/Eye -> Scenery Centroid -> scenery... >-> Aircraft Origin -> Cockpit -> ... > > I wonder if your fix isn't more complicated than it needs to be. Hmm, that would fix the cockpit jittering from the aircraft view. But the transform node from the eye position to the aircraft origin will take special code depending on the type of view. Right? What I like with the approach I have choosen here, is that you can take the *whole* scenegraph (ground and aimodels, that includes especially the carrier) and change the scenery center to a position where you need the highest accuracy with one function call. The application of that function will be that the renderer can set the center to somewhere near the viewpoint and the groundcache can put it somewhere near the aircraft. Also switching views causes the scenery center to be at a wrong position for one or two frames with the current cvs implementation. The reason is that the propagation of the scenery center through all subsystems and child classes of subsystems is hard to get right. So being able to get that right with one step at least for the scenegraph is a good idea. It took me serveral less intrusive takes to finally end with this implementation because of problems with the scenery center not propageted right within a loop. So, this will not only remove the jitter in the views but also eliminates the aircraft jumping around when switching views, having the cloud/sky subsystem placed at the right position even when views are switched and makes the code a bit more robust to changes in the evaluation order of the subsystems. 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
Re: [Flightgear-devel] RFC: Eliminating jitter
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 working on the
transform system you might find parts of it useful...
It does take care of a few oddities in SGLocation [e.g. getAbsolutePosition()
required the scenery_center as parameter (but does not depend on it), while
get_relative_pos took no argument etc.]. Dunno if these oddities really
manifest as bugs, but IMO they made the placement/transform system quite hard
to understand and use.
cheers,
Manuel
? SGLocation.diff
Index: location.cxx
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/scene/model/location.cxx,v
retrieving revision 1.6
diff -C2 -r1.6 location.cxx
*** location.cxx 19 Nov 2004 21:44:17 - 1.6
--- location.cxx 28 Apr 2005 15:42:43 -
***
*** 94,98
dst[0][3] = SG_ZERO ;
dst[3][3] = SG_ONE ;
-
}
--- 94,97
***
*** 104,108
// Constructor
SGLocation::SGLocation( void ):
! _dirty(true),
_lon_deg(-1000),
_lat_deg(0),
--- 103,107
// Constructor
SGLocation::SGLocation( void ):
! _position_dirty(true), _orientation_dirty(true),
_lon_deg(-1000),
_lat_deg(0),
***
*** 111,120
_pitch_deg(0),
_heading_deg(0),
! _cur_elev_m(0),
! _tile_center(0)
{
sgdZeroVec3(_absolute_view_pos);
- sgZeroVec3(_relative_view_pos);
- sgZeroVec3(_zero_elev_view_pos);
sgMakeRotMat4( UP, 0.0, 0.0, 0.0 );
sgMakeRotMat4( TRANS, 0.0, 0.0, 0.0 );
--- 110,116
_pitch_deg(0),
_heading_deg(0),
! _cur_elev_m(0)
{
sgdZeroVec3(_absolute_view_pos);
sgMakeRotMat4( UP, 0.0, 0.0, 0.0 );
sgMakeRotMat4( TRANS, 0.0, 0.0, 0.0 );
***
*** 127,148
void
- SGLocation::init ()
- {
- }
-
- void
- SGLocation::bind ()
- {
- }
-
- void
- SGLocation::unbind ()
- {
- }
-
- void
SGLocation::setPosition (double lon_deg, double lat_deg, double alt_ft)
{
! _dirty = true;
_lon_deg = lon_deg;
_lat_deg = lat_deg;
--- 123,129
void
SGLocation::setPosition (double lon_deg, double lat_deg, double alt_ft)
{
! _position_dirty = true;
_lon_deg = lon_deg;
_lat_deg = lat_deg;
***
*** 153,157
SGLocation::setOrientation (double roll_deg, double pitch_deg, double heading_deg)
{
! _dirty = true;
_roll_deg = roll_deg;
_pitch_deg = pitch_deg;
--- 134,138
SGLocation::setOrientation (double roll_deg, double pitch_deg, double heading_deg)
{
! _orientation_dirty = true;
_roll_deg = roll_deg;
_pitch_deg = pitch_deg;
***
*** 160,256
double *
! SGLocation::get_absolute_view_pos( const Point3D scenery_center )
{
! if ( _dirty ) {
! recalc( scenery_center );
! }
return _absolute_view_pos;
}
float *
! SGLocation::getRelativeViewPos( const Point3D scenery_center )
{
! if ( _dirty ) {
! recalc( scenery_center );
! }
return _relative_view_pos;
}
! float *
! SGLocation::getZeroElevViewPos( const Point3D scenery_center )
! {
! if ( _dirty ) {
! recalc( scenery_center );
! }
! return _zero_elev_view_pos;
! }
!
!
! // recalc() is done every time one of the setters is called (making the
! // cached data "dirty") on the next "get". It calculates all the outputs
! // for viewer.
! void
! SGLocation::recalc( const Point3D scenery_center )
{
!
! recalcPosition( _lon_deg, _lat_deg, _alt_ft, scenery_center );
!
! // Make the world up rotation matrix for eye positioin...
! sgMakeRotMat4( UP, _lon_deg, 0.0, -_lat_deg );
!
!
! // get the world up radial vector from planet center for output
! sgSetVec3( _world_up, UP[0][0], UP[0][1], UP[0][2] );
!
! // Creat local matrix with current geodetic position. Converting
! // the orientation (pitch/roll/heading) to vectors.
! MakeTRANS( TRANS, _pitch_deg * SG_DEGREES_TO_RADIANS,
_roll_deg * SG_DEGREES_TO_RADIANS,
! -_heading_deg * SG_DEGREES_TO_RADIANS,
! UP);
! // Given a vector pointing straight down (-Z), map into onto the
! // local plane representing "horizontal". This should give us the
! // local direction for moving "south".
! sgVec3 minus_z;
! sgSetVec3( minus_z, 0.0, 0.0, -1.0 );
!
! sgmap_vec_onto_cur_surface_plane(_world_up, _relative_view_pos, minus_z,
! _surface_south);
! sgNormalizeVec3(_surface_south);
!
! // now calculate the surface east vector
! sgVec3 world_down;
! sgNegateVec3(world_down, _world_up);
! sgVectorProductVec3(_surface_east, _surface_south, world_down);
!
! set_clean();
! }
!
! void
! SGLocation::recalcPositio
Re: [Flightgear-devel] RFC: Eliminating jitter
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 memory) like this: Root/Eye -> Scenery Centroid -> Aircraft Origin -> Cockpit -> ... 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 millimeters, which is several pixels of screen space in a small cockpit. But the solution should be as simple as reorganizing the scene graph: Root/Eye -> Scenery Centroid -> scenery... -> Aircraft Origin -> Cockpit -> ... I wonder if your fix isn't more complicated than it needs to be. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] RFC: Eliminating jitter
Hi,
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 center.
The solution will be to move the scenery center near the view point.
This way floats relative accuracy is enough to show a stable picture.
To get that right I have introduced a transform node for the scenegraph which
is responsible for that shift and uses double values as long as possible.
The scenery subsystem now has a list of all those transforms required to place
objects in the world and will tell all those transforms that the scenery
center has changed when the set_scenery_center() of the scenery subsystem is
called.
The problem was not solvable by SGModelPlacement and SGLocation, since not all
objects, especially the scenery, are placed using these classes.
The first approach was to have the scenery center exactly at the eyepoint.
This works well for the cockpit.
But then the ground jitters a bit below the aircraft. With our default views
you can't see that, but that F-18 has a camera view below the left engine
intake with the nose gear and the ground in its field of view, here I could
see that.
Having the scenery center constant will still have this roundoff problems, but
like it is now too, the roundoff error here is exactly the same in each
frame, so you will not notice any jitter.
The real solution is now to keep the scenery center constant as long as it is
in a ball of 30m radius around the view point. If the scenery center is
outside this ball, just put it at the view point.
As a sideeffect of now beeing able to switch the scenery center in the whole
scenegraph with one function call, I was able to remove a one half of a
problem when switching views, where the scenery center was far off for one or
two frames past switching from one view to the next. Also included is a fix
to the other half of this problem, where the view position was not yet copied
into a view when it is switched (at least under glut). This was responsible
for the 'Error: ...' messages of the cloud subsystem when views were
switched.
Appended are two patches flightgear.diff which need to be applied to
flightgear's source and SimGear.diff which needs to be applied to SimGear's
source. The two files placementtrans.[ch]xx need to be put into
SimGear/simgear/scene/model.
If nobody objects, I would like to have these applied to CVS.
Thanks to Melchior, who helped me testing that stuff.
Greetings
Mathias
--
Mathias FrÃhlich, email: [EMAIL PROTECTED]
Index: src/AIModel/AIBase.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/AIModel/AIBase.cxx,v
retrieving revision 1.34
diff -u -r1.34 AIBase.cxx
--- src/AIModel/AIBase.cxx 27 Dec 2004 17:35:22 - 1.34
+++ src/AIModel/AIBase.cxx 23 Apr 2005 06:58:08 -
@@ -69,6 +69,9 @@
}
FGAIBase::~FGAIBase() {
+// Unregister that one at the scenery manager
+globals->get_scenery()->unregister_placement_transform(aip.getTransform());
+
globals->get_scenery()->get_scene_graph()->removeKid(aip.getSceneGraph());
// unbind();
SGPropertyNode *root = globals->get_props()->getNode("ai/models", true);
@@ -146,6 +149,8 @@
aip.setVisible(true);
invisible = false;
globals->get_scenery()->get_scene_graph()->addKid(aip.getSceneGraph());
+ // Register that one at the scenery manager
+ globals->get_scenery()->register_placement_transform(aip.getTransform());
} else {
if (model_path != "") {
SG_LOG(SG_INPUT, SG_WARN, "AIBase: Could not load model.");
Index: src/ATC/AIEntity.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/ATC/AIEntity.cxx,v
retrieving revision 1.9
diff -u -r1.9 AIEntity.cxx
--- src/ATC/AIEntity.cxx 19 Nov 2004 22:10:42 - 1.9
+++ src/ATC/AIEntity.cxx 23 Apr 2005 06:58:08 -
@@ -48,6 +48,9 @@
_model->deRef(); // Ought to check valid?
//cout << "Removing model from scene graph..." << endl;
globals->get_scenery()->get_scene_graph()->removeKid(_aip.getSceneGraph());
+// Unregister that one at the scenery manager
+globals->get_scenery()->unregister_placement_transform(_aip.getTransform());
+
//cout << "Done!" << endl;
}
@@ -57,6 +60,9 @@
_aip.init(_model);
_aip.setVisible(false);
globals->get_scenery()->get_scene_graph()->addKid(_aip.getSceneGraph());
+// Register that one at the scenery manager
+globals->get_scenery()->register_placement_transform(_aip.getTransform());
+
}
void FGAIEntity::Update(double dt) {
Index: src/FDM/groundcache.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/groundcache.cxx,v
retrieving revision 1.5
diff -u -r1.5 grou
