Viewpoint: centerOfRotation shifted in a strange way

[elmkni]

Hi Michalis,

while testing some of my X3D files I came across a problem with the Viewpoint node:

centerOfRotation seems to get altered by some internal View3DScene mechanism under certain conditions (even when there is no explicit Viewpoint given in the X3D file)!

Here is a simple example:

<X3D profile="Full" version="3.3">
<Scene>

 <NavigationInfo type='"EXAMINE"'/>

 <Viewpoint/>

 <Shape>
   <Appearance>
     <Material/>
   </Appearance>
   <Box/>
 </Shape>

 <Transform DEF="CR">
   <Transform translation=".122 -.074 -.2">
     <Shape>
       <Text string='"test rotation centre (C) 22.09.2019 Elmar Knittel"'>
         <FontStyle size=".00426" family='"SANS"' justify='"END","END"'/>
       </Text>
     </Shape>
   </Transform>
 </Transform>

 <ProximitySensor DEF="PS" size="1e4 1e4 1e4"/>

 <ROUTE fromNode="PS" fromField="position_changed"
          toNode="CR"   toField="set_translation"/>
 <ROUTE fromNode="PS" fromField="orientation_changed"
          toNode="CR"   toField="set_rotation"/>

</Scene>
</X3D>

Try to rotate the cube and you'll see what I mean ...

My best guess: some automatic scene centering mechanism tries to compensate the movement of the Text node (which makes the scene somewhat 'a-symetrical').

I can correct this behavior partially by adding a big (size="40 40 40") fully transparent cube to the scene, but that's not really a good solution.

BTW.: When I try to print out the Viewpoint settings with "Clipboard -> Print Current Camera...", I only get position and orientation but not centerOfRotation and fieldOfView, which are essential to re-create the exact view!

So please:

• Add centerOfRotation and fieldOfView to the "Print Current Camera..." menu and
• Tell me how to get around the centerOfRotation problem.

With best regards,

Elmar

P.S.: here is the the test file: view3dscene_issue_20.zip

[michaliskambi]

Indeed, we don't support Viewpoint.centerOfRotation at all right now. I tried to add support at one point in the past, but I observed that a lot of test X3D models do not set it (and using a default Viewpoint.centerOfRotation = zero would make Examine navigation weird for these test models). So instead we have an internal "center of rotation" calculated simply as the middle of scene bounding box.

I'll fix it, this way:

• If Viewpoint.centerOfRotation is not zero, we will use it (instead of the bounding box middle)

• If Viewpoint.centerOfRotation is zero (default), we will still use the bounding box middle. This is not exactly conforming to X3D specification, but this way Examine camera will work sensibly for a plethora of models that don't define sensible center of rotation.

• I think I'll add a new field, like SFBool forceCenterOfRotation, to force using the Viewpoint.centerOfRotation even when zero.

