Examine: scale/rotate produce odd results

[elmkni]

Hi Michalis,

it's again me, Elmar!

I've tested the latest view3dscene-4.3.0-win64-x86_64 from 14-Dec-2022 02:55.

When I scale in and out my test-scene (see attachment), the scaling gets "stuck" at some point and rotating disjoints the red cube from its center position.

The latter problem vanishes if I out-comment "ROUTE PS.position_changed TO COPYRIGHT.set_translation".

These problems do not occur with version 4.2.0 of view3dscene ...

Please help!

Regards,

Elmar

#X3D V4.0 utf8

PROFILE Full

Viewpoint { fieldOfView .4 }

DEF RED_BOX Shape {
 appearance Appearance { material Material { diffuseColor 1 0 0 } }
 geometry Box {}
}
DEF BLUE_BACKGROUND Transform {
 scale -20 20 20 children Shape {
  appearance Appearance { material UnlitMaterial { emissiveColor 0 0 .5 } }
  geometry Box {}
 }
}
DEF COPYRIGHT Transform {
 children Transform {
  translation .056 -.037 -.2 children Shape {
   geometry Text {
    string "test scale/rotate (C) 09.12.2022 Elmar Knittel"
    fontStyle FontStyle { size 0.00213 family "SANS" justify "END" }
   }
  }
 }
}
DEF PS ProximitySensor { size 1e4 1e4 1e4 }
ROUTE PS.position_changed TO COPYRIGHT.set_translation
ROUTE PS.orientation_changed TO COPYRIGHT.set_rotation

view3dscene_issue_46.zip

[michaliskambi]

Thank you, I have this in my TODO -- sorry for a delay, I have a few big tasks to finish this week. But I will get to this report, thanks!

[elmkni]

Hi Michalis,

it's again me, Elmar!

I tested again with the latest view3dscene-4.3.0-win64-x86_64 from 19-Apr-2023 15:23.

---

I found out, that the "stuck"-problem was caused by collision detection and picking, which is enabled by default.

If I disable it, either in the View3DScene navigation-menu or by enclosing my above test-code in

Collision {
 enabled FALSE children [
   ...
 ]
}

then I get almost the old View3DScene behavior and I can zoom in and out normally!

Is there a way to disable collision detection and picking in view3dscene.conf or via some undocumented command-line switch?

That would be more convenient than altering several thousand X3D files or to manually disable collision detection and picking every time I start View3DScene by clicking on a X3D file ...

---

But even then, one nasty problem remains:

when I zoom out (making the cube smaller) and then try to rotate it, the cube is not centered anymore!

If this new behavior is intended (I hope not), View3DScene is rendered unusable for me ...

---

The version of View3DScene from 2022-09-12 that I use daily at the moment, does not show these odd behaviors at all!

I still hope you can fix at least the centering problem, so that I can migrate to newer versions of View3DScene!

With best regards,

Elmar

P.S.: Consider updating the Jenkins build more frequently, because otherwise I always have to download allmost 700 MB from snapshot just for an up-to-date view3dscene.exe binary!

[michaliskambi]

Is there a way to disable collision detection and picking in view3dscene.conf or via some undocumented command-line switch?

Thanks for finding the issue.

The "Examine" navigation indeed honors collision detection by default in latest view3dscene, as X3D spec also says to do collisions for all navigation modes. If you don't want to use collisions, then do the same thing as in "Walk": disable collisions. Clicking on "Collisions" button in view3dscene to disable collision will do the trick.

That said, let me think about this, I'll likely change it. I know this is non-intuitive and most use-cases of "Examine" actually don't want collisions... In Castle Game Engine editor we disable collisions on "Examine" from code, for this reason. We should do it in some different way, to have collisions by default "off" for "Examine" in view3dscene.

when I zoom out (making the cube smaller) and then try to rotate it, the cube is not centered anymore!

Can you make a recording what you mean by this and/or send a testcase? Rotating the cube should work naturally, it does in my tests.

P.S.: Consider updating the Jenkins build more frequently, because otherwise I always have to download allmost 700 MB from snapshot just for an up-to-date view3dscene.exe binary!

Argh, I wasn't aware the builds on https://jenkins.castle-engine.io/public/builds/view3dscene we're stuck since January... Thanks for pointing it out. Fixed, the builds on https://jenkins.castle-engine.io/public/builds/view3dscene/ are now fresh (and will stay fresh, the builds should be done after every commit, to view3dscene or Castle Game Engine repository).

