Fist off, Cinemachine 3.x is great. Lots of good improvements!
I was really happy after seeing that Splines are now used as a basis for dollied cameras.
The problem/use case I have:
I am often creating camera-movements for cutscenes. To me it is really tedious and impractical to control exactly where the camera will look at at any given position on my position path. I first tried creating a second track for my look-at target, but this is horrendous to maintain, since both paths are pretty much “out of sync” once I make changes to one of them. I also tried just animating the rotation of my camera over time, which works, but changing the path will again require me to change the animation timings.
The feature I would like:
The new CinemachineSplineRoll component does pretty much what I want, only for the roll of the camera instead of its rotation. It adds “information points” directly onto the path. I would love to have the same component, just for Rotation, so that I can say that at time/distance t1, please look into that direction, and then at t2 look into this direction, where between these timepoints we get an interpolated rotation - just like its done with roll right now. This way I do not have to maintain a separate rotation animation or a second spline on which a lookAt target moves.
It’s an interesting suggestion but I’m having my doubts about it. Marking up the spline with specific rotations is pretty fragile. Any perturbation of the spline in the area of the markup will throw the rotation off - and that seems to be going against your goal of making it easy to maintain.
Also, how would you expect to control the easing between rotation data points?
What exactly do you mean with “any perturbation of the spline in the area of the markup will throw the rotation off”? Do you mean that when the spline changes its shape, the rotation might be different, since the forward axis of that rotation point has changed with the spine? This could be solved by employing worldspace “look directions” instead of local rotations. This behaviour could be toggleable.
Also, doesn’t the roll already have the same problem? In this case we just add two more axis to it. The roll is basically a forward z rotation, and now we add a x and y rotation to it
In terms of interpolation, that’s a good point. Quaternion interpolation can be weird. Again, how does the CinemachineSplineRoll currently solve rotation interpolation? DOTween for example has a FastBeyond360 rotation mode, which handles rotations pretty gracefully
I mean that if you set the rotation for the purpose of framing something, that rotation is only meaningful at that precise camera location. If the path shifts a bit, you’ll be looking at the wrong thing.
Yes indeed, although I think that an approach that specifies LookAt points instead of rotations or directions would be much more robust and interesting.
Your OP inspired me to develop just such a component, and I have a nice working version of it now which will very likely be included in the next CM3 release. The idea is that you assign LookAt targets (either GameObjects + offsets or absolute points in space) to specific locations on the spline. What’s nice is that no matter how the spline shifts as you edit it, you’re guaranteed that at that location on the spline, you will be looking at the targeted thing.
Current inspector looks like this:
and it comes with a nifty scene-view tool to set it up:
Roll serves a different purpose: it’s roll about the tangent of the spline. It naturally travels with the spline, and if you’re setting it in order to look at specific things, you’ll be plagued with all the maintenance issues that a full-blown rotation-baked-into-the-path will have. Not recommended.
awesome So cool to see a feature request turning from a need into a finished product! Given the size of Unity, it can feel like an overwhelming, slowly progressing, abstract entity, but this thread fully counters that notion and reminds me that behind every package and every feature are people after all that want to create a good product, so kudos!
So cool to see a feature request turning from a need into a finished product! Given the size of Unity, it can feel like an overwhelming, slowly progressing, abstract entity, but this thread fully counters that notion and reminds me that behind every package and every feature are people after all that want to create a good product, so kudos!