Search Unity

  1. Check out the Unite LA keynote for updates on the Visual Effect Editor, the FPS Sample, ECS, Unity for Film and more! Watch it now!
    Dismiss Notice
  2. The Unity Pro & Visual Studio Professional Bundle gives you the tools you need to develop faster & collaborate more efficiently. Learn more.
    Dismiss Notice
  3. Improved Prefab workflow (includes Nested Prefabs!), 2D isometric Tilemap and more! Get the 2018.3 Beta now.
    Dismiss Notice
  4. Improve your Unity skills with a certified instructor in a private, interactive classroom. Watch the overview now.
    Dismiss Notice
  5. Want to see the most recent patch releases? Take a peek at the patch release page.
    Dismiss Notice

Dolly path failing in build

Discussion in 'Cinemachine' started by gww2, Sep 13, 2018.

  1. gww2

    gww2

    Joined:
    Jan 13, 2017
    Posts:
    12
    We have a virtual camera moving on a dolly path defined at runtime looking at a target. In editor it works exactly as expected. However, when we build out to windows standalone the dolly movement fails. It still looks at the target, but it sits at 0,0,0. We're running 2.1.10 in 2018.2.7f1, and saw the same behavior in 2018.2.6f1.

    We haven't been able to find any editor specific code that could cause this and using the visual studio debugger is showing the bad position coming from the virtual camera's state, but also that the dolly is created and hooked up.

    Our other cameras using transposer offset in world position execute identically in editor and build. We're at a bit of a loss at what to look at next.
     
  2. gww2

    gww2

    Joined:
    Jan 13, 2017
    Posts:
    12
    We've found the issue. The virtual camera was missing a body component to control the position. It works in editor because of the CinemachineVirtualCamera OnEnable triggers adding this component in editor because on validate is called. In the build onvalidate is not called, and even worse, it fails silently.

    We started to look further into things and see that OnValidate is used for several components to set up/fix things. This seems a bit concerning if you're generating these objects at runtime. Also it seems like a major oversight not to have an error or warning if these components are missing.
     
  3. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    1,731
    OnValidate is used to check ranges of fields and such things, to help guard against user error. It never adds components to a vcam. Likewise, OnEnable does no such things, except is one special case to handle a legacy file format. An empty Body component is a valid configuration (it shows up as Do Nothing in the inspector). There is no way for us to warn against this because there are many cases where it's the desired thing.

    Am I misunderstanding anything here?
     
  4. gww2

    gww2

    Joined:
    Jan 13, 2017
    Posts:
    12
    In 2.1.10, if you set a m_Follow target on a virtual camera without adding a body component it automatically adds one in editor, and does not add one when built. In editor it gets added via the OnEnable call:

    Code (CSharp):
    1.  
    2.             if (ValidatingStreamVersion < 20170927)
    3.             {
    4.                 if (Follow != null && GetCinemachineComponent(CinemachineCore.Stage.Body) == null)
    5.                     AddCinemachineComponent<CinemachineHardLockToTarget>();
    6.                 if (LookAt != null && GetCinemachineComponent(CinemachineCore.Stage.Aim) == null)
    7.                     AddCinemachineComponent<CinemachineHardLookAt>();
    8.             }
    9.  
    ValidatingStreamVersion is set to 20170927 if OnValidate is not called, otherwise its set to 0.

    The end result is setting a target without it having the appropriate stage component results in the virtual camera following the target in editor, but not in the build. Additionally because the component is added silently, and there are no other checks for consistency between setting a target and having a component that can do something with that target, debugging it was rather tricky.
     
  5. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    1,731
    Yes, that code is only there to support older saved scenes that were expecting a certain behaviour before the API changed - sort of an automatic upgrade for those cases. The correct behaviour for newer scenes is to do nothing, to not enter that code. If that code was executing for you then it's a bug in 2.1.10.