Please let us know if you find any bugs, things you like, things you don’t like, everything. We really appreciate your feedback
New Features
New Collider implementation. Curb feelers are gone, replaced by a clever camera-repositioning algorithm that will try to preserve camera height or distance from target (strategy is user-selectable).
New CinemachineConfiner confine a virtual camera to a simple bounding volume.
New Framing Transposer. This is a special transposer that will respect composition and framing rules by moving the camera without rotating it. Takes only a Follow Target (no LookAt - this is important). Designed for Orthographic cameras, but will also work for Perspective cameras. If Follow target is a CinemachineTargetGroup, then will also provide Group Framing options.
New CinemachineMixingCamera. Drive a continuous blend of up to 8 virtual cameras from timeline or game logic. Create complex rigs with custom blends and expose them as ordinary vcams.
New CinemachineDollyCart. for moving anything along a path. No need to create dummy vcams just for that.
Path now supports Distance Units in addition to Path units, making it easy to create steady motion.
TrackedDolly: added ability to use Distance or Path units for path position.
Transposer and TrackedDolly: added target angular damping on 3 axes. This makes for great follow cameras for driving / flying / chase type scenarios.
OrbitalTransposer and FreeLook: added angular damping and binding mode, same as Transposer.
OrbitalTransopser and freelook: added checkbox to invert input axis.
Added IgnoreTimeScale option to Brain. Useful for snappy cameras even in slo-mo.
Improvements
Added off-button for SaveDuringPlay. Default is OFF
No SaveDuringPlay for vcam priority, LookAt and Follow targets, GroupTarget members.
Added IsBlending API method to StateDrivenCamera and ClearShot.
TargetGroup now has a user-selectable update method.
TargetGroup now respects the weight when computing bounding box, so it’s possible to gradually add or remove members by manipulating the weight.
Clearshot: if randomize, then re-randomize whenever it becomes active.
ClearShot: default blend is cut.
ClearShot create menu: add a Collider by default.
FollowZoom: min/max FOV defaults changed to 3/60.
Composer damping range is now 0-20 instead of 0-100.
TrackedDolly: added path position offset to Auto-Dolly. Stays on the path (unlike path offset, which is based on the path tangent and so can go off the path
Two new example scenes, more coming with the final release version
Bugfixes
SaveDuringPlay obsolete API fix for 2017.2.
Fixed build errors when building for UWP.
Clearshot and SDC: don’t reset state if deactivated.
FreeLook destroy - no more orphan rigs.
Fixed strange build error that only showed up in MonoDevelop.
FreeLook was not respecting X-axis accel and decel. Heading speed had to be crazy high. Now same as Orbital (warning: may have to re-tune settings on existing FreeLooks).
Nice changes and lots of stuff I can see immediate uses for. I’ll have to check out some of those new components. The Framing Transposer brings to mind the Super Smash Bros. camera.
I’ll probably test out the changes within the next day or two. Thanks to everyone for the solid work!
Ive just fully integrated it into my project and a few things immediately pop out to me about the Freelook Cam:
5 different binding modes are front and center. This is great, and really makes the tool feel more versatile!
It seems to be a lot better at accounting for jitter on the player!
I noticed you pulled the height and radius settings out. These are important settings, so making them front and center like this is the right move
one thing that confused me is that in the individual rig settings (top/middle/bottom rig), the body section is greyed out because you arent allowed to change the tracker type from “Orbital Transporter”, but for a long time I didn’t even now there were drop down settings you could change because the entire line is greyed out. This is probably a limitation of Unity’s UI, I understand, but if you could make the “Body” text black it would do wonders for the user experience
I dont know if im doing something wrong here, but while camera rotation along the x axis works beautifully, camera rotation along the y is at a snail’s pace regardless of how high I crank up the max speed (and regardless of my spline tension settings)
All in all though, its a fantastic update. Keep up the good work!
Ah, thanks. Turned the Y damping on each rig (top, middle, bottom) down to 5 and it worked like a charm
Also, I have one more important piece of feedback about the Collider. It works great, and does everything I expect it to do, but one feature that would do wonders is allowing different damping values for zooming in (to avoid obstacles) and zooming out (once the coast is clear). I say this because I obviously need the zoom in to be snappy to avoid the obstacles in time, but there’s no rush zooming out, and doing it too fast is soooo disorienting. A result is a camera that kind of jerks all over the place back and forth. Just like transitions can say A > B 2 seconds, B > A .5 seconds, it would be great to have that same sort of functionality with the collider
Alright, so I just gave the 2.1 beta a try in my project. I haven’t tried the new components yet; just cleaning things up for now.
Immediately, I noticed that the “target forward” heading’s case is blank in CinemachineOrbitalTansposer.cs. After this:
case Heading.HeadingDefinition.TargetForward:
Add this:
velocity = VirtualCamera.Follow.forward;
break;
Incidentally, using a verb like “Follow” for an object is an exceptionally weird thing to do. Save that for functions.
Also, the collider needs some ejection code, as the clipping is super real.
And, on an unrelated note, moving all three rigs of a free look up or down is such a common thing that there seriously needs to be a height offset. I’d much rather use the heights to define separation and a single value to define position. Managing three values instead is a pain. There’s no way to simply drag a value up and down and immediately see the results. By the time you calculate the proper offset for all three values, you’ve already forgotten what the shot looked/felt like in the first place and have to reset them. And, if your heights are not in clear, incremental steps (e.g., one is 1.357, the other is at -0.0432), maintaining separation while tweaking is just not viable at all. Being able to change a single value and immediately see the results is a big deal. Without it, the experience is like filling out a survey between trying out two different eyeglass lenses.
That’s it for now. Thanks for the updates. Cinemachine saved me from some major headaches already with my third person character camera alone.
There’s an issue with Cinemachines asset store “View License Agreement” link. It’s only displaying up to the first “(” - you have to install Cinemachine to read the full license.txt
Thanks for posting. There was a problem with timestamps in the released beta version: the auto-import isn’t working because it thinks the PostFX stub is up-to-date. But everything is there, you just have to poke it. Go into your project assets and delete CinemachinePostFX.cs, and the auto-import should happen. I’ll update the beta with the fix.
EDIT: oops, sorry I didn’t read your post properly. You’re looking for PPV2. That doesn’t exist yet, but we’re working on it
I think the code was correct as shipped. What issue does this suggested change address?
Good point. Possibly better names for these fields would be LookAtTarget and FollowTarget. Alternatively, you could look at these fields as being commands, as in Look at this thing, or Follow that thing. That was our thinking in choosing the names.
Can you elaborate a little on this? I don’t quite understand what you mean.
Excellent suggestion! We’ll add that to our list.
Thanks for all your feedback, we really appreciate your effort
The TargetForward heading does literally nothing at all without it. It’s completely unused, falling back on an unrelated case. Setting velocity to Follow.forward as I have is the expected behavior. After updating to 2.1, the camera stopped recentering to behind my character. This was the obvious cause.
Functions are commands. Fields are not. Calling it Follow is no different than calling it DoAThing. It doesn’t make any sense to the core audience using this field: programmers. And, it can lead to really misleading, nonsensical code like Follower.Follow(Camera.Follow).
By ejection code, I mean an algorithm to push the camera away from nearby colliders (toward the player) such that it doesn’t partially clip through geometry. Perhaps this isn’t noticeable with the default field of view of 40 (I haven’t checked), but with any game-ready field of view that doesn’t cause discomfort to people prone to simulator sickness (e.g., a minimum of 90), using the collider component (set to pull forward), this degree of clipping happens against all surfaces: Nytro - Cinemachine collider - camera clipping - Album on Imgur
The whole point of feelers was to prevent this sort of thing. Having a third of the screen looking through floors, walls, and terrain isn’t exactly ideal.
what settings do you have on the collider? is your dampening too high? Because I have a game-ready locomotion system in a stage with unforgivingly tight corridors, and the camera doesn’t clip for me when i set the dampening low enough
that’s odd. Like I said, I dont have clipping issues with my collider, it works as expected for me. I would show you a video, but that’s honestly more trouble than it’s worth lol, but I can if you really want it
yes, I am using a freelook with a dedicated late called “camera obstacle” that it looks for. It doesn’t anticipate the collision, so it’s kinda jerky, but it works for me
