Objects attached to the camera blur despite not moving

[ErrorFoundHere]

There's an issue with anything that is supposed to stick to the camera at all times receiving the motion blur effect whenever you stop moving the camera (it suddenly blurs whatever mesh is attached to the camera for split second and then unblurs it. When constantly moving the camera or when just starting to move the motion blur effect does not happen (as expected) but whenever the camera stops the motion blur is applied to what should be considered an unmoving object in screen-space. It happens also when you rotate the camera and suddenly stop rotating it (but doesn't happen upon starting to rotate or during rotation).

https://github.com/user-attachments/assets/4e91a607-5a9c-4157-bed8-da552bb66e7a

[sphynx-owner]

Alright, a few questions:

• which motion blur implementation are you using?
• I notice a lot of general stutters in either the recording or gameplay, if that is solved does it still happen?
• Is any position, either the object's or the camera's, controlled from a script? if so, which process do you use for positioning?

[ErrorFoundHere]

Alright, a few questions:

• which motion blur implementation are you using?
• I notice a lot of general stutters in either the recording or gameplay, if that is solved does it still happen?
• Is any position, either the object's or the camera's, controlled from a script? if so, which process do you use for positioning?

• I'm using SphynxSimpleJumpFloodMotionBlur but I tried switching to other ones and the problem was still the same
• Yes, regardless of performance stability or framerate it happens all the same
• Yes, the camera's position is controlled from a script, but I tried both regular process() and physics_process() and it makes no difference, the issue is exactly the same in both cases

[sphynx-owner]

Hey, I was able to recreate it and after investigation it seems to be a bug in the engine itself and the way it generates the velocity buffer. The weirdest part is that you would not see that with any camera velocity change, just when it reaches a stop, so once there's an issue created for that I would close this one and redirect to it as it would probably no longer be up to me to fix.

[ErrorFoundHere]

Alright! Should I open an issue in official Godot's github or is there already one open about this? Or maybe you should let them know? You probably know what's wrong and can explain to them a lot better than I can haha

[sphynx-owner]

I let the motion blur work ground on discord know about this, telling them about your issue submission and my further findings, and I think they will take it from here. Great job finding this its a serious issue. I will keep this one open until a more focused issue is created

[Jamsers]

Are you rotating/handling the camera or the item attached to the camera in _physics_process or in any kind of physics system whatsoever?

[ErrorFoundHere]

I am rotating and moving the camera in a camera's script, I tried both regular _process() and _physics_process() but it makes no difference. The item attached to the camera is simply a child of the camera and therefore inherits it's transforms automatically.

[Jamsers]

I see. Just to be thorough, can you try setting your Physics/Common/Physics Ticks per Second in your project settings to something obscenely high, like 200, and test this scenario again?

[ErrorFoundHere]

I just tested, exactly the same. Tried 20 tics too and it's actually worse (wider smear)

[ErrorFoundHere]

I also noticed an issue where if you change Scaling 3D Scale in the Viewport while the game is running it messes up the Compositor layer and resizes it incorrectly so it doesn't cover the whole screen, but if you close the game and run again with the Scaling 3D Scale changed it works fine.

[Jamsers]

I was able to recreate the bug by moving the camera with AnimationPlayer, both on _process and _physics_process. On my system/project it's so slight you can barely see it, but if you look closely it's there.

[ErrorFoundHere]

The issue is most visible when you move the camera very quickly and put it to a sudden stop

[ErrorFoundHere]

Huh, that's odd. I did some tests and it appears that when I switch the "Scaling 3D Mode" between Bilinear or FSR 1.0 or FSR 2.2 the issue randomly disappears or reappears. Almost as if there was some kind of desync

[ErrorFoundHere]

It seems that when I disable TAA the issue is there with bilinear scaling, but with TAA enabled it sometimes works, sometimes doesn't

[Jamsers]

Yeah that was the case with mine too, but it seems you can kinda consistently trigger the issue by reloading the scene in-game (get_tree().reload_current_scene())

[ErrorFoundHere]

Yeah, very odd I would say

[ErrorFoundHere]

Hm, I'm noticing some very strange behavior, almost as if the depth field reading went corrupt, and it ends up motion-blurring the far away meshes, but all of a sudden up-close meshes only motion-blur correctly in the top left corner. Almost as if some layers of the depth-pass for motion blur got resized for some reason while the further away ones didn't?