I am currently in the middle of camera refactor in the engine ( https://castle-engine.io/wp/2019/09/14/big-improvements-to-camera-api-coming-soon-and-check-out-our-game-on-nintendo-switch/ ). After that refactor, I'll handle this task (as centerOfRotation handling is also inside camera code).

[elmkni]

Hi Michalis,

thanks for your answer! -- Meanwhile I have tested with:

• OctagaPlayer 5.0.8: no centerOfRotation problem
• InstantPlayer 2.3.0: no centerOfRotation problem
• freeWRL 4.3.4: no centerOfRotation problem

and using an EventListener instead of a ProximitySensor with ROUTEs:

• X3DOM 1.8.1-dev: no centerOfRotation problem

I also tested setting a suitable boundin box via bboxSize="40 40 40" in a surrounding Transform or Group node, but that didn't work either -- bboxSize seems to be ignored.

A new field like forceCenterOfRotation would confuse the above mentioned X3D players and I want my scenes to work in all those viewers!

Adding a fully transparent cube does work (see attached files), but

• Supporting bboxSize would be a better solution.
• Adding fieldOfView to the "Print Current Camera..." menu is still a good idea.

With best regards,

Elmar

P.S.: here are the test files: view3dscene_issue_20-1.zip

[michaliskambi]

A new field like forceCenterOfRotation would confuse the above mentioned X3D players and I want my scenes to work in all those viewers!

That's a fair point.

On the other hand, I really want the scenes where the author didn't bother to set correct centerOfRotation to have useful rotations. And I encountered a lot of such scenes. Simple assuming that centerOfRotation = 0,0,0 for them would result is weird Examine camera rotations.

Possibly the sensible solution is to use centerOfRotation from Viewpoint / OrthoViewpoint always (even when it is zero), thus following X3D specification. But still calculate centerOfRotation as "middle of bounding box" when the Viewpoint / OrthoViewpoint is not specified at all. This would make Examine work OK when you don't specify Viewpoint / OrthoViewpoint nodes.

I will test this.

As for bboxSize: It is ignored for now indeed, and it is only an "optimization hint" according to X3D specification. We can automatically calculate proper bounding boxes very fast.

As for extending "Print Current Camera..." output: sure, I'll do it too.

[elmkni]

Hi Michalis,

sorry for the late answer! -- I think the 'sensible solution' is probably the best. It stays within the X3D specification, but also works for files where centerOfRotation was not explicitly set.

So, go ahead and implement it... ;)

Best regards,

Elmar

[michaliskambi]

I see this old ticket is practically identical to the point 2 ("weird center of rotation") of the issue https://github.com/castle-engine/view3dscene/issues/46 .

In the end, right now I implemented handling of centerOfRotation only when it's non-zero. Despite discussion of this ticket, with resolution:

Possibly the sensible solution is to use centerOfRotation from Viewpoint / OrthoViewpoint always (even when it is zero), thus following X3D specification. But still calculate centerOfRotation as "middle of bounding box" when the Viewpoint / OrthoViewpoint is not specified at all. This would make Examine work OK when you don't specify Viewpoint / OrthoViewpoint nodes.

Hm. Let me experiment and maybe change my mind :)

[michaliskambi]

Done, and tested. We now use centerOfRotation in the current viewpoint (Viewpoint or OrthoViewpoint). We only calculate the center of rotation automatically when there's no bound viewpoint.

[michaliskambi]

FYI, I added to view3dscene and CGE a new field autoCenterOfRotation (SFBool, default false) to Viewpoint and OrthoViewpoint.

Reason: I needed a way to say "this viewpoint doesn't contain useful centerOfRotation, calculate one looking at bounding box". For example when converting MD3 or glTF models to X3D -- MD3 or glTF have some cameras (so they are converted to viewpoint nodes) bu they don't have any useful "center of rotation" provided. Trying to use default (zero) resulted in weird "Examine" behavior for some of them, when the zero point was far from model's visible shape. So we need to restore old behavior for them, and say "ignore centerOfRotation field, use bounding box as center".

This shouldn't change anything for you, I'm just letting here know. By default when reading X3D file, autoCenterOfRotation is FALSE (so we follow X3D standard behavior and honor centerOfRotation). Menu items like "Print Camera Node..." in view3dscene will not output it when it's default. So nothing should change for your use-case.

[elmkni]

Hi Michalis,

thanks for the information!

I've tested with latest View3DScene from 12-May-2023 23:03.

1 warnings:

VRML/X3D: Error when reading, will skip the rest of X3D file: Error at line 5 column 48: Invalid X3D node content (probably unknown or not allowed field, prototype or VRML 1.0-style children) inside "Viewpoint": got "autoCenterOfRotation"

Scene URL: "D:\Temp\v4_test_scale_rotate.x3dv".
Use "File->View Warnings" menu to view these warnings again.

I see -- it is not yet compiled into the executable. But anyway, its default is FALSE, so it should have no effect on my files.

In the unlikely case, that I discover an effect of autoCenterOfRotation once it has been compiled in, I will inform you -- otherwise everything is O.K.

With best regards,

Elmar