CM v2.1 beta release: New features, new fixes, improvements, examples,

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!

 

Hi,
I upgraded to the beta but getting errors on

vcam1OrbitalTransposer.m_HeadingBias = headingBias;
vcam1OrbitalTransposer.m_HeightOffset = heightOffset;
vcam1OrbitalTransposer.m_Radius = radius;

I'm programmatically switching cameras and generating new camera positions in the x,y,z using the above fields. At least I was, but not now.

Could you explain why the change and what is the new replacement to implement to achieve the same behavior?
I can't see anything in the docs.

Edit:
Never mind, found it.

//Cinemachine V2.1 has changed these
var m_FollowOffset = new Vector3(0, heightOffset, -radius);
if (vcam2.enabled)
{
vcam1OrbitalTransposer.m_Heading.m_HeadingBias = headingBias;
//vcam1OrbitalTransposer.m_HeightOffset = heightOffset;
//vcam1OrbitalTransposer.m_Radius = radius;
vcam1OrbitalTransposer.m_FollowOffset = m_FollowOffset;
}

Be nice if you could add some guide to what has changed.

ty.

 

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:

Code (csharp):

1. case Heading.HeadingDefinition.TargetForward:

Add this:

Code (csharp):

1. velocity = VirtualCamera.Follow.forward;
2. 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

 

Looks like the package is missing the file CinemachinePostFXV2.unityPackage.
Is anywhere I can get it?

 

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: http://imgur.com/a/px2e2

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

 

And no problem, thank you for the awesome program! I cant wait to see how this develops

 

Collider settings: http://imgur.com/a/Gon2p
Damping is 0.

 

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

 

Nah, seeing it in action probably wouldn't help. But, are you using a FreeLook? Perhaps it only affects those.

 

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

 

The issue isn't that it is not recentering. The issue is that it is recentering using the wrong method.

The purpose of GetTargetHeading is to get a value representing yaw from the target using the method assigned, no matter what that method is. "Velocity" is just the in-scope name for "current target forward vector" and is processed to get a yaw value in that function. This is just another case of misleading naming, because how fast the target is moving is enitrely irrelevant, as long as the HeadingTracker can get a non-zero forward vector from recent values.

Below is the old (untouched, pre-2.1) code and a screenshot from my repository diff showing it within the context of updating to 2.1. The old code used a simpler method of returning the target's rotation Y (which I don't recommend, because it ignores the current CameraState's reference orientation that is passed into the heading function), but the function's job is very clearly to produce a value representing target yaw.

2.1 update diff: http://imgur.com/a/1bUag

Code (csharp):

1. case Recentering.HeadingDerivationMode.TargetForward:
2.    return VirtualCamera.Follow.rotation.eulerAngles.y;

The expected behavior for HeadingDerivationMode.TargetForward is that the camera will be behind the target, looking in its forward direction, after recentering. This was the case pre-2.1 due to the above code (which I do not recommend) and is the case with my alternative code (which I recommend over the old code above). But, without either of them, TargetForward falls through to WorldForward instead, causing the camera to look in the same direction regardless of the target's forward vector. Again, the issue isn't that it isn't recentering. The issue is that it is recentering using the wrong method. I can say with 100% certainty that this is not an issue with my project specifically.

Cool, thanks. I'll check it out shortly.

 

I tried the build with the camera radius property in a bunch of corner cases, some very literal, and I must say that it's super slick. With a properly calibrated radius, its resilience exceeded my expectations. So, major props on the new collider.

In my platformer project, I've been procedurally modifying a FreeLook's values to create three separate smart (player-responsive) camera modes that can be cycled with the 'c' key, and it's been working out great. If you'd like to see how the resulting third person controller works using Cinemachine, I have a demo on itch.io.

I may not get around to testing the other components for quite some time, but, with a custom controller, the FreeLook is in a pretty good place.

 

I noticed there's no more Cinemachine Post Fx, how do we control Post Processing on VCs now?

 

PostProcessing was already there, you mean the corresponding version?

 

Said and done. You always have the solution! Why don't you run for presidence?

 

I am having some trouble using noise in this version.

