PhantomCam3D behaves differently than Camera3D when unconfigured

[Scuas]

Hi, I'm getting unexpected jitter out of PhantomCameras3D compared to Camera3D and I'm unsure why.

In this setup both cameras are children of a BoneAttachment3D node of a moving skeleton.
They are both added without any alterations, I'm assuming a PhantomCamera3D should behave the same as Camera3D if it has the follow/look at modes set to None.

In this test the Camera3D works correctly without jitter as the skeleton moves, but the PhantomCamera3D jitters as if it's trying to apply some sort of interpolation or updating out of sync. My goal is to have a phantom cam which does not move at all and acts exactly like Camera3D (I.E: let's itself be moved via the parent transform updating only), but supports the tweening/camera-transitioning system from Phantom Camera.

I initially tried to use the Glued follow mode, but this introduced a smooth interpolation I was unable to configure/remove.

Is there a way for me to eliminate the jitter, or hook a standard Camera3D into the transition/layer system?

[ramokz]

There shouldn't be any interpolation happening if you've set the Follow Mode and Look At Mode to None.
It does process the logic still, but it only copies the Transform3D values and applies it to the Camera3D.

hook a standard Camera3D into the transition/layer system?

Unfortunately not; would essentially have to merge the PCam and Camera node logic into one single node, as there's a lot more than just Transform values that are being referenced from a given PCam node.

What Godot version are you on, and would you be able to share a small reproducible project? I haven't worked with the Bone nodes before, so want to make sure I'm seeing the same thing. There have been some improvements / systemic changes to how physics interpolation works in Godot 4.5, so it might be that the addon needs some changes to properly support that. Based on what I read, that shouldn't be the case, but I've got another theory for what might be happening if that's the case.

[Scuas]

4.6-beta2, and I can't share this project nor do I have any time to make a reproducible anytime soon but I can do what I can to try and narrow it down.

It sounds like if it copies the transform3D values and applies it to the camera, there could be a order of operations issue somewhere? BoneAttachment3D copies the transform of a selected bone during the skeleton's modification process, which in my project defaults to the idle process. I'm wondering if it's setting an outdated value somehow.

The simplest setup should be to create a skeleton with three bones, add a SpringBoneSimulator that runs all of them and add boneattachment3D (tracking the lead bone) with a child camera. If this structure moves (say, animated position) it should do the jitter as phantom but not on standard.

[ramokz]

I realize that I am too unfamiliar with working with bones in Godot having tried for about an hour, so found a small project that had an animated model with a bone structure that I used as an example instead.

Is the jitter you're seeing appearing similar to this?

pcam-under-bone.mp4

For reference, here's the tree structure:

The PCam is just a child of the BoneAttachment3D, which is what drives the transform changes to the camera.

Bone attachment setup:

And PCam properties:

[Scuas]

In my example the bone attachment is a direct child of Skeleton3D with use external skeleton turned off, but it yes that does look like the same result I am experiencing with the same phantom cam settings.

You should notice that if a normal camera is used in place of the phantom cam under BoneAttachment3D, the jitter resolves in your setup?

[ramokz]

You should notice that if a normal camera is used in place of the phantom cam under BoneAttachment3D, the jitter resolves in your setup?

It does, yes.

To fix that in my instance, the solution was to just set the Interpolation Mode on the PCamHost to Idle, so that it forcefully only updates the transform values during the process ticks.

[ramokz]

Just checking, was the above helpful, or are you still encountering the issue?