Foliage WPO Velocity for TAA smearing

coming from this thread:…ch-not-working but by now it’s better to make a new one.

I tried this on 4.24 and earlier with no luck. I’m on 4.25 now and I still can’t output velocity from WPO on static objects, namely foliage. without this I can’t fix the TAA smearing on my foliage.

on 4.25 the material option “Support accurate velocities from Vertex Deformation” was removed, so now only the r.BasePassOutputsVelocity project setting remains (though it was renamed from “Accurate velocities from Vertex Deformation” to "Output velocities during base pass)
enabling/disabling this project setting has zero impact on the output velocities from my static foliage WPO animation

a new project setting “Output velocities due to vertex deformation” was added which controls r.VertexDeformationOutputsVelocity
enabling/disabling this project setting also has zero impact on the output velocities from my static foliage WPO animation, which seems expected because the code specifically checks for movable objects for this to work

**TL;DR **- how do I fix the TAA smearing on my static Foliage and LandscapeGrass, caused by WPO animation?

Looks bugged beyond all reasonable recognition. Checked 4.25, and only movable instanced foliage will writes velocity, but not static hism or grass.
Also, for the record, in that commit, IsMovable check makes zero sense to me.

If Material modifies world position(It might make sense to check if, if it modifies it in a way, that is different between current and previous frame), you should be writing velocity disregarding if object is movable, moved or not, and should be rendering object into velocity pass anyway, if base pass velocity is disabled, as long as velocity from vertex deformation is enabled.

figured out as much, thanks

Static mobility, the renderer assume the entire mesh is static, because of light baking… so this include WPO no moving what so ever, and therefore it doesn’t draw the velocity at all of the mesh

Just do vis Velocity (if r.BasePassOutputsVelocity=0) or vis GBufferVelocity (r.BasePassOutputsVelocity=1) in the console.

Now… ironically, this is a problem Fortnite ran into too. Could change mobility of the component to stationary mobility, but just a change that is to wide spread, and so to address the problem on large scale on the many components we have is force the base pass to draw velocity with this change:…b86ed907d3ac46

This will work only if you use r.BasePassOutputsVelocity=1 (“Output velocities during base pass” in renderer settings)

Now the problem is this change will make TAA’s AA_DYNAMIC_ANTIGHOST of r.PostprocessAAQuality=4 completely ineffective as if you are running with r.PostprocessAAQuality=3, because it can no longer differentiate between static geometry versus staionary and movable geometry in the velocity buffer. But for us, we actually use r.PostprocessAAQuality=3 on all consoles platforms anyway because of performance constrains, and get away with the ghosting thanks the cartony look of fortnite that ends up creating a very narrow history rejection clamping box.

Then just remember to use a PreviousFrameSwitchif you animate your WPO animation from with dynamic material parameter.

Now you might be wondering then what is the point choosing between correct motion vector of WPO and more ghosting, or not? Kinda crappy choice… And to awnser this, I will let you explore github :rolleyes:

Velocity eval for every primitive seems unreasonable. Should be per primitive or per material flag.

that’s the entire point. I can’t set everything to Stationary/Movable for performance reasons. even if I wanted to, Foliage is Static/Movable (no Stationary) and Landscape Grass has no option at all.

well I tried every combination of options in 4.24 and 4.25 and I still can’t get my -static- foliage and grass to render without TAA smearing, so what I’m really wondering, given how UE4 relies so much on TAA, is if this issue will ever be solveable :smiley:

This can be fixed by a simple checkbox. Go to project settings, rendering, optimizations, then turn on Output velocities due to vertex deformation. Immediate changes will show, Then use r.TemporalAASamples=4 and r.TemporalAACurrentFrameWeight=0.2 for your taa samples/weight. The change will be night and day, not literally, as it has no affect on sun position… Atleast its supposed to not.

thanks for trying to help but please take the time to actually read the thread :wink:
as I stated in the original post the project setting literally does nothing on static objects (the underlying code checks if the object is static, and if so it skips it). but look for yourself: try any of the velocity debug views (console: “vis Velocity” / set viewport viewmode to Buffer Visualization: Velocity / enable motionblur and do show -> visualize -> motion blur), you’ll see no velocity vectors from your animated foliage/grass.
using less TAA samples and a higher frame weight only hides the issue a little bit (and I’m already using similar settings btw) but it doesn’t really fix it.

atm there’s no combination of settings that will make -static- foliage and grass actually output velocities from WPO animation, which results in visual ghosting

Any fix for that?

Is this still an issue in 4.26 when using r.TemporalAA.Algorithm 1 ?

I already did read the thread. That fix works 90% of the time but after reading other threads, apparently its a bug with the engine itself that happened in 4.25, which is fixed by making the grass movable which is… a crappy bandaid patch at best. I have not seen any other fixes except waiting for 4.26.1 or further to fix the issue.

Any news about this? There’s still no velocity output unless setting meshes to moveable (which can’t even be done for landscape grass type)

Yes, gen5 TAA still require velocities for WPO motion not looking blurry

Sorry for the delay in my response as I needed a last minute break for personnal reasons.

r.TemporalAA.Algorithm=1’s history rejection no longer need to differentiate dynamic geometry from static geometry in the velocity buffer that r.PostProcessAAQuality=4’s AA_DYNAMIC_ANTIGHOST need. So r.BasePassForceOutputsVelocity=1 would basiaclly make Gen4 TAA exactly like r.PostProcessAAQuality=3.

So using 4.26’s r.BasePassForceOutputsVelocity=1 when you have r.TemporalAA.Algorithm=1 or r.PostProcessAAQuality=3. Not that r.BasePassForceOutputsVelocity=1 only work when r.BasePassOutputsVelocity=1. the performance overhead r.BasePassForceOutputsVelocity=1 is negliegable on base PS4 and base XB1 and more powerful hardware thaw, due to the BasePassPixelShader.usf already compiling all the math to compute the velocity and just outputing black when the geometry is static.

In case needed, there is a feedback forum thread about Gen5 TAA hereI’m trying to remain as active as possible if you feel like talking/give feedback more about Gen5 TAA.

no worries :slight_smile:

so if I get it right, on 4.26 using the following settings together:

r.TemporalAA.Algorithm=1 -or- r.PostProcessAAQuality=3

… should compute proper velocity from WPO, ultimately getting rid of WPO ghosting?
I’ll have to give it a proper try then!

looks like *r.BasePassForceOutputsVelocity=1 *was the missing piece for me. I was confusing it with another project setting so I never really tried this one before.
I can confirm. the following settings

r.TemporalAA.Algorithm=1 -or- r.PostProcessAAQuality=3

compute proper velocity from WPO from static Foliage, correctly showing in both the Velocity Buffer and the Motion Blur visualization view
thanks @Guillaume.Abadie! :slight_smile:

@Guillaume.Abadie update: setting* r.BasePassForceOutputsVelocity=1 *leads to SingleLayerWater having completely broken motion vectors, causing a horrible smear all across the water
see image

is this issue known?

I confirm this one, reflection on water is broken with r.BasePassForceOutputsVelocity=1

Did you guys reported the issue or there are any news about ?

I wanna ask you guys a question about this.
I have a project that i upgraded from 4.24 to 4.25 and then 4.26, now if i use the “r.BasePassOutputsVelocity=1” option i am getting some really bad artifacts on my landscape (black splotches)
kinda bizzare.

Infact, if I remove the landscape material i still get these artifacts.
If I disable this option the artifacts go away.
If I create a brand new project the issue is not there, then if i enable this from the UI the issue appears right after restarting.

I cannot be the only one having this problem!
(it can be reproduced on binary and source versions of 4.25 and 4.26 using the bruishify example landscape shader pack…)

I’ve been using this for years without issue.
I’ve also seen this issue recently in SCUM since they moved to 4.26, so its not just my project. (can be seen on distant landscape bits, i think it flickers when it is changing lods as if you lock the landscape to lod 0 you also dont see the issue…

Has anyone else seen this???

have attached a screenshot for ref…