4.24 PreviousFrameSwitch and ShadowPassSwitch not working

PreviousFrameSwitch seems not working(I’ve enabled Accurate velocities from Vertex Deformation).
Using ShadowPassSwitch for a shadow pass pixel depth offset also failed.
None of these switches work?

Nope, they work fine.
Mind that previous frame switch would work only, when plugged into world position offset.

As for shadow pass switch, there is no pixel depth offset for dynamic shadows.

I don’t think so. I’ve tried static, stationary with cascade, stationary without cascade, movable.
ShadowPassSwitch does not affect the above options. What I want is to push shadow back using ShadowPassSwitch.

For PreviousFrameSwitch, I connected two different vectors to the WPO input and ensure that Accurate velocities from Vertex Deformation are checked. Is this not enough?

I’m also having issues with this feature. enabling accurate velocities and using previous frame switch only seems to affect movable or stationary objects, but I can’t find a way to make it affect static objects.

this very same thing is explained by Simon here:

of course using non-static objects is very limiting. the overhead of making Foliage movable is undesired, and for Grass it’s even impossible as it’s locked to static.

so is there an actual way to have accurate velocities and previous frame switch working on static objects, or does this require engine changes / a feature request / a pull request?

PS. sorry for reviving this thread

There are two separate settings here.

First is accurate velocities from vertex deformation. It results in basically evaluating WPO network two times, second time being with frame-dependent parameters being set to previous frame values.
It happens during velocity pass.

You are most certainly right, that it should be enough, but you have to be aware, that velocity pass only renders movable objects that actually moved.
For other objects, velocity is reconstructed from scene depth and previous cam transforms.
I suggest you curing that by adding a flag for primitive, that forces it to be rendered in velocity pass unconditionally, if enabled.
(I believe someone on Unreal Slackers discord even made a PR for that).

Second setting is velocity output from base pass.
When this is enabled, velocity pass will be skipped, gbuffer will be fatter, and everything, that you render into base pass, will also export to velocity buffer.
By having both settings enabled, your static geometry will output correct velocity and previous frame switch will work as you’d expect.

thanks for the info :slight_smile:

I thought they are the same thing? the Project Setting “Accurate velocities from Vertex Deformation” sets r.BasePassOutputsVelocity to 1. The only other option is the Material setting “Support accurate velocities from Vertex Deformation” which is just an opt-in to the global Project setting.
sure internally they might be 2 separate things, but as far as using the feature it seems it’s just one thing.

actually when set to movable they seem to render into the velocity pass even if they are not actually moving. that’s the result I got from adding a test WPO animation with previous frame switch, no need to move the actor for it to work (when using accurate velocities setting)

right, that’s what I suspected.
seems to be this one: which is accepted and merged (into 4.25 it seems. I’m on 4.24 atm tho), with bAlwaysHasVelocity component flag. Plus they added another feature on top with the cvar r.VertexDeformationOutputsVelocity

but even then I need the new code right, right? but the VertexDeformationOutputsVelocity tooltip describes a significant performance cost on heavy scenes (my case atm), and suggests using r.BasePassOutputsVelocity instead. however simply using r.BasePassOutputsVelocity I still can’t get the static geometry to output anything and fix the WPO TAA ghosting :confused:

They aren’t.

Not strictly following recent changes in the engine, but prior behavior was for object not to be rendered in velocity pass, unless its transforms changed. I’m reassured nothing changed in that respect though. Perhaps having a material with accurate vertex deformation on the mesh flags it as one always having velocity now, but that wasn’t the case throughout earlier versions.

Nope, you do need new code for the case, when you want to render velocities in velocity pass. Outputting them during base pass will work in stock.

It is a cost either way. You are just choosing between rendering objects one more time versus making base pass a bit heavier and sacrificing a bit video memory on that stage. Applicable to grass, it is simply not reasonable to render it in extra pass and you don’t have options but to render velocity during base pass.

right. so how to get it to work? :smiley:
I only have the Project setting “Accurate velocities from Vertex Deformation” (same as r.BasePassOutputsVelocity=1) and the Material opt-in “Support accurate velocities from Vertex Deformation” - switching those 2 around either combined or not with PreviousFrameSwitch produces no result unless I make my mesh stationary or movable