@JFonS any other blockers?

I have now exposed this to BaseMaterial3D.

@EMBYRDEV Could you please rebase against the master instead of merging it into your branch?

@EMBYRDEV Could you please rebase against the master instead of merging it into your branch?

Done!

Is there anything else needing done before looking at getting this merged?

Do you have a test project available to make sure this PR works as intended? I'd like to test this locally. This can be a scene with your post-processing shader setup.

@Calinou omg, I put it in my recycle bin last week and never got around to emptying it... lucky. 🤣

Here is a google drive link for the scene in the screenshot.

Both the post processing shader and the smoke on the torches have this render mode enabled. Remove the render mode to see the default behaviour of the engine prior to this PR.

Is there anything else needing done before looking at getting this merged?

Clay needs to give it a review as the rendering lead. I asked and he said that he'd like to take a look.

Rebased :)

@clayjohn any chance this can make it in for 4.2?

Yep, its tagged for "4.2". I just need to give it a review

@EMBYRDEV Are you able to do the changes suggested by @clayjohn?

Just to add some more feedback. I have a lot of problems with motion vectors on transparent materials with TAA. While using this flag will have the drawback of destroying smaller particles, it is very needed for a lot of effects. TAA often introduces weird artefacts at the edges of transparent particles/quads. Is it planned to also add this flag to the StandardMaterial3D or just just in shaders?

It depends. As of 4.2, we never write motion vectors when using transparent materials. So if your need is just for disabling TAA on transparent materials, then it will be fixed in 4.2 without this PR.

If you are using one of the 4.2 betas, and are still having issues with transparent materials, then this PR won't help you.

If you need to disable motion vectors for another reason, then we can move forward with this PR. Basically this PR is just waiting until someone finds a need for it.

I want to add that this issue with Motion Vectors also applies to more than just post-processing effects. I've been working on a terrain system with polygons that follow the Camera as it moves (in unit steps), the motion vectors used for FSR 2 cause a lot of artifacts when the ground shifts position. I've included videos below to illustrate the issue:

No Upscale + FXAA (baseline, no artifacts):
https://github.com/godotengine/godot/assets/1392440/0254a1d2-8130-4322-97b1-43c24e085935

Upscale (0.5 renderscale) + FSR 2
https://github.com/godotengine/godot/assets/1392440/2f7990ac-7ed6-489f-a4be-cedfb364bb48

As you can see, FSR2 looks great while still.. but in motion these artifacts essentially make it unusable with this terrain technique without the ability to disable motion vectors. So I would love to see this render_mode motion_draw_disabled option added in the future, and would even suggest including an additional motion_draw_custom option in the future. That would allow shaders to output their own screen-space motion vectors explicitly, as any "one size fits all" solution will likely have performance/memory trade-offs and may still be unusable in some situations (such as ray-marched clouds, or other visual effects) where doing motion calculations in the shader is basically the only practical solution.

I want to add that this issue with Motion Vectors also applies to more than just post-processing effects. I've been working on a terrain system with polygons that follow the Camera as it moves (in unit steps), the motion vectors used for FSR 2 cause a lot of artifacts when the ground shifts position.

Can you try this PR out and confirm that it does indeed help with your issue? I'm not convinced that using this shader flag on a large portion of the screen with an opaque material wont lead to smearing artifacts. Although, with motion vector passthrough, if we ever address #67332 then the sky might help some of those issues.

Can you try this PR out and confirm that it does indeed help with your issue?

I copied my Godot repo (up-to-date with master) and fetched this PR... however while the new motion_draw_disabled render_mode option is there... FSR 2 itself is not. I'm assuming this PR is from before FSR2 was added into master, but without FSR2 it's hard to test. While TAA does seem to have some subtle artifacts due to motions-vectors... it's not noticeable enough for me to do valid comparison. Certainly no where near the very obvious "fuzzing" FSR2 artifacts.

I tried merging in master.. but there's 5 different conflicts I'm not going to try and resolve myself. If there's an update to this PR with those issues resolved, ping me and I'll try again.

@clayjohn I can confirm that this is still required as of 4.2rc1 With FSR2 enabled the problem isnt as pronounced but if you have FSR disabled and TAA enabled then we do still need this for post processing effects.

I'll take some time soon to rebase this against master to aim for 4.3.

I have rebased against master and this should be safe to merge now.

As for @clayjohn's suggestion of switching the shader variant instead of using the define, this actually causes a problem as the rest of the pipeline seems to expect the shader to still have the vector in it's output layout.

And since we don't check for the disabled flag here it works nicely. If you have any suggestions on how best to handle this then I'll be happy to implement but this seems like the most streamlined solution.

