Virtual camera transform update timings

[unity_6255F9AC6E8A43BB555E]

Hi, I have a vcam with an OrbitalTransposer and CinemachineInputProvider. I’m using floating origin (Space Graphics Toolkit), so I need to control exactly when things move. I was under the assumption that the virtual cameras only update their transforms in the brain’s ManualUpdate (I have it set to Manual Update). My intention is to snap the camera back to origin immediately after it is moved. But from the included image, it seems that my vcam’s transform is updating before ManualUpdate is called (along with the main camera), causing a view frustum error at some point before I can get to it (I am orbiting above a solar system, causing large movements). The only thing affecting the vcam’s transform is the CinemachineInputProvider that alters the OrbitalTransposer’s angle. So does the vcam’s transform get modified at some point other than ManualUpdate? And is there a way to hook in to that timing?

V: Vcam position M: MainCam position

[Gregoryl]

I don’t really have enough context to tell you what’s happening here. The vcam’s position certainly is weird in the “before manual update” output. Is the vcam parented to something that got moved? Same question for the camera.

Perhaps you can show the hierarchy and explain a bit what gets moved (by your code) and when.

Cinemachine should not be touching any vcam transform or invoking any pipeline calls outside of ManualUpdate.

If you need to do some post-processing after CM has placed the main camera, a good way to do it is to hook into CinemachineCore.CameraUpdatedEvent, which is fired immediately after the camera has been positioned (which usually happens in CinemachineBrain.LateUpdate).

Another good technique (if your vcams are tracking stuff that gets snapped) is to use CinemachineCore.OnTargetObjectWarped().

Can I ask why you’re using ManualUpdate mode instead of the more manageable LateUpdate setting in the CM Brain?

[unity_6255F9AC6E8A43BB555E]

Hi Gregory, thanks for the quick and detailed reply! Didn’t have much time the last day or two, but I’ve been tinkering with it here and there.

The vcam changing position problem resolved itself after restarting Unity (should’ve done that first).
As for the out of view frustum error, I was using an extension to do a floating origin snap during the body stage callback, which was probably bad and wrong and messed up Cinemachine’s flow. I basically wanted to move → snap → orient. I was avoiding OnTargetObjectWarped because I didn’t realize it forced an immediate position change, which was exactly what I needed (almost like it was designed for cases like this!!)

So the initial issues are resolved, however I am still getting some jitter. It’s a rough solar system simulation so the movements are large. The process goes like this now:

Update:
UpdateData() //Stored as doubles with a local and global position
UpdateTransforms() //Converts data into world position for Unity

LateUpdate:
TrySnap() //Runs when camera is reacting to celestial body movement
brain.ManualUpdate()
TrySnap() //Runs when camera is the cause of movement (user input, prevents out of view frustum error)

I’m still using ManualUpdate (SEO 90, the brain immediately follows at 100) just so I can more easily wrap it in TrySnaps (which just snaps as long as the camera moved far enough). I’m avoiding using events just because Unity seems to like giving out of view frustum errors unless it’s timed exactly like this.

Anyway, here’s a video of me enabling and disabling the “Pre Cine Snap” and how it affects the jitter (the object is following an orbital path where it moves 1e10+ each frame):

Kinda hard to see, but with it enabled, it’s aligning with the center of the object perfectly (which is the center of the hexagonal shape closest to the camera), but it’s not at the exact right location, and so it orients itself differently each time as well. It seems like a floating point error but the vcam gets put back near origin before the ManualUpdate. When the simulation is stopped, it ends up at the intended position and orientation. There’s no damping, either.

These are logged directly following each brain.ManualUpdate(). Also the “Vcam Offset” means its expected value, aka its settings.

Anyway, I rambled a lot and now I realize this may not even be a Cinemachine related question anymore, so I can mark this resolved and make a new post if you want. In any case, thanks for your help!