[elmkni]

Hi Michalis,

it's again me, Elmar!

You wrote:

Can you make a recording what you mean by this and/or send a testcase?

I made two short videos:

v4_test_scale_rotate_OLD_BEHAVIOR.mp4 -> shows my testcase in View3DScene from 2022-09-12

v4_test_scale_rotate_NEW_BEHAVIOR.mp4 -> shows my testcase in View3DScene from 2023-04-19

These two videos and the testcase file are in the attached zip!

v4_test_scale_rotate.zip

I hope it becomes clearer where the problem is ...

Best regards,

Elmar

P.S.: Thank you for re-activating the Jenkins builds!

[elmkni]

Why did you close the issue, the scale-rotate problem still exists ... didn't you get the videos I posted?

[michaliskambi]

1. As for collision detection during Examine:

That said, let me think about this, I'll likely change it. I know this is non-intuitive and most use-cases of "Examine" actually don't want collisions...

I fixed this in the simplest way possible, our "Examine" and "2D" navigation modes just don't make collision detection ever, right now.

Maybe I will reintroduce this idea at some point, but I guess I'll have to figure out

• a situation when it is actually useful
• and a default that makes sense (which probably means: no collision detection for "Examine" / "2D" by default; for "Walk" collision detection by default is a must (otherwise you fall down), for "Fly" -- I could go either way)
• and a way to change it in persistent way, likely.

For now, things behave just like in old versions. I agree this is more intuitive / useful, I shouldn't have changed it.

This part of the fix is already build in https://jenkins.castle-engine.io/public/builds/view3dscene/ .

2. As for weird center of rotation:

I hope it becomes clearer where the problem is ...

Thank you for the recordings and testcase! Yes, they make it clear.

The problem is that our "center of rotation" now automatically adjusts to the middle of bounding box of all objects in the scene. And the copyright text "test scale/rotate (C) 21.04.2023 Elmar Knittel" is actually making the whole world bigger, and center of rotation is between your cube and that text.

In old versions, it was working kind of by accident: we also adjusted to the bounding box of everything (including your text "test scale/rotate (C) 21.04.2023 Elmar Knittel"). But we did it only once, at model load, before the ProximitySensor starts working. So the center of rotation was still in the middle of the cube, because the text was inside the cube.

We changed this, because "calculating center of rotation only once" was causing other problems. In dynamic scenes, if you e.g. delete everything at some point, and add something else -- we actually want to change center of rotation.

The solution I did now is to add support for X3D standard centerOfRotation field on X3DViewpointNode ( https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/navigation.html#Viewpoint ). This just gives you the option to set the center of rotation explicitly, and view3dscene will no longer try to auto-calculate it.

There's a catch here: As most people don't set centerOfRotation (leaving it zero, 0 0 0), we have to ignore this field when it is exactly zero. So to make it work, set it to anything at least minimally different than 0 (even the smallest different will be OK).

All in all, change

Viewpoint { fieldOfView .4 }

in your X3D file to

Viewpoint {
  fieldOfView .4
  centerOfRotation 0 0 0.001
}

and it will be OK. Sorry -- I don't have a solution that would work for your X3D files without any modification. As I mentioned above, I would consider old behavior "good in your case but only by accident". If we calculate bounding box automatically, we are bound to sometimes calculate something non-intuitive (in case of "odd" geometry far from user's focus of view) and the right solution is just give you the power to set explicit center of rotation.

The support for centerOfRotation is part of CGE, please give Jenkins a few hours to build a CGE + view3dscene with this fix. It will be available as part of https://jenkins.castle-engine.io/public/builds/view3dscene/ .

Why did you close the issue, the scale-rotate problem still exists ... didn't you get the videos I posted?

Sorry, I simply didn't see you posted the videos when I was closing the issue by a GIT commit (I made it at almost the same time you posted videos). I wanted to then ask you to reopen the issue when you submit the videos, and consider the main issue (collision detection at zoom) closed until then. I should have instead wait :), I didn't expect you to send the videos so quick -- thank you very much for this!

[michaliskambi]

There's a catch here: As most people don't set centerOfRotation (leaving it zero, 0 0 0), we have to ignore this field when it is exactly zero. So to make it work, set it to anything at least minimally different than 0 (even the smallest different will be OK).