Using any of the presets from the package the effect is quite extreme, the camera jumps from one position/orientation to another. Even if I reduce the amplitude and frequency gain to something small but noticeable (like 0.05) the camera vibrates instead of producing a smooth movement.

To reproduce it:
New project with cinemachine.
Add the brain to the camera and a virtual camera.
Set noise in the virtual camera to "Basic Multi Channel Perlin" and select any preset.
Add a cube or some other object in front of the camera.
Run

Cheers

 

I think I found the source of the problem.

The values produced for "time" in CinemachineBasicMultiChannelPerlin::MutateCameraState() are inconsistent, sometimes you can get a "time" value lower than the one for the previous frame and that is because "deltaTime" changes frame to frame. Therefore the line:

float time = mNoiseTime * deltaTime * m_FrequencyGain;​

is not a valid way to get the time for the frame (mNoiseTime being a frame counter).

This did not happen on previous versions as the "deltaTime" value given was Time.fixedDeltaTime but this changed in CinemachineBrain::LateUpdate() for this version. As the line:

float deltaTime = GetEffectiveDeltaTime(true);
​

Is now:

float deltaTime = GetEffectiveDeltaTime(false);
​

Reverting that particular line fixes the problem I was having.

 

Just checked the new version.
Adam, Gregoryl, you guys are beautiful! Now CM works for my 2D game like a freaking magic out of the box!
Create 2D vcam, place a follow target, tune dead zones and a couple of other numbers and that's it!
Everything works perfect so far.

 

(I'm going off second hand info here..)

Does this version improve/add split screen support?

 

What timestamp are you referring to?

 

Hello I have a question. I am using cm free look camera and I have my third person character how can I make him face the camera direction while walking ?

 

I have a couple questions.

Is there a way to setup the collider so that I can ignore thin pillars when preserving line of sight, but still collide with them when pushing the camera into them?

Also, is there a way I can make the collider's line of sight damping setting smoothly move along its collided path instead of moving through the object and then smoothly moving to its endpoint?

 

Is there any way to keep updating FreeLook Camera position and rotation when it's in standby state? I have second Dolly camera in the scene and want to have smooth transition between Dolly and free look when the path ends.

 

We're getting lots of jitter/judder in the Asset Store 2.01 with simple rigs that look at targets that travel in straight lines (exactly as mentioned in the Crazy Jitter thread https://forum.unity.com/threads/cinemachine-crazy-jitter.465865/) so we're looking forward to testing the jitter fixes in 2.1.

Also, thanks for adding the 'SaveDuringPlay' option - we were about to add that in ourselves.

Any rough date for the 2.1 release yet... or 'when it's done'?

 

I haven't tested your v2.1 beta yet - we're still on the v2.01 release version from the Asset Store. I will download the beta shortly and check it out. If it misbehaves I will let you know and prepare a repro project.

We're using Cinemachine v2.01 and Timeline, with a dolly camera on a straight path that moves along next to and looking at a target for a while, and then stops moving as the target moves off into the distance. With the aim damping at default 0.5,0.5 and the aim dead zone at 0,0 it judders/jitters like crazy, especially at distance. It can be helped by adding some dead zone and tuning the damping but seems very dependent on framerates as well. This is quite a simple case - essentially a fully snapped lookAt camera just LateUpdating to look at a (non-physics) target moving in a straight line.

Other than that, so far our tests and basic use of Cinemachine v2.01 to replace a few of our camera moves has been great. Thanks to you, @Adam_Myhill and your team for the great work.

Edit: Just checked v2.1 beta and possibly the jitter seems reduced... but it's still there. I suspect it's my poor tuning rather than a bug. If I can repro it with some cubes I'll send it.

 

Thanks for the reply

I stripped a test scene and exported a package with Cinemachine 2.1 beta: cinemachine-jitter.unitypackage

I've left the default damping 0.5,0.5 and clamped the aim dead zones to 0,0 so it's probably my tuning but you can take a look just in case. The timeline just blends the intro to the dolly cam, then moves the dolly cam along as it looks at the moving cube go off into the distance. Potential problems are damping, deadzone clamp, and the distances being quite large units. The jitter is really noticeable in our project with the moving cube being rendered over a skybox mesh (rendered with another camera). More variable framerates with lots of geometry and postfx makes it a lot more obvious.