Bot releases are hidden (Show)
Limit Target
would result in unneeded errors and not properly reset the sides to their default values.Published by ramokz 6 months ago
Follow Group
in phantom_camera_3d.gd
with phantom_camera_2d.gd
Draw Limit
didn't update when changing the Shape2D
in 2D scenes.Published by ramokz 6 months ago
[!note]
The breaking changes in this release are a one-time thing.
It's a combined number of system changes that needed to happen at some point, and so it was decided to do it in one go rather than over the course of multiple releases.
[!important]
Always be sure to have your current changes commited to source control before updating to avoid losing work.
This release, specifically the property change, further down the page, relies on changes that were only released in Godot 4.2. As such, it will now only be compatible with that and future versions of Godot.
A lot of the addon's filenames have been changed to align with a general snake_case naming convention, but as a result will likely run into an error on start-up that looks like this:
If you're well-versed with Godot, then this should be a relatively simple thing to resolve, but if you're unsure how to solve this, follow the steps below.
This is mainly an under-the-hood change and will only impact existing users of the addon.
_property_list
to @export
.The shift to @export
was always planned, but for a later release β initial thinking was for v1.0. The reason it is being introduced now is due to a project export bug (#164), where an important feature didn't consistently work when exporting a project β despite working consistently in the editor. Suffice to say, that's a pretty big problem. From some initial tests, this issue did not occur when using the aforementioned @export
approach. So the decision was made to make the jump sooner than originally planned. So far, the issue has yet to reappear.
The change was also meant to coincide with a better editor experience, as @export
allows for supporting inspector property tooltips (#55) as well as an in-editor documentation page for all the addon's public node properties, functions, and signals (#168).
From a development perspective, the change also greatly simplifies the process of adding, removing and debugging properties, which in turn reduces the code complexity and time spent testing new and old features.
The addon has been in the worked since before Godot 4 was fully released. Not until Godot 4.2 was it possible to dynamically show or hide properties using @export
. If the addon had used @export
from the start, it would have resulted in all the available properties for a given addon node always being displayed. The vast majority of which being both irrelevant and confusing without contextual toggles or modes enabled β awful developer experience, in other words.
One of the changes made here is that property names do not have any nested names, e.g. follow_parameters/target_offset
, are now named as a single variable name, e.g. follow_offset
.
Assuming you're using some form of source control, such as Git, the good news is that you can convert the property names manually from the individual scene files (.tscn
) directly and keep your existing property values. Below is an example of how I would migrate an existing setup from a pre-0.7 project to be using the new property names from this release. Note that the follow_damping_value
property is the exception to this - more in the Important section below.
Once you've updated the addon and opened an existing scene that has PCam2D
and PCam3D
nodes, their values will have reset - you may have to re-save the scene first. From here, if you want to keep your existing setup, you can look at your source control and compare what values have been changed. In the example below, I've readded a follow_target
and damping
with random values.
As the image above shows, the names are not changed to be unrecognisable from the previous version. They are different, however, which does mean manual intervention if you wish to migrate the values over. Simply use your text editor of choice and add the values into the .tscn
file directly.
[!Tip]
If you're unsure what a property name is called now I would suggest looking it up on the documentation site. It will have all the up-to-date names.
[!important]
As you may have noticed from the image above, some values have had their type changed in this release too. The only properties this relates to isfollow_famping_value
. You need to adjust its value according to the new system β see the Improved Follow Damping Logic section further down the page for more info. As the effect of the value have, for all intents and purposes, completed shifted I would recommend doing a test in one scene, feel it out, and reapply values elsewhere based on that observation.
_process
This might seem insignificant, but it does have a notable impact.
It will likely affect everyone, existing as well as new addon users, so would suggest following the steps in the βWhat can I do about it?β section further down for how to work with this change.
_process
or uses a Tween
animation should no longer be jittery.A big thanks to @P5ina (for the PR) and @Lasuch69 for the discussing and helping with this change.
In previous releases, camera movement has been happening in the _physics_process
. This was initially in large part been due to playable characters, what the camera would also typically be assigned to follow, would be a physics-based node such as CharacterBody2D/3D
. This meant that as the physics object moved, along with the character asset within the physics object (i.e. sprite / 3D model), the camera followed it relatively evenly as the movement should both be happening in the _physics_process
.
While having the camera move in the _physics_process
meant that following a physic-based node was generally fairly smooth, it did also come with a few, no-trivial, issues.
The arguably biggest issue, was that animations that were being done in the _process
, such as anything using the built-in Tween
method, would always result in jitter. Either when it was being followed by the camera or were moving while the camera followed something else. Since not everything is, nor should, be moving in _physics_process
it highlighted an issue with the previous approach. As things stood, it was deemed not possible to solve while the camera moved in the _physics_process
and so it was changed to be occurring in the _process
instead.
If you're using a physics object as a follow or look at target, and it's set to move in the _physics_process
then you will likely notice jitter right away β even if you apply follow damping
.
A typical playable character would then often consistent of a node hierarchy like:
CharacterBody2D/3D
Sprite2D
or a MeshInstance3D
CollisionShape2D/3D
Assuming a developer had assigned a CharacterBody2D/3D
to update in the _physics_process
it would previously be running in the same process as the camera. Moving the camera to then run in the _process
instead meant that they wouldn't be synchronized and run at different intervals.
The short explanation is that the _physics_process
runs at a fixed interval, whereas the _process
runs at a dynamic interval based on your framerate. They can sometimes run at a very similar pace, but for all intents and purposes they will not. Godot's documentation has written more on this topic.
In the case of this addon, the core issue here with jitter isn't really that the camera and its target are running in different processes, but rather that the visual representation is.
As its parent, in this example CharacerBody2D/3D
, moves in the _physics_process
so too does the visual representation that is nested within it. What is needed here is to control when the visual representation moves, rather than being entirely dependent on its parent moving.
There are a couple of things you can do to mitigate jitter, which is covered more extensively on the support page on the documentation site.
https://github.com/ramokz/phantom-camera/assets/5159399/72cc6147-4f31-4edd-a8ce-4d2322983d4d
PCam3D
now supports rotational damping when it has an assigned target in Look At
mode. The damping value aligns with the new Follow Damping system, where lower values leads to less damping and vice versa.
Previously excluded to 3D scenes, the viewfinder now also supports displaying what a Camera2D
sees in 2D scenes.
Another benefit of the property revamp, and similar to classes in Godot, the addon now has an editor documentation page that describes the available properties, functions, and signals based on the built-in documentation commenting feature. While the documentation website covers that and many other things in greater detail, the inclusion here should help with reading and exploring the available options from within the Godot script editor itself.
https://github.com/ramokz/phantom-camera/assets/5159399/60d27504-893e-4ca3-a280-a05a3e173cc0
The previous system used a simple linear interpolation (lerp) to move the camera for both 2D and 3D scenes. While it worked fine, it didn't feel like the right approach for the follow movement.
The new system is based on Unity's Smooth Damp, where it now uses a more complex logic that allows for velocity to also affect the camera's follow movement.
The practical difference between the lerp and smooth damp solution can be broken down into:
Lerp | Smooth Damp |
---|---|
Accelerates quickly and slows down as it approaches its target. | Starts slow and accelerates as velocity increases over time before slowing down as it approaches its target. |
Smooth damp, in essence, feels more like what an actual camera would move like in real life.
Another addition is that the directional axis can be manually configured with different damping values. E.g. if you want vertical damping to be less than the horizontal, you can supply different values for each. The video above shows an example of this, where the x-axis damping is higher than the z-axis'.
[!tip]
Value-wise, and unlike the previous approach, lower numbers now means less damping. The ideal amount should be somewhere between 0-1, likely somewhere around 0.1 to 0.25.
Thanks to @voithos for suggesting the code solution and others for chiming in (#92)
In previous releases, grabbing and setting new property values, like priority
, follow target
, had to be done with their appropriate getters and setters respectively. Thanks to the property refactor, all properties can now be directly assigned. Setter and getter methods are still valid, of course.
quaternion
value of the SpringArm3D
in Third Person Follow
mode. Previously limited to only rotation in radians and degrees (#190)
Inactive Update Mode
can now be changed via code, whereas it was previously limited to only be set from the inspector.editor_interface
to use the singleton class, EditorInterface
, introduced in Godot 4.2.Pixel Perfect
property to Snap to Pixel
, as the previous name incorrectly implied it fully addresses pixel perfection β which is a much tricker problem to solve in reality.PhantomCameraTween
enum names to align with the built-in Godot Tween
enum names.dead_zone_changed
signal.phantom_camera_properties.gd
as all properties now live directly in their respective files.look_at_target_changed
signal.Camera3DResource
."Failed to load script "res://addons/phantom_camera/scripts/panel/viewfinder/viewfinder.gd" with error "Parse error".
(#181, #164)Third Person
Follow Mode properties related to the SpringArm3D
via code would cause a crash if done so on a PCam3D
that wasn't set to Third Person
(#257)
Published by ramokz 7 months ago
As the addon gets more refined over time, leading to potential breaking changes, the updater now requires an extra step to be completed before it can be triggered for major or minor releases. The only practical difference is an added dropdown menu, where you have to select Yes
instead of the default No
option, which will then make the update button appear. This is to give a bit of friction and to give some thought before pressing the big green Update button and risk causing project side effects.
This will, however, not occur for patch or hotfix releases.
Term Reference Examples:
Major Release:
v0.8
->v1.0
Minor Release:v0.6
->v0.7
Patch Release:v0.6.4
->v0.6.5
Hot Fix Release:v0.6.4
->v0.6.4.1
[!TIP]
You may have to enableAdvanced Settings
in the top right-hand corner for the settings to appear in the panel. Alternatively, you can search for them.
Options to now disable the updater to two different levels (more below) have been added to the Project Settings
.
This is meant to better support released projects where no further work is happening, but where the project is occasionally being opened.
π‘ Thanks to @lunarcloud for the suggestion (#203)
[!IMPORTANT]
If you are using the addon by having forked the project, then the updater window will now always be disabled.
This is to prevent an update from overriding your own changes.
Pulling and merging themain
branch should be done instead.
IfEnable Updater
is disabled or using a forked version of the project, this will appear by default in theOutput
tab within the Godot editor on startup.
Like with theEditor Updater
, this too can be disabled from theProject Settings
.
Framed Follow
PCams would stack the dead zone fields in the viewport. (#226)
SpringArm3D
properties such as collision_mask
didn't get triggered during runtime. (#224)
Published by ramokz 9 months ago
follow_target_changed
signal that's emitted whenever a PCam
's follow target is changed.
Look At Offset
option for Look At Group
.
Published by ramokz 9 months ago
queue_free()
a PCam node due to an invalid reference to the PCamHost
node. (#175)
Camera3D
resource properties via a PCam3D's
setter methods wouldn't update the Camera3D
if a PCam
was the active one. (#184)
PCam3D
) didn't assign its target properly. (#182)
Published by ramokz 9 months ago
Third Person Follow
PCam3D
with both damping
enabled, with a small damping value
, and a follow target
far away from a global position of (0, 0, 0) the camera would very slowly move towards its intended position from (0, 0, 0). Leading to a potentially long wait before you could realistically make use of the camera's intended behaviour. (#167)
Published by ramokz 10 months ago
Limit
applies. The previous version had an issue where there would be a quirky jump as you transition between neighbouring Limit
areas. As a result from this change, the 2D damping logic has been reverted to pre-0.6, which means the damping applies an interpolation to the movement, rather than relying on the Camera2D's
Position Smoothing. Like the previous change, this shouldn't have any notable impact.
is_tweening
signal β emitted whenever a PCam
is tweening.Follow Properties
in the node inspector, such as Follow Offset
and Damping
, even without a Follow Target
whenever the Follow Mode
is not set to None
. This is to allow for dynamically applying a Follow Target
during runtime while allowing to set Follow Properties
if they're known during compilation and not being forced to do so via code.void
return types to various functions.Follow Target
. Allows for resetting the property using the reset button to the left of the property button.Follow Target
and Follow Path Target
. It means that the pop-up menu selector only allows for selecting Node2D
/Node3D
and Path2D
/Path3D
nodes, respectively.Camera2D
Limit
size wouldn't reset properly while tweening between PCam2D
's if both were using a CollisionShape2D
as their limiter. Resulting in the camera snapping in one direction.Frame Preview
not updating in 2D scenes when changing the Zoom
property. This was due to a bug where the variable name zoom
in PhantomCamera2D.gd
didn't trigger the setter, and consequently the _draw
function call, resulting in the preview not updating. The fix here was to rename the variable to camera_zoom
instead.TileMap
or CollisionShape2D
(Shape2D
) would result in a PCam2D
not being able to fetch the node, resulting in updates to the Limit Node
not updating the PCam2D
limit. The solution was to wait until the PCam2D
had called its _ready()
function before validating the Limit Path
property when the scene is loaded.scale_with_editor_scale
was enabled on some .svg icons, which scaled them to look correct on high resolution monitors. This issue should be resolved in Godot 4.3, but until then this property will be disabled to avoid user frustration.Published by ramokz 10 months ago
To support pixel perfect camera movement, a new toggle option to snap Camera2D
to whole pixels has been added.
This should be particularly useful in pixel art projects, where assets should always be aligned to the monitor's pixels to avoid unintended stretching.
In addition to allowing TileMaps
to apply the Camera2D Limit
, a CollisionShape2D
can also be used to apply the Limit
values using its Shape2D
property. It will automatically update the limit when the Shape2D
is changed.
Support for PCam
signals have been added. This is meant to allow for receiving callbacks when specific events begins or ends for each PCam
. This has been added for both PCam2D
and Pcam3D
nodes.
List of added signals:
became_active
- Emitted when the PCam
becomes active.became_inactive
- Emitted when the PCam
becomes inactive.tween_started
- Emitted when the Camera
starts to tween to the PCam
.tween_interrupted(PhantomCamera pcam)
- Emitted when the tween is interrupted due to another PCam
becoming active.tween_completed
- Emitted when the Camera
has completed its tween to the PCam
.TileMap Limit
, has been renamed with a generic Node Limit
property - the same goes for setter/getter methods. As a result, existing property values will likely reset upon loading scenes that have any overrides, and setter/getter calls will produce errors if used in scripts until renamed to the new ones. This change is to allow other node types to be assigned to the property, such as the newly added CollisionShape2D
, but also to make the names less specific and more in line with other property names.
.tscn
files in a text editor.Follow Mode
, to avoid accidentally resetting critical property values.TileMap Limit
nodes will now update the Limit
size after the TileSet
is changed. Note: This will only be triggered after leaving the TileMap
editor panel.TileMap Limit Margin
to type Vector4i
instead of Vector4
. Changed due to Camera2D
Limit
property only supports integer values.Zoom
property from phantom_camera_properties.gd
to phantom_camera_2D.gd
. Changed due to the Zoom
property is only used in 2D scenes and PCam2D
.const
, vars
, func
etc., into their own, collapsable, regions.Framed Follow
in 3D scenes would not apply its distance and offset upon loading a scene. Resulting in the camera zooming into its target and effectively breaking on load.
PCam2Ds
while the initial PCam2D
's Follow Damping
were enabled led to undesired transition easings and sudden camera jumps at the end of the tween.Limit Left
.Published by ramokz 10 months ago
Whenever a new update of Phantom Camera is released on GitHub, the editor will show a prompt to update to the latest version directly from the editor.
Code and layout for this feature was replicated from the Dialogue Manager addon by @nathanhoad.
Utilizing the built-in Limit
properties of Camera2D
nodes, you can now limit the position of the camera to a specified area. Optionally, it also supports the built-in smoothing property. So whenever the edge of the limit is reached it will gradually ease to its limit, as opposed to immediately stop once it reaches the edge.
On top of the existing built-in feature set, TileMap
node can also optionally be used as a way to limit the Camera2D
movement. An optional margin can also be set to further adjust the limit's size.
The editor preview area of the clamped area can be toggled within the editor.
Example Scene
addons/phantom_camera/examples/example_scenes/2D/2DLimitExampleScene.tscn
Camera2D
Limit
property #139PCam2D
nodes will now by default show what it will frame (green rectangle) when instantiated, similar to the purple rectangle a Camera2D
shows. This is to help determine the composition of the individual PCam2D
without switching the priority around.
This can optionally be disabled per instance to reduce screen clutter.
PCam2D
now uses the Position Smoothing
property of the Camera2D
instead of its own interpolation method. The damping should be very similar, but there might be a minor damping speed difference compared to releases prior to this.Camera2D
property behaves.PCam2D
Priority Override
property wasn't being set.Framed Follow
mode would behave strangely if it wasn't the first PCam
to have the highest priority when a scene starts.
Camera
would jump to and tween from unexpected positions if the Camera
's parent nodes had any positional offsets.
Third Person Follow
's SpringArm3D node wasn't updating its length during runtime when using the setter method.
Published by ramokz 12 months ago
Camera2D
, with a PCamHost
as a child, is positioned below a PCam2D
in a scene's hierarchy, it would result in a crash on startup.
Published by ramokz about 1 year ago
Follow Group
or Look at Group
entirely via code would never trigger their respective logic.
Look At Group
node from the array would cause continuous error output.Follow
and Path
target nodes via setter method..gitattributes
so that anything but the addons/
directory content won't get downloaded.Camera
node and then a PhantomCameraHost
node will trigger a series of errors until a PhantomCamera
node was added as well.get_position()
calls to get_global_position()
get_rotation()
calls to get_global_rotation()
Thanks @m4rr5 for spotting these!
Published by ramokz about 1 year ago
https://github.com/ramokz/phantom-camera/assets/5159399/419c403d-257a-4d15-8c16-04972fc36a43
As the name implies, this mode is meant to be used for third person camera experiences.
It works by applying a SpringArm3D
, where the properties, such as Collison Mask
, Spring Length
and Margin
, can be controlled from the PhantomCamera3D
.
More documentation, with an example code setup for orbit controls, can be found on the Third Person wiki page.
A working scene example can be found in 3DFollowThirdPersonExampleScene.tscn
inside addon/examples
directory.
Enabling this temporarily changes the currently active PhantomCamera
without modifying the Priority
value.
The intent is to avoid having to manually adjust a PhantomCamera
's Priority
value to preview it by, e.g., by setting the value to 99, which can lead to unintended behaviour if not reverted back again.
The Viewfinder will display a UI prompt whenever a PhantomCamera
has this enabled. Pressing the UI prompt will select that PhantomCamera from the scene tree.
Note: The override is only functional when working in the editor and will be ignored when running the game.
Camera3D
properties can now be adjusted per PhantomCamera3d
nodes using the new Camera3D
resource. With the exception of the Cull Mask, these properties will also be tweened upon changing the active PhantomCamera3D.
The adjustable properties are:
As part of this addition, some of the scene's Camera3D
properties will be overridden by an active PhantomCamera3D
node IF it has a Camera3D
resource assigned to it β by default, they will not have that.
I.e. If there's existing code in the project that changes the Camera3D
's properties, or if there is a pre-defined property setup on a Camera3D
node, then be aware that this can either cause conflicting property changes or unintentionally override an existing setup.
StringName
.PhantomCamera3D
s now uses the shortest rotation distance. Fixes an issue where the tweening would do an unexpected 180-degree spin.
Published by ramokz about 1 year ago
Enables dynamic framing of a given target using dead zones. Dead zones enable the camera to remain still until the target moves far enough away from the camera's view. This is determined by the horizontal and vertical dead zone size in their respective properties within the inspector.
https://github.com/ramokz/phantom-camera/assets/5159399/6c9d1653-b4c6-4b5d-8855-402776645689
Preview what the Camera2D
/ Camera3D
sees when attached to a PhantomCamera. Accessible from the bottom panel labelled Phantom Camera
. The viewfinder rendering of the scene will only work when the combination of a Camera
, PhantomCameraHost
and PhantomCamera
are present in the scene.
When Follow Mode is set to Framed, dead zones will also be visible in the viewfinder and, if enabled, when playing the game from the editor.
Note: Dead Zones will never be visible in build exports.
When creating a new scene, the Viewfinder will not work by default due to the missing required nodes.
To improve the user experience, and to provide better guidance for why it isn't working, the Viewfinder provides a quick and simple button flow to adding any missing required nodes.
Most of the setup is there, however, getting the 2D view to render in the viewfinder doesn't quite work yet.
Issue can be found here: https://github.com/ramokz/phantom-camera/issues/105
Added a series of functions that allows for setting and getting properties, enabling easier code configuration of PhantomCamera nodes.
With this you can now assign, or remove, targets to a Follow Group, change the target offset, get its current priority and more.
See the PhantomCamera2D and PhantomCamera3D property pages for the full list of setter and getter functions.
Published by ramokz over 1 year ago
When PhantomCameras are instantiated, there's now a property to prevent it from automatically triggering a transition.
This is to cover use cases such as avoid having the Camera drag behind a playable character, for however long the Duration
property is set to, whenever a scene is loaded. Instead, it can now (optionally) do its follow / look at logic from the moment it enters the scene and is set with the highest priority.
https://user-images.githubusercontent.com/5159399/235308051-2bb876d6-777d-4acc-bea6-d9fbbbc702d8.mp4
Published by ramokz over 1 year ago
The property naming convention has been updated to match Godot's snake_case standard.
As a result, property values of (most) existing PhantomCamera
nodes' will be reset upon opening the scene they exist in.
To avoid having to redo all the parameters in the editor:
.tscn
) that have PhantomCamera
nodes, like shown belowZoom
support in AnimationPlayerCan now animate the zoom
property of a PhantomCamera2D
using AnimationPlayer
nodes.
Note: The output log will spam errors when doing this, but the effect should be working as intended regardless. Still under investigation!
Published by ramokz over 1 year ago
Support for following a target while being positionally confined to the closest point on Path2D
/ Path3D
.
Tween properties (Duration, Transition and Ease) are now resources. So their values can be saved as a file and be linked across multiple PhantomCamera
nodes and updated from a single place.
Individually set how frequently PhantomCamera
nodes should update when inactive.
Short guide for how to tween between PhantomCameras
using an AnimationPlayer (timeline) node: https://github.com/ramokz/phantom-camera/wiki/Using-AnimationPlayer