Search Unity

  1. Engage, network and learn at Unite Austin 2017, Oct 3 - 5. Get your ticket today!
    Dismiss Notice
  2. Introducing the Unity Essentials Packs! Find out more.
    Dismiss Notice
  3. Check out all the fixes for 5.6 on the patch releases page.
    Dismiss Notice
  4. Unity 2017.1 is now released.
    Dismiss Notice
  5. Unity 2017.2 beta is now available for download.
    Dismiss Notice

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

Discussion in 'Cinemachine' started by Adam_Myhill, Aug 29, 2017.

  1. Adam_Myhill

    Adam_Myhill

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    188
    Hi Everyone,

    New CM v2.1 beta has been released here:
    https://drive.google.com/open?id=0BwhlqkMsERx4VzZoMUFMa2xQR28

    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).
    • Several jitter and judder issues resolved.
     
    Corvwyn, Jokonut, Alverik and 2 others like this.
  2. OhiraKyou

    OhiraKyou

    Joined:
    Mar 27, 2012
    Posts:
    134
    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!
     
    Adam_Myhill likes this.
  3. Jjules

    Jjules

    Joined:
    Dec 25, 2012
    Posts:
    25
    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 upload_2017-8-29_21-14-39.png
    • 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!
     
  4. sonicviz

    sonicviz

    Joined:
    May 19, 2009
    Posts:
    959
    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.
     
    Last edited: Aug 30, 2017
  5. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    310
    Yes, good point. We'll look into ways to make that less confusing.

    It's your Y damping. It's interfering with the axis motion. Turn it down and the axis will be nice and snappy.
     
  6. Jjules

    Jjules

    Joined:
    Dec 25, 2012
    Posts:
    25
    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
     
  7. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    310
    hmmm... thanks for that suggestion. Interesting. Let me think about how to do that.
     
  8. OhiraKyou

    OhiraKyou

    Joined:
    Mar 27, 2012
    Posts:
    134
    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.
     
  9. DominoM

    DominoM

    Joined:
    Nov 24, 2016
    Posts:
    189
    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
     
  10. caosdoar

    caosdoar

    Joined:
    Oct 29, 2016
    Posts:
    21
    Looks like the package is missing the file CinemachinePostFXV2.unityPackage.
    Is anywhere I can get it?
     
  11. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    310
    THanks, we're looking into fixing that
     
  12. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    310
    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 :)
     
  13. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    310
    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 :) :)
     
    Mad_Fox likes this.
  14. OhiraKyou

    OhiraKyou

    Joined:
    Mar 27, 2012
    Posts:
    134
    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.
     
    Last edited: Aug 31, 2017
  15. Jjules

    Jjules

    Joined:
    Dec 25, 2012
    Posts:
    25
    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
     
  16. Jjules

    Jjules

    Joined:
    Dec 25, 2012
    Posts:
    25
    And no problem, thank you for the awesome program! I cant wait to see how this develops
     
  17. OhiraKyou

    OhiraKyou

    Joined:
    Mar 27, 2012
    Posts:
    134
  18. Jjules

    Jjules

    Joined:
    Dec 25, 2012
    Posts:
    25
    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
     
  19. OhiraKyou

    OhiraKyou

    Joined:
    Mar 27, 2012
    Posts:
    134
    Nah, seeing it in action probably wouldn't help. But, are you using a FreeLook? Perhaps it only affects those.
     
  20. Jjules

    Jjules

    Joined:
    Dec 25, 2012
    Posts:
    25
    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
     
  21. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    310
    I think you are perhaps overestimating the purpose of the GetTargetHeading method. Its job is only to process the velocity and apply that to the reference orientation - it modifies the meaning of the Zero axis value. Velocity is only significant if the heading definition is PositionDelta or Velocity. It is absolutely correct that it should do nothing for the other cases. Have a look at GetReferenceOrientation(), implemented in the base class. This is where the other heading modes are (implicitly) processed.

    I don't know why the camera stopped recentering for you. It recenters for me with the code as shipped. I think we should look more deeply into the cause of the behaviour change for you. Any chance you could zip me up a mini-project showing the problem?

    Yes that does look rather silly. It might be a little late to change the property name now, but we could add aliases: LookAtTarget and FollowTarget. At least those can be interpreted as nouns.

    You make a strong case here. The curb feelers were removed because they were not doing what people were expecting them to do: namely avoid walls and such. We focused on making a new collider algorithm to do that effectively and efficiently. That said, you are right in pointing out the omission. I'm going to fast-track a fix for this. I'll keep you posted.
     
    Last edited: Sep 1, 2017
  22. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    310
  23. OhiraKyou

    OhiraKyou

    Joined:
    Mar 27, 2012
    Posts:
    134
    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.
     
    Last edited: Sep 1, 2017
  24. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    310
    Yes, you're right. Thanks man for being so persistent :) Big thumbs-up to you.
    Updated the beta with your fix.
     
  25. OhiraKyou

    OhiraKyou

    Joined:
    Mar 27, 2012
    Posts:
    134
    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.
     
    Gregoryl and Adam_Myhill like this.
  26. elettrozero

    elettrozero

    Joined:
    Jun 19, 2016
    Posts:
    90
    I noticed there's no more Cinemachine Post Fx, how do we control Post Processing on VCs now?
     
  27. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    310
    It's still there, but it's hidden until PostProcessing asset is installed, otherwise it won't build.
     
  28. elettrozero

    elettrozero

    Joined:
    Jun 19, 2016
    Posts:
    90
    PostProcessing was already there, you mean the corresponding version?
     
  29. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    310
    It's possible that the Cinemachine-PostProcessing adaptor package didn't auto-install, maybe because of a timestamp problem. Find the CinemachinePostFX package in the CM asset and manually install it.

    Must be PostProcessing v1. CM doesn't yet support v2.
     
  30. elettrozero

    elettrozero

    Joined:
    Jun 19, 2016
    Posts:
    90
    Said and done. You always have the solution! Why don't you run for presidence? ;)
     
  31. caosdoar

    caosdoar

    Joined:
    Oct 29, 2016
    Posts:
    21
    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
     
  32. caosdoar

    caosdoar

    Joined:
    Oct 29, 2016
    Posts:
    21
    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.
     
  33. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    310
    @caosdoar Thanks for catching that. The change in the brain had accidentally crept into the beta release. I've updated the beta.
     
  34. HarryDemch

    HarryDemch

    Joined:
    Mar 9, 2015
    Posts:
    14
    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.
     
    Adam_Myhill and Jjules like this.
  35. Carwashh

    Carwashh

    Joined:
    Jul 28, 2012
    Posts:
    220
    (I'm going off second hand info here..)

    Does this version improve/add split screen support?
     
  36. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    310
    Cinemachine supports split-screen since version 2.0, released this summer.
     
  37. rneron1

    rneron1

    Joined:
    Jun 16, 2017
    Posts:
    8

     
  38. Carwashh

    Carwashh

    Joined:
    Jul 28, 2012
    Posts:
    220
    What timestamp are you referring to?
     
  39. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    310
    I'm not sure I understand your question, but I'll take a guess.

    In the demo, Adam showed a "lame" splitscreen, i.e. both cameras showing the same thing. You can set things up so that the cameras show different things. The idea is to use the Unity layering system. Set up Unity camera A to see layer A, and Unity camera B to see layer B. Each Unity camera has a CM brain. Then assign vcams to either layer A or layer B. Camera A will see the vcams on layer A, camera B will see the vcams on layer B. This is explained in the user guide, shipped with CM.
     
    Carwashh likes this.
  40. Bltzz13

    Bltzz13

    Joined:
    Sep 10, 2017
    Posts:
    8
    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 ?
     
  41. Adam_Myhill

    Adam_Myhill

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    188
    Hi @Bltzz13, there's a section in Free Look just for that. Something to consider though, if you want the camera to face a certain direction, are you sure you want to be able to Free Look? If you don't want the user to have orbit controls, it's probably worth checking out the Orbital Transposer mode on a virtual camera body.

    If you do want orbit controls and to have the camera 'recenter' to a particular angle after they stop inputting:

    Setup your FL Heading Definition to be how you'd like. They all give different results.
    Position Delta is like a bread crumb kind of follow.
    Velocity is the direction of motion - think of a car powersliding - it's facing direction is not the same as the direction of travel.
    Target Forward is the direction your follow object is pointing - maybe try this one first
    World Forward gives you the ability to keep cameras oriented to your follow object in a world relative way. IE the camera is always 'south' of the character, etc.
    upload_2017-9-10_17-10-8.png
    Once you have that, check on Recenter To Target Heading and give it some numbers. Try 0,0

    Note you can tone down the Max Speed if you want to attenuate the inputs for just that shot.
    upload_2017-9-10_17-19-38.png


    Super important pro tip!
    With the State Driven Camera module, it's super easy to make lots of different free-look cameras and have them blend together based on animations. Don't try to make just a single free-look camera for your game, blend between lots of them based on game events or animations! 10+ free-look setups just for a character's localmotion system is not uncommon and it's super powerful!
     
  42. dylanjay9

    dylanjay9

    Joined:
    Aug 1, 2017
    Posts:
    1
    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?
     
  43. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    310
    @dylanjay9 Good questions both.

    In fact there is no distinction between preserve line of sight and pushing camera into obstacles. When a camera is "pushed in" to an obstacle, what happens is that the obstacle blocks the line of sight, so the standard "preserve line of sight" algorithm will apply. We can't tell the difference.

    A good way to handle thin pillars would be to add the concept of a grace period before a line of sight gets resolved. That way, fleeting obstructions would be ignored. It's on our roadmap.

    For the second question, unless you add intelligent navigation capabilities to the camera, there is no foolproof way to get it to never smooth its way through walls. Intelligent navigation would most likely involve adding a navmesh to your game, and rigging the camera to use it. Cinemachine does not provide this out of the box, although it could certainly be extended in that direction.
     
    Aronka likes this.
  44. Aronka

    Aronka

    Joined:
    Dec 17, 2014
    Posts:
    10
    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.
     
  45. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    310
    @Aronka As long as the vcam remains enabled, it will be updated behind the scenes, so your transitions should be smooth.
     
  46. greg-harding

    greg-harding

    Joined:
    Apr 11, 2013
    Posts:
    293
    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'?
     
  47. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    310
    @greg-harding Just when you think you've got all bases covered, another use-case comes along and throws the whole thing :) Care to zip me up a jittery package so I can have a look?
     
  48. greg-harding

    greg-harding

    Joined:
    Apr 11, 2013
    Posts:
    293
    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.
     
    Last edited: Sep 15, 2017
    Adam_Myhill likes this.
  49. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    310
    Yes, jitter/judder is a tricky thing, and it's particularly noticeable when the framerate isn't constant. Damping in particular is sensitive to this. Recently we have revisited the damping algorithm to make it less sensitive to variable framerate. I'm hoping the new code makes it into the next cut of the beta. We're aiming for end-of-month, to answer your original question.
     
  50. greg-harding

    greg-harding

    Joined:
    Apr 11, 2013
    Posts:
    293
    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.