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

ping @sebavan again for visibility

1 Like

Thanks @carolhmj !!!

I would say it is by design mainly for perf as you mentioned.

Thanks for official confirmation. Noted as “won’t fix”. Totally fine as it’s a really small edge case and even well documented in the property.

Once I added the fix downstream I was completely surprised how many setters there are – even the position of a TransformNode has this behaviour.
Babylon.js/transformNode.ts at master · BabylonJS/Babylon.js (github.com)

So setting transformNodeInstance.position.x = 2 vs. position prop changes result of _IsSynchronized.. resulting in essentially what looks like “non-deterministic” behaviour from seemingly identical changes. I think an audit of the library would bring to light many more potential issues. As I mentioned the fix is “easy but tedious”, but the performance and memory are of utmost importance. Definitely interesting to look at the impact of and to revisit design decisions.

@Todilo same issue reported on github ( ArcCamera setting upVector crash · Issue #250 · brianzinn/react-babylonjs (github.com)), so you can track there the fix and I think put sebavan response as solution here if you like. cheers.

1 Like

hi @Todilo sorry this took so long - the code was committed to repo the day after your original question was asked! anyway - it’s out now on version 3.1.13.

Thank you very much. I did a workaround in the meantime but actually need to update my code for other reasons so I will definitely check it out.