ArcRotateCamera upVector crashes

I am using babylon react and if I set the arcRotateCamera upVector to anything but 0,1,0 (default) it crashes. See image below.

 <arcRotateCamera
            name="camera1"
            target={cameraRotationPoint}
            upVector={new Vector3(0, 1, 0)}
            alpha={-1}
            beta={2.5}
            radius={0}
          />

I have my scene setup in a way that the arcate rotate rotates around the wrong axes and instead of rotate all object I thought maybe it is enough to change upVector.

1 Like

This works fine in the playground Babylon.js Playground

Maybe @brianzinn would have an idea ?

1 Like

The renderer doesn’t treat that property different than other Vector3’s. ie: target that you are using

Do you have a repro or can share more of the code? I can try it out when I get home, but what you have ought to work.
edit: actually easy to repro. I’ll try to track the bug tonight

What react-babylonjs does is try to reduce GC memory pressure by re-using objects. Check this PG:
Babylon.js Playground (babylonjs.com)

This line crashes babylon:

scene.activeCamera.upVector.x = 0.6;

Solutionwise - I think I know the problem - it’s because we don’t call the upVector setter and other code depends directly on the vector being normalized and setMatUp() being called. Almost like Vector3 should publish an event, so we don’t need comments like here (but it’s well documented at least!):
BabylonJS/Babylon.js (github.com)

I did something similar in GUI to observe changes and update accordingly, but I think would not be considered on an essential class like Vector3:
add ValueAndUnit change tracking · BabylonJS/Babylon.js@9bf8875 (github.com)

I can see in the TypeScript compiler when the property is a “set accessor” or not. For correctness I can deoptimize that. ie: if Babylon.js doesn’t check if the Vector3 is dirty etc. I think any solution downstream in Babylon.js will have performance impact and add some code clutter. Let’s hold off to see if this is deemed a bug - otherwise I’ll fix upstream that setters are called instead of their nested props.

@sebavan is that a bug or just by design and need to deal with it as-is? Cheers