Refactor PhantomCamera and its host

[hayahane]

Project Type

Editor

Feature Description

It's nice to see a feature-packed camera plugin in Godot. Since this plugin is inspired by Cinemachine, it mostly just take over it architecture. However, Godot is not like Unity. Unity needs virtual cameras because a rendering process begins within a camera in Unity, which means more camera, more rendering. It is not the same case in Godot. Godot starts a rendering in a Viewport. Godot Cameras are already like Cinemachine Virtual Cameras, so there is no need for making another vcam. Current architecture takes much more step to use and possibly more chance to make mistakes.

Use Cases

It's a system refactoring.

(Optional) Proposed Solution

Phantom Cameras should be extended from Camera3D/Camera2D.

[ramokz]

Am not sure what problem this is meant to solve?

What PCams do is that they pass data to a scene's Camera2D/3D that has a PCamHost, which is also how Cinemachine behaves. That is, the render camera remains the same at all times, but the transform and various parameter logic changes with the virtual camera or as it gets passed on to one another. Godot doesn't need more Camera2Ds/3Ds to achieve that effect.

[hayahane]

Sorry if something I wrote confuse you. I'm not very familiar with english.

Current system runs well, but PCam is like making a virtual camera for a virtual camera( Godot's builtin camera is already virtual)

What I'm suggesting for to make PCam extends Camera directly, so that we won't need to set an additional host. Not something urgent, but it doesn't make sense to do exactly Cinemachine does since the Camera is "virtual" originally.

Appreciate your work. It is your work that let me feel the energy of godot community and make up my mind to use godot. If you are busy with something else I would like to find some time to make a pr.

[ramokz]

PCams are used to merely tell what a given Camera2D/3D should do, they're not really doing much beyond that — it's just a Node2D / Node3D with property and positional logic applied on top of it at the end of the day. The purpose of the PCamHost tells the PCams which Camera2D/3D they should affect.

If you removed the idea of PCamHost and used multiple custom Camera2D/3D nodes, you then run into odd challenges like “how should the Camera interpolate between different positions as priorities change?”. Since you would then either need to tween a previously active Camera to the newly active one, which will mess up the previous Camera's position. Or, alternatively, teleport a Camera to the spot where the previously active camera is, and then interpolate to where that Camera should be.

Both seem a lot more complicated and brittle than just telling a single Camera2D/3D in a scene to go to X position and apply X property changes when a node emits a signal with those data attributes.

The “virtual”, or here “phantom”, part is more of an abstract definition to imply that they're not actually cameras, but rather data points designed to override a camera's properties and less to do with how Unity and Godot's built-in cameras differ.

[hayahane]

I didn't think over blending and tweening thing. I was inspired by the builtin Camera2D's smoothing function and then checked the source code.

There should be a way to override these camera data in the viewport. We could save these data instead of a camera in the singleton, interpolate, and override it to the RenderingServer (using rid instead of a node), which hides the host and camera setup from users.

Since at present, the I don't know whether using server api is better to maintain, maybe this issue should closed and focus on more important issues?

[ramokz]

I didn't think over blending and tweening thing. I was inspired by the builtin Camera2D's smoothing function and then checked the source code.

If you mean the Camera2D's Position Smoothing and Rotation Smoothing, then, yes, those do fulfil similar purposes as parts of the addon — specifically the damping system. However, those properties do not exist for Camera3D, and are only a small subset of what the addon aims to do.

There should be a way to override these camera data in the viewport. We could save these data instead of a camera in the singleton, interpolate, and override it to the RenderingServer (using rid instead of a node), which hides the host and camera setup from users.

That's basically what the PCam do, no? The purpose of having nodes in scene is that they're more easily accessible in terms of setting up a composition, placement and various properties of each PCam instance where a camera can be applied to. The data is important, but so too is the development time of placing the nodes in the scene and adjusting them as needed.

Since at present, the I don't know whether using server api is better to maintain, maybe this issue should closed and focus on more important issues?

Am always happy to hear ideas and suggestions; however, the only actionable ones are those are highlight either specific or structural issues that prevent someone from achieving something specific. At the minute, I'm still not entirely sure what the proposed alternative would simplify nor resolve.

[hayahane]

At first I thought making PCams extends Camera3D can benefit this with camera previews and also save tie for drawing gizmos. Besides, users won't bother setting up hosts. Some builtin features like camera attribute switching can be done with turning on a new Camera3D automatically. However, I'm not quite sure about this now, since using server apis can result in losing editor features.

[ramokz]

At first I thought making PCams extends Camera3D can benefit this with camera previews

There is a editor panel at the bottom of the editor labelled 'Phantom Camera', which previews the camera when a PCamHost and PCam are both in the scene and setup correctly. You can easily swap between and preview different PCams within the editor by toggling the priority override in the individual instance, which will updated the viewfinder.

[...] also save tie for drawing gizmos

There should already be gizmos in the editor for each PCam?

Besides, users won't bother setting up hosts.

Am not sure why you're assuming that? It's literally just adding one node per scene / Camera. The viewfinder editor panel even helps with setting that up from a single button press if it's missing in a scene.

Some builtin features like camera attribute switching can be done with turning on a new Camera3D automatically.

Sure, but you wouldn't be able to transition between them. It will always be a jump cut as you toggle the different cameras' Current property.

[hayahane]

Sorry for the late reply. (It's weird I didn't receive an e-mail)

There should already be gizmos in the editor for each PCam?

Worried about this future features may conflict.

The viewfinder editor panel even helps with setting that up from a single button press if it's missing in a scene.

It's my mistake, I should down a further study on your work. It looks quite nice! At the moment of writing this Issue, I was worried about Godot 4 plugins may have to change much in the future, so I'd like plugins to use built-in things (I looked at CyclopsLevelBuilder, and there would be much work to rebuild these plugins).

Sure, but you wouldn't be able to transition between them. It will always be a jump cut as you toggle the different cameras' Current property.

This is what triggered me to propose this. Since Godot is going to add more and more things to Camera, it might be difficult to maintain. On the other hand, being highly integrated to a actively-changing engine may also cause problem. Many plugins do there own way which is obsolete when the engine updates, and that confuses people what's current best way. Maybe I was driven crazy by the idea of integrating all functions into the engine to make it not that chaotic as Unity is.

Anyway, best camera control plugin in Godot 4 so far. Thanks for your work and active reply. It is wise to keep plugins separated from the engine modules at present.