iTranslated by AI

The content below is an AI-generated translation. This is an experimental feature, and may contain errors. View original article
🎥

Organizing Live Cameras in Unity Cinemachine: Technical Notes on Timeline and Recorder

に公開

I find that in Unity, it is easier to manage live cameras as Cinemachine Virtual Cameras rather than increasing the number of physical Cameras.

Discussions regarding the direction and composition of live-style cameras are covered in a separate article. This article focuses strictly on Cinemachine, Timeline, switching, dissolves, and their connections to Recorder and FBX export.

Related:

The gateway to all production notes is summarized in the Virtual Live Production Notes Index.

Practical repositories are currently being organized under the VLiveKit series. Code and samples with public links are included in the relevant sections within this article.

Takeaway from this article: Use Cinemachine as a layer to organize camera states

  • Instead of adding physical Cameras, use Virtual Cameras to organize center, stage left, stage right, telephoto, close-up, and wide shots.
  • Consolidating into a single Main Camera makes it easier to think about Visual Compositor, Recorder, and post-export review.
  • Setting up a workflow that can be locked into a Timeline makes it easier to fix good random movements later.

Organize automatic switching with Virtual Cameras rather than physical Cameras

Initially, I wanted to create a mechanism for automatic camera switching.

What I first tried was a script that used a RawImage covering the entire screen to fade and cut between multiple cameras. It simply switched cameras randomly at a set number of beats.

I thought that if I added a script to shake the camera slightly using Perlin noise and set it to LookAt, it would become a simple auto-camera switcher.

At this point, I hadn't consolidated everything into Cinemachine. However, what I wanted to achieve was quite suited for Cinemachine.

As an entry point for considering Cinemachine dissolves and camera switching, I have added this post to my technical shelf.

https://x.com/toki_prpn/status/1645282581250998272

My GitHub also contains validation code for camera switching and shaking, which is being organized as part of the VLiveKit series.

Cinemachine is more effective for organizing camera states than creating camera work

In live scenes, it is less likely to collapse if you organize camera states with Cinemachine rather than dealing with many Camera components.

For engineers, there are situations where touching Camera components directly is easier to understand. However, when considering connections to Visual Compositor and Recorder, and the final output from a single Main Camera, it is easier to handle by switching Virtual Cameras rather than adding physical cameras.

Looking at it as a live camera system, you also need several types of cameras.

  • Center handheld
  • Telephoto from behind the audience
  • Stage left and right handheld
  • Crane-style telephoto
  • Camera for feet or hands

It is easier to organize these by placing them as Virtual Cameras and switching them via Timeline or scripts rather than having each one as a physical Camera.

Consolidating into a single Main Camera makes export and switching verification easier

As I continued working on this, I moved toward wanting to consolidate everything into a single Camera component.

Considering the connection to Visual Compositor and Recorder, it is easier to handle by using a single Main Camera and switching Virtual Cameras on the Cinemachine side, rather than adding multiple physical cameras.

For engineers, there are cases where touching Camera components directly offers better extensibility. However, for a live scene as a whole, increasing the number of physical cameras complicates handling during export and switching.

Therefore, Cinemachine is easy to understand if you view it not just as a "camera work creation tool," but as a "layer for organizing camera states."

If you want to see how to verify the visuals after consolidating into a single Main Camera, the Timeline integration of Visual Compositor is also a good entry point.

https://docs.unity3d.com/ja/Packages/com.unity.visual-compositor@0.16/manual/timeline.html

Fixing to a Timeline allows for correcting random highlights later

When thinking about live-style cameras, Timeline is just as relevant as Cinemachine alone.

What I wanted to achieve was a state where I could simply insert a dissolve-ready Prefab into a scene where Cinemachine camera work was created via Timeline, allowing me to fade-switch between multiple Virtual Cameras.

Also, it is easier to fix auto-camera movements if they are handled deterministically via Timeline rather than being purely random. You can lock in moments where good movement occurred and fix parts with animation. The idea is to create a few of these and use them as switching material.

When Cinemachine, Timeline, and Recorder are connected, it becomes easier to create a live-video-like flow even for short durations.

If you are wondering how to approach Timeline or the Playable API, having an entry point like study session materials makes it easier to circle back.

https://unity-fully-understood.connpass.com/event/315521/?utm_campaign=event_participate_to_follower&utm_source=notifications&utm_medium=twitter

In terms of handling Bindings on the Timeline, investigating TimelineBindingResolver is also worth putting on your shelf.

https://x.com/trit_techne/status/1789254933608374292

https://github.com/tanitta/TimelineBindingResolver

Super-telephoto jitter and dissolves should be verified early

There are still items regarding Cinemachine that I want to refine.

  • Handling of cross-dissolves
  • Dolly Track
  • Aim position prediction
  • Synchronization with BPM or Timecode
  • Jitter when shooting with super-telephoto
  • Integration with Recorder and FBX export

I am particularly concerned about jitter that occurs when targeting a character with a super-telephoto lens. Since I want to shoot with telephoto in character lives, this remains to be verified.

Viewing up to Recorder/FBX Exporter helps as post-export verification material

I have also considered the idea of exporting cameras created in Cinemachine to FBX.

For example, the idea of exporting cameras created in Unity to narrow down the range captured on screen or the subjects of movement check.

I am still in the middle of verifying this, but if Cinemachine, Timeline, Recorder, and FBX Exporter are connected, it can be used as a criterion for judging what to review after export, rather than just finishing after creating the camera.

Regarding the Recorder and FBX Exporter, it is helpful to check the official pages before trying to export, as it makes it easier to foresee how much can be transferred from the Unity side.

https://docs.unity3d.com/ja/Packages/com.unity.formats.fbx@4.1/manual/recorder.html

I keep the Unity Virtual Camera as a separate entry point for thinking about live camera-like inputs and operation feel.

https://apps.apple.com/jp/app/unity-virtual-camera/id1478175507

Conclusion

Cinemachine was useful as a layer for organizing live cameras within Unity, rather than just something for making cameras move in a "nice" way.

Center, stage left, stage right, telephoto, handheld, crane, close-up, wide. Place those camera roles as Virtual Cameras and consider them in combination with Timeline and switching.

It is easier to understand if you view it as an entry point for thinking about how to handle multiple camera states, rather than just learning Cinemachine.

The gateway to all production notes is summarized in the Virtual Live Production Notes Index.


Last updated: 2026-05-04

Discussions about personal production and verification for virtual lives are also held on the personally managed Discord server "VLiveHouse!!!".
Anyone is welcome to join, and beginners are also very welcome.

https://discord.gg/sufusTsAcJ

GitHubで編集を提案

Discussion