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.
