[Source] [X3D-Earth] Xj3D property setting for origin manager, for inclusion in X3D-Edit

[chris]

Hi Rex,

That's an interesting implementation: I imagine the elevation threshold
approach helps when there is navigation paths between space and the surface
(and back again).

a couple of observations:

<snip>

>
> Description
>
> The dynamic origin management strategy currently implemented in Xj3D is an
> extension to the original implementation. Internal to the browser, all
> geo-referenced coordinates are converted into GCC (Geocentric Cartesian) for
> use in rendering and transformation. The
>
In the comments below, I am going to assume that coordinates are still in
double (or higher) precision immediately after this conversion.


> original implementation would offset those coordinates by the GeoOrigin
> position as nodes were instantiated. The functional addition to the browser
> consists of a manager class that makes determinations based on the user's
> Viewpoint on when and where a new local origin is required, and notifies the
> loaded Geo nodes that they must update their interal state to account for
> the new setting.
>
> Local origins will be configured at either the ellipsoid center, or at the
> ellipsoid surface. The default origin manager's criteria for switching the
> local origin setting are configured with two parameters. An elevation above
> the ellipsoid is used as a threshold for establishing an initial local
> origin. A Viewpoint elevation above the threshold will cause the local
> origin to be configured as at the ellipsoid center. An elevation below the
> threshold will cause a local origin to be configured at the Viewpoint's
> geodetic position on surface of the ellipsoid.
>


> Once a local origin has been established at the ellipsoid surface, an
> orthodromic distance from that local origin will be used as a threshold for
> reconfiguration. When the Viewpoint moves beyond the threshold distance from
> the local origin a new origin is established, again at the Viewpoint's
> geodetic position on surface of the ellipsoid.
>

 Observable jitter and other errors become evident on the graphics display
after the conversion to cartesian step mentioned above occurs in the
simulation pipeline. Therefore, given the assumption that coordinates are
still in higher precision immediately after the conversion, a cartesian
distance calculation is all that is required to determine a threshold
distance for reducing jitter. Would that calculation not be more efficient
than great circle calculation? It is also less error prone: the more complex
calculation has higher worst case relative error. My research indicates that
relative error has a fluctuation property: occasionally spiking first in one
direction then the opposite.

regards,

chris


-- 
http://www.vrshed.com
There be greater truth at the centre.
http://www.floatingorigin.com

Association of Virtual Worlds, http://associationofvirtualworlds.ning.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/mailman/private/source_web3d.org/attachments/20090606/8c84e1e2/attachment.html>