Viewpoint Behavior inside GeoLocation

[npolys]

In an interesting twist, I found that when I wrap
a scene (a local set of coords) with an offset under GeoLocation

Viewpoints have an interesting (bug?) behavior:

while their position and orientation is all correct in the local scene (unwrapped)
the centerOfRotation must be in the geocoords.

This is difficult if one is using the 'd' debug and 'v' to cut and paste viewpoint parameters.

otherwise, wild navigations abound!! :-\

I assumed that the center of rotation would also be in the local coordinate system.

[andreasplesch]

A little bit hard to follow without an example. Do you have one ?

[andreasplesch]

https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.proof/Part01/components/geospatial.html#GeoViewpoint is indeed silent how center_of_rotation is defined. x3dom expects geocoords for cor there.

But I think you are using a regular Viewpoint under GeoLocation, as it is not recommended and rather meaningless to use GeoViewpoint (or any geospatial node) under GeoLocation.

So I think this may be unrelated to GeoSpatial. A regular Viewpoint under a Transform may also require cor in world coordinates (a bug). I remember some transformed Viewpoint issues being fixed in Examine navigation but perhaps not cor.

I think 'v' always reports global values.

[andreasplesch]

x3dom/src/nodes/Navigation/modes/DefaultNavigation.js

Line 823 in 434365a

viewpoint.setCenterOfRotation( view._pick );

sets the viewpoint field to global coordinates on double click. ( This would either need to change to local coordinates or a non persistent helper be used like view._trans).

x3dom/src/nodes/Navigation/modes/DefaultNavigation.js

Line 681 in 434365a

var center = viewpoint.getCenterOfRotation();

assumes that the field is in world coords, similar elsewhere.

Since a getter and setter is mostly used, it may be possible to switch to local coordinates by finding all calls.

'v' reports world coordinates for position and whatever the field value currently is for cor.

'v' could print two choices: one vp in world coords. for inclusion in toplevel, and also on in local coords for the current vp, for replacing a transformed vp.

So, it should be possible to fix the cor situation but it is rare that local coords. for cor are actually needed. Transformed vps are usually only used for animation without a need for cor, and for interactive use cor will be functionally set on double click while the initial value can be figured out pretty easily (for example by clicking on the desired cor and reading off the reported position). That leaves really standard conformance which would be good.