Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Feedback Inconsistent API, UI, and UX with the rest of Unity, makes it feel like a third party tool.

Discussion in 'Cinemachine' started by MechaWolf99, Oct 5, 2021.

  1. MechaWolf99

    MechaWolf99

    Joined:
    Aug 22, 2017
    Posts:
    293
    Hello, first I want to say that I really love Cinemachine, it is extremely powerful and I always use it if I am doing anything with cameras!

    However, Cinemachine was originally an asset store tool that was acquired by Unity 5 years ago, and it still feels like it is a asset store tool in 2021.
    It's API, UI, and UX all lack consistency with the rest of the core of Unity. I assume a lot of this is due to not wanting to break old versions, and so people don't have to relearn things. But it actively hurts the quality of package, and the experience of new users.

    API
    Firstly, it still uses the
    Cinemachine
    namespace. If I was a new user this makes no sense at all, every other packages (that was not bought) is under the
    UnityEngine
    namespace.

    Public fields are still exposed in most classes. Not only is this inconsistent with the rest of Unity, it also goes against C# standards. They also all use the
    m_
    naming convention which makes them feel even more 'internal' than just normal public fields. It feels unclear whether they should be used or not, and if so it feels like they could change/break.

    Everything is called
    Cinemachine___
    , it still feels redundant (it is already in the
    Cinemachine
    namespace), messy, and inconsistent with the rest of Unity (no other package does this).
    A lot of them could just remove
    Cinemachine
    and be fine, for example
    CinemachineVirutalCamera
    , can just be
    VirtualCamera
    . It looks cleaner and is more concise. And other ones could be renamed to have more accurate names
    CinemachineCollider
    to something like
    VirtualCameraCollider
    .

    Extensions -- these would be much better suited as standard non-MonoBehavior classes that are in a list on the VirtualCamera. This would allow for the API to be cleaner over all, removing methods and properties that are not useful in extension or should not be used in extensions, and have better naming for methods. Like
    Awake
    and
    OnDestroy
    could be something like
    OnConnect
    and
    OnDisconnect
    just as an example.
    (I haven't done a lot with the extensions so I could be wrong on this making more sense, but I don't think I am though?)

    Again I understand the reason why these things may not have changed, to avoid breaking changes. But again, I feel it actively hurts the package and makes it feel lower quality.

    UI/UX
    Unity has had a new icon style since 2019, and Cinemachine's icons still don't match.

    Not all components have a icon.

    All of Cinemachine's components are in the add component menu with a non spaced name
    Cinemachine/CinemachineVirtualCamera
    instead of
    Cinemachine/Cinemachine Virtual Camera
    . This also has their name in the component title bar not have spaces either.

    This goes with the thing I said earlier about the extensions API. I think that having extensions be displayed within the Virtual Camera component more like how the PostProcessing component display's its effects would be cleaner, and give a more accurate overview of the relationship between it all.
    As it is now having the "Add Extension" dropdown is very inconsistent UX with the rest of unity and doesn't do at all what is expected imo. (Adding a new component instead of adding something to the Virtual Camera)

    The preferences window still has the Cinemachine logo.

    The
    CinemachineBrain
    adds a little icon in the hierarchy to the camera... why? This doesn't feel needed to me and again, inconsistent with the rest of Unity.

    I feel like all of the Cinemachine things and the Camera menu item should be under the same menu item in the "GameObject" menu. It's all camera stuff, so why should it be separated? All 3D and 2D and UI is together, why not cameras?

    VirutalCameras created using the menu item have names that are inconsistent with the rest of Unity. For example "CM vcam1" should be "Virtual Camera" to be consistent.

    Maybe more of an API thing, but some cameras seem to have fields that are not used, for example
    CinemachineBlendListCamera
    never uses the "Follow" or "look At" fields.

    The Cinemachine Virtual Camera
    The "Status" and "Solo" thing feels... un-Unity to me. To be honest I am not exactly sure how I would change it to feel more native. At the very least I would separate it out from the rest to give it a clearer indication that its its own thing.

    The "Game Window Guides" toggle feels more like it should be in the Game Window itself to me. If not, then it should at least be down by the "Aim" section with the values that it actually edits, not at the top. Perhaps make it look more like the "Edit Collider" toggle that is on collider components.

    The guides in general feel old. At the very least it would be nice if the cursor would update to show the drag direction when over one of the lines.
    Now with the new scene Overlay and tools API I think it may be better to just move the guides to the scene view instead. It has always felt inconsistent that you need to go to the game window to edit the values when everywhere else in unity you do that in the scene view.

    The "Follow" field should be down with the "Body" area, and the "Look At" field down with the "Aim" area. This way each is actually with the fields that require them. I would say to actually hide the fields within their respective areas so that you only see the fields when using a type that actually needs them. (If I am not thinking of a use for them otherwise that would make this not makes sense, please let me know).

    Do the "Follow" and "Look At" really need a option to turn them in to target groups? If so maybe a context menu option for the fields would be better. It is the same number of clicks, and I feel keeps the UI cleaner and more consistent.

    The "Body" and "Aim" also feel inconsistent in their styling. To me having the foldout toggle stick out from the rest of the background feels a bit messy, I think switching to using the
    FoldoutHeader
    style would be more consistent and feel more responsive (The style the new reorderable lists use for their header).


    I could go on (And will if you want me to), but I feel like this covers the most common and major things. It just really feels like it needs a 'consistency' pass to make it feel like it is actually part of Unity, and not just a third party tool.

    I like both Cinemachine and Unity, and want to see it get better (thus I spent 2+ hours writing this). I would be happy to make PRs for some of the non-breaking changes, but idk if you accept community PRs. (I could also do the breaking changes too, I just assume you would want to do those your self)

    I do want to reiterate that I understand the reason not to do breaking changes, but when it hurts your product to not make those changes... you just need to at some point right?

    Well thank you for taking the time to read, I hope this was at least somewhat helpful.
     
    Last edited: Oct 5, 2021
  2. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    7,658
    Hey @MechaWolf99 thanks for the awesome feedback! We really appreciate these kinds of posts. I find myself agreeing with 92.8% of what you write. As you point out, we are stuck with the historical API decisions because changing them would break too many of our customers' projects. It simply isn't worth it. On the other hand, inspector and UX changes are always possible, and your suggestions are excellent. As it happens, we are currently doing a UX pass to improve some things, but this is a gradual process.

    Also, we are working on an all-new DOTS-based version of Cinemachine, and that would be a perfect opportunity to revisit naming and API because back-compatibility would not be an expectation. And we get to rename everything if we want to. On that topic, if you had to think of a new name for the Cinemachine Virtual Camera, what would it be?
     
  3. MechaWolf99

    MechaWolf99

    Joined:
    Aug 22, 2017
    Posts:
    293
    That's good to hear and you're welcome, I really appreciate how active and responsive you are on the forums!

    Yeah, I figured that would be the case for the API, is there a chance of getting like a Cinemachine 3.0 that has a better API, and then simply treat Cinemachine 2.0 as an LTS (bugfixes, but no new features)? People not wanting a break their project simply stay on the 2.0 version, while new users can use the 3.0 version. I assume not, but I figure I may as well ask, haha.

    That's great to hear about the UI and inspector stuff, unfortunate that only so much can be done because of the API :/
    In regard to the UX and inspector, do you accept community PRs (I can't tell from looking at the github)?

    Ooh, the new DOTS-based thing sounds nice, I imagine it must be nice working on it too, getting to make a cleaner API.
    I think "VirtualCamera" is fine, but maybe something that makes it a bit clearer what it actually is would be better, since in my mind, a camera already is a virtual camera since it is not a physical camera. Maybe something like "Camera Proxy" or "Shot Controller", though neither of these are that great, I'm having a hard time thinking of a good name for it at the moment. But I do feel there is something better than VirtualCamera.
    (On the topic, if you still have the CinemachineBrain, please rename it to use Controller instead of Brain)
     
  4. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    2,497
    Old but relevant thread that it's still on top of the search results. I've been forced to work with Cinemachine in a project and I agree 100% with @MechaWolf99. The experience using this tool is totally like using some non-Unity third party package.

    Exactly. Why? No other Unity component does this. This icon cannot be hidden. It's just distracting and unnecessary. Makes the tool feel like some lame third-party package calling for attention.

    Not to mention adding a top-level menu entry... If I recall correctly, this has been discouraged since 2015 at least.

    Honestly, Cinemachine needs some serious rework to integrate itself in Unity. A non-backwards compatible version (or even a new package, Cinemachine2) that integrates properly into Unity is required.

    Now there are official guidelines on how to design user experiences that integrate into the Unity UI:

    https://www.foundations.unity.com

    This is an excellent opportunity to rewrite Cinemachine to be what it should have been from the beginning: an Unity tool.
     
    MechaWolf99 likes this.
  5. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    7,658
    MechaWolf99 and Edy like this.
  6. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    2,497