As you can see, FSR2 looks great while still.. but in motion these artifacts essentially make it unusable with this terrain technique without the ability to disable motion vectors. So I would love to see this render_mode motion_draw_disabled option added in the future, and would even suggest including an additional motion_draw_custom option in the future. That would allow shaders to output their own screen-space motion vectors explicitly, as any "one size fits all" solution will likely have performance/memory trade-offs and may still be unusable in some situations (such as ray-marched clouds, or other visual effects) where doing motion calculations in the shader is basically the only practical solution.

I don't think disabling the motion vectors would result in any different result at all in your use case here: motion vectors are not generated for static geometry in the first place and are derived from depth buffer and the camera movement.

It sounds to me like your second suggestion is the one that applies the best: being able to output motion vectors value from the shader. I've suggested as much but it sounds like it'd have to be added by modifying parts of Godot I haven't really looked into yet (shader compiler, the shader template acknowledging the new shader variable, permutations, etc).

motion vectors are not generated for static geometry in the first place and are derived from depth buffer and the camera movement.

Yes I figured, but keep in mind the ground is not actually static, but a mesh which moves along with the camera at distinct unit steps. In between those steps things look fine, it's only for a split second after each "step" (where the ground actually shifts position) where the artifacts occur.

That being said, I agree that ultimately just disabling motion vectors might not fully solve everything here, as other parts (like portions of the grass) will do the same thing as the ground (in terms of following the camera), but also sway with the wind, and so dynamically move each frame. Ultimately having the ability to output correct motion vectors may be the only way to eliminate artifacts (tho for the most part it looks fine until the large snap happens).

Terrain3D has issues with TAA/FSR. Like Phil, our terrain is a clipmap. The meshes follow the camera and the vertices move potentially every frame. I'd like a method to disable motion vectors on the terrain while allowing the user to have them for the rest of their scene. Or a method to clear, overwrite or insert an inverted motion vector so these modes are usable.

Downstream issue
TokisanGames/Terrain3D#302

So I havent tested the new CompositorEffect API but I imagine that removed my usecase for this PR, being PostProcessing shaders that play nicely with AA.

That being said this may still be useful for some particle types where smearing is desired over rippling effects (EG. Small smoke particles & sparks)

As for Terrain3D I have a feeling that enabling this mode would potentially lead to the terrain itself becomign a smeary mess.

@TokisanGames would you be able to give this PR a test to see if this actually solves your issue or if we need a differing approach?

I built this PR rebased off of the 4.2 branch. With TAA enabled on my 3070, motion vectors are mostly calculated correctly, with flickering only in some areas. This PR does disable motion vectors, but it turns my terrain into a blurry mess.

TAA

TAA Motion Vectors

TAA Motion vectors disabled

Ahh looks liek this isnt the solution to your problem. I think it is still super important to expose the ability to passthrough motion vectors from behind the object as some large billboard sprites like lens flares can cause big problems with TAA but I think in addition to this we need to expose a way to write custom motion vectors from shader.

I'll get this rebased and implement feedback soon so that this can make it in for 4.4 sorry for the delay.

Is this PR still ongoing?

Is this PR still ongoing?

4.4 is currently in feature freeze, so any new features can only be merged in 4.5 at the earliest.

Just an update on this. The main problem identified when this PR was created was that transparent objects were inappropriately overwriting motion vectors. That turned out to be a bug and we fixed it separately in 4.2. Afterwards both PhilipWitte and TokisanGames reported issues with their terrain systems since clipmapping requires teleporting meshes around to adjust terrain LOD. We now have a solution specifically for that problem that is approved and should be merged soon (#105437).

Embyrdev highlighted that the original problem still exists when using TAA (which means that the bug may not be been fixed for TAA) and that there may still be some value in disabling MVs entirely for certain mid-processing effects (lens flare etc.).

Given that my personal opinion is that we should:

1. Investigate and resolve the issue of transparent objects writing to MVs when using TAA and not FSR2
2. If users find situations where they need to disable MVs for mid-processing effects, then we should expose a writable MOTION_VECTOR built-in. We already know we need it anyway since its necessary for any sort of texture scrolling VFX, so I would go ahead and implement it. After doing so, I would re-evaluate whether this PR is necessary.

My hope is that this PR is unnecessary. That is not to say that it isn't well done or isn't a good PR. I think it is well done, but I hope that the feature it implements is ultimately not necessary. Ideally users would be able to selectively avoid the problems of bad MVs without having to disable them entirely. Disabling MVs removes all the benefits of TAA from the object entirely and can easily defeat the purpose of using TAA or FSR2