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

Reply via email to