Let me experiment, I may rethink this. This is also tracked now in #20 -- an old ticket, where us both discussed the same thing :)

[michaliskambi]

There's a catch here: As most people don't set centerOfRotation (leaving it zero, 0 0 0), we have to ignore this field when it is exactly zero. So to make it work, set it to anything at least minimally different than 0 (even the smallest different will be OK).

I changed the decision here. We now use centerOfRotation if viewpoint is bound (regardless of if it's zero or not).

Internally CGE has properties on TCastleExamineNavigation:

• AutoCenterOfRotation: Boolean (default true) and
• CenterOfRotation: TVector3 (default zero)

But for X3D authors, things are more following X3D spec: we just use viewpoint's centerOfRotation, and do not require any additional boolean to make it work. We auto-calculate center of rotation only when there's no viewpoint.

This change is part of Castle Game Engine -- please give Jenkins 6-8 hours before it is available in view3dscene builds.

[elmkni]

Hi Michalis,

it's again me, Elmar!

You wrote:

please give Jenkins 6-8 hours before it is available in view3dscene builds.

I've waited patiently for 16 hours now, but still no updated View3DScene, neither on Jenkins nor on GitHub.

The changes regarding collision detection are included though (in the so far latest Jenkins build from 20-Apr-2023 23:09)!

Am I missing something?

Please help!

With best regards,

Elmar

[michaliskambi]

I've waited patiently for 16 hours now, but still no updated View3DScene, neither on Jenkins nor on GitHub.

The server on which the CGE builds are made indeed run into disk issues earlier today, and in effect a long build failed at the very end (before it was packed to zip).

I fixed it and the next build is running. Sorry, please just wait a few hours more.

You can easily check when this is done looking at this page: castle-engine/castle-engine@snapshot...master . It shows the commit not included in the CGE (in effect, not used by view3dscene builds too). Right now it includes 8 commits, including one with log "Use viewpoint centerOfRotation when viewpoint is <> nil...". Once this page will be empty, it will mean the fix is in CGE. Shortly after (like 15 mins) the new view3dscene on https://jenkins.castle-engine.io/public/builds/view3dscene/ will be available.

[michaliskambi]

OK, this is just not a good week for Jenkins :) It really should be more reliable. Something for me to improve. Maybe by just migrating GitHub Actions more.

But the Windows and Linux builds, of Castle Game Engine and of view3dscene, are now build and include all the fixes related to this ticket. You can download latest view3dscene from https://jenkins.castle-engine.io/public/builds/view3dscene/ , and Windows and Linux builds contain everything fixed.

( If you are on macOS or Raspberry Pi -- then unfortunately you'll have to wait a bit longer. )

[elmkni]

Hi Michalis,

it's again me, Elmar!

I've just downloaded and tested the most recent version of View3DScene from Jenkins (21-Apr-2023 22:29).

---

Finally everything works!

It's even better:

I could now delete the surrounding inverted box, that I only introduced to my scenes to circumvent View3DScene's automatic center computation by enclosing the copyright notice and the actual 3D object with a super-object that would force the center of the scene to be computed as to be at <0,0,0>!

But I actually keep the box, because I use it now for attaching an effect shader to it, that produces a nice background image.

• I could use ImageBackground (that you have so kindly implemented) as well, but I like it if all parts of a scene are kept within the X3D file (in highly compressible text form).

• Another reason why I prefer the effect shader solution is, that it doesn't first strech the used image to the next power of 2 size and then scales it down again to the actual size of the window, which causes blur (especially with JPEG files, that allready contain visual artifacts). The image produced by the effect shader in contrast is very crisp and highly compressable!

• The third reason is that an effect shader can easily be ported to an composed shader to be used in other X3D viewers!

---

And the best thing is, that I don't have to change my files in any way!

No centerOfRotation 0 0 0 or centerOfRotation 0 0 .001 needed! I just need Viewpoint {} as a minimum to get my scenes centered at <0,0,0>.

---

I'm so happy that this nasty centering issue is finally solved!

Thank you so much for your hard and tireless work!

I appreciate it!

With very best regards,

Elmar

---

P.S.: Now only issue #52 (PixelTexture3D as emissive texture) and (not so important) issue #17 (periodic NURBS) remain ... ;)