I also noticed that once this happens -the spinning mesh I placed in the scene no longer motion-blurs correctly, now it only motion-blurs correctly when I move the camera back and forth quickly enough OR if the mesh is in the top left corner of the screen. Very strange.

I may be wrong tho, I'm having trouble recreating this issue and it's quite hard to make correct observations what is really happening here.

[ErrorFoundHere]

But in general it would seem like there are situations where everything works PERFECTLY fine. But there seems to be an issue where something gets corrupt along the way and it becomes broken creating the issue.

[Jamsers]

I can reproduce the issue quite consistently in the car scenario in Crater-Province-Level/motion-blur-testing, at the end of the first half when the car (and camera) stop abruptly. It seems to only happen when FSR 2 is off - when FSR 2 is on, the issue doesn't happen.

Similar to #88208 in that respect. 🤔

[ErrorFoundHere]

I thought so too, but then I noticed that sometimes while the issue may seem "not present" -it can in fact turn out that the entire motion-blur feature is for no reason not present either, lol. Which is odd. Or at least not present on certain things it seems, it's hard to pin point the exact rule. In particular the object attached to the camera may not have the issue due to not having motion blur either for an unknown reason, while the far away background will have motion blur.

[ErrorFoundHere]

I was able to get those issues with both Bilinear and FSR, tho FSR seemed to "break" the closer "motion vector layers" so the issue was not appearant until you realize that motion blur is also missing. It's a very odd issue because it's not always present, like I said -sometimes it just works perfectly, other times things just get corrupted and you don't instantly notice.

[sphynx-owner]

it seems like you are finding more issues. can you show examples of everything? in case you are finding unrelated stuff that I CAN solve

[ErrorFoundHere]

It's gonna be hard to show it it's really easy to miss and might not be as clear with compressed video quality. I'm having some trouble recreating those issues reliably too, but it would seem that switching between Scaling 3D Modes while changing the Scaling 3D Scale all while the game is running produces some questionable results and some unreliable changes. I guess I could try tho

[ErrorFoundHere]

https://github.com/user-attachments/assets/e5e4a20b-34f2-4c54-9ef4-3f35488fea56

Here, whenever there is a visible issue I circle around it with the cursor

[ErrorFoundHere]

I am not sure if it isn't possible to break it in FSR 2.0 aswell, but if that is the case then it must be rather difficult to make happen because while the other two Scaling 3D Modes are easily breakable for this issue FSR 2.1 seems to work at the very least most of the time just fine.

[sphynx-owner]

even the bilinear one seems broken. I am not sure what you are doing there. regardless, I submitted a bug report for the original problem https://github.com/godotengine/godot/issues/96041

[ErrorFoundHere]

Ye I'm not sure, I'm using a Viewport container and as you can see a Canvas layer performance debug. I'm also using a Canvas item rect that covers the screen to get the lens flare effect. A number of moving parts which I suspect isn't making things easier to identify, but it's still odd.

[Jamsers]

To my eye there are two different bugs going on here - the bug when the camera stops abruptly, and the bug when motion blur only works on the upper left corner of the screen after changing scaling in game

Might be best to try to create a minimum reproduction project for the second bug so that it can be examined closer

It'll also allow us to more definitively tell if it's another Godot bug or a bug with motion blur itself

The first bug is already confirmed to be an engine bug (due to sphynx being able to confirm the raw motion vector output from the engine itself)

[ErrorFoundHere]

Well yes, those are most definitely two different bugs, but I'm mentioning the other one because it directly makes it harder to identify what's going on with the first one. But yeah, I suppose it really came down to identifying that the motion vectors data was incorrect, which is enough for now. Let's hope that's fixed soon

[Jamsers]

I tried recreating the second bug in Bistro-Demo-Tweaked but changing scaling in game there doesn't trigger the bug. However in Bistro-Demo-Tweaked I change scaling by calling:

RenderingServer.viewport_set_scaling_3d_scale(get_viewport().get_viewport_rid(), render_scale)

Not sure how you change scaling in your game but maybe it's specific to that method

[ErrorFoundHere]

Well, I have a viewport container set up and a viewport attached to it, it could be that the viewport container wasn't resized properly and would sometimes overwrite the size of the viewport inside despite the stretch setting being disabled on the container, maybe that's the issue? I'm unsure of this as I don't think the size of the "upper corner blur-space" matched the resulting size of the container, tho it sounds like one of the only thing that would make sense in this situation. The viewport itself may not be resized automatically through the viewport container due to stretch being disabled, but maybe the other features that are supposed to work within the viewport didn't consider the switch? I don't know