[x3d-public] Viewpoint centerOfRotation global or local

[Don Brutzman]

Wow, very curious and surprising case.  Having /centerOfRotation/ in global space might explain some navigation anomalies as well.

On 12/5/2020 8:01 PM, Andreas Plesch wrote:
> 
> I was surprised that x3dom uses the global coordinate system for
> Viewpoint's centerOfRotation field. But it turns out that the spec.
> does not say that it is given in the local coordinate system
> 
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/navigation.html#X3DViewpointNode
> https://www.web3d.org/x3d/content/X3dTooltips.html#Viewpoint
> 
> So using the global coordinate system seems appropriate.

Interesting question.  Gosh I thought the other questions were tricky, this takes the prize for today...  :0

Let's give it a try.  Following your trail, am thinking there are (at least) three specification sections of interest:

==================================================
X3D4 Navigation component, 23.3.1 X3DViewpointNode
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/Part01/components/navigation.html#X3DViewpointNode

[...]
The position and orientation fields of the X3DViewpointNode node specify relative locations in the local coordinate system. Position is relative to the coordinate system's origin (0,0,0), while orientation specifies a rotation relative to the default orientation. In the default position and orientation, the viewer is on the Z-axis looking down the −Z-axis toward the origin with +X to the right and +Y straight up. X3DViewpointNode nodes are affected by the transformation hierarchy.

[...]
The /centerOfRotation/ field specifies a center about which to rotate the user's eyepoint when in EXAMINE mode. If the browser does not provide the ability to spin around the object in EXAMINE mode, or LOOKAT is not in the list of allowed navigation modes, this field shall be ignored. For additional information, see 23.4.4 NavigationInfo and 22.4.1 ProximitySensor.

==================================================
X3D4 Grouping component,

The transformation hierarchy includes all of the root nodes and root node descendants that are considered to have one or more particular locations in the virtual world. X3D includes the notion of local coordinate systems, defined in terms of transformations from ancestor coordinate systems. The coordinate system in which the root nodes are displayed is called the world coordinate system.

[...]
Some nodes, such as Switch or LOD, contain a list of children, of which at most one is traversed during rendering. However, for the purposes of computing scene position, all children of these nodes are considered to be part of the transformation hierarchy, whether they are traversed during rendering or not. For instance, a Viewpoint node which is a child of a Switch whose whichChoice field is set to -1 (indicating that none of its children should be traversed during rendering) still uses the local coordinate space of the Switch to determine its position in the scene.

==================================================
X3D4 Navigation component, 23.4.6 Viewpoint
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/Part01/components/navigation.html#Viewpoint

[...]
When the viewAll field is set to TRUE or a viewpoint is bound with viewAll field TRUE, the current view is modified to change the centerOfRotation field to match center of bounding box for entire visible scene, and the orientation field is modified to aim at that point. Finally, zoom position in or out until the bounding box containing the entire scene is fully within the current viewing window. If the current view is within a model, any intervening geometry does not block the change in position. No collision detection or proximity sensing occurs when zooming. If needed, near and far clipping planes shall be adjusted to allow viewing the entire scene. When the value of the viewAll field is changed from TRUE to FALSE, no change in the current view occurs.

==================================================
(viewAll defined similarly for OrthoViewpoint)
==================================================

So we can at least say that the the global coordinate system is _not_ appropriate for resulting /position/ or /orientation/ values, even if any intermediate calculations were performed in global coordinate space.

Your point is well taken that centerOfRotation frame of reference does not appear to be defined.  Certainly having a definition is expected.  There is no mention or consideration of global scene coordinates except for viewAll computations.

Simplest specification revision is to add a sentence to 23.3.1 X3DViewpointNode stating,

	"The /centerOfRotation/ field is in the same local coordinate system as the current viewpoint node's /position/ and /orientation/ fields, in accordance with _4.3.5 Transformation hierarchy_.

We should be very careful here because the Viewpoint itself might be in a moving reference frame.  That has to be considered and may often be the case when rotating the current view around another nearby object in that same moving reference frame.

Meanwhile, at the moment you shift into VIEWALL mode, having a global perspective is needed for computations.  Once viewAll realignment is complete, the user expects to be able to rotate or move relative the center of the scene.  If the currently bound Viewpoint is moving, then everything seen following the initial viewAll shift also moves.

Hmmm.  Is this an expected behavior or not, i.e. a feature or a bug?

Am thinking that this is reasonable and consistent behavior with /centerOfRotation/ /position/ and /orientation/ fields all in the same local coordinate system.

Exemplar use case #1: Viewpoint with initial viewAll TRUE that is being animated to provide a grand tour.  Probably have Viewpoint parent hierarchy at center of scene, have Viewpoint initial position wherever you want, and have animating PositionInterpolator values given relative to that center of the scene for a smoothly interpolated guided path.

Exemplar use case #2: avatar is navigating freely throughout town and has a secondary viewpoint that always turns to look at center of scene/town when bound.

So according to this line of thought, the answer to your question is that /centerOfRotation/ is always in the same local coordinate system as parent Viewpoint.

Interesting, tricky business.  Please advise (anyone) if you have a better way to express this.

> Relatedly, the new viewAll field affects the centerOfRotation field:
> 
> "When the viewAll field is set to TRUE or a viewpoint is bound with
> viewAll field TRUE, the current view is modified to change the
> centerOfRotation field to match [the] center of bounding box for
> entire visible scene, and the orientation field is modified to aim at
> that point."
> 
> Here, the new centerOfRotation would make more sense to be given in
> the global coordinate system since the entire scene is considered.
> But, of course, it would be possible for the browser to compute the
> corresponding position in the Viewpoint's local coordinate system as
> well.

correct and agreed, copied above to craft a linear response.

> So is x3dom correct in using the global coordinate system (ignoring
> outer Transforms) for Viewpoint's centerOfRotation field ?

it will be interesting to see what other implementations have done.

> Thanks, Andreas

all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman