Lack of previous frame local to world matrix in material editor causes a ton of inconvenience, when working with world position offset.
A typical example would be RotateAboutAxis material expression usage in WPO causing totally wrong velocity output and as a result, unwanted blurring/ghosting, which is commonly mistakenly attributed to TemporalAA.
check out DistanceFieldLightingPost.usf line 35. I’m not entirely sure but you might be able to track down how the params of the function are passed and so end up re-constructing the previous frame world position
or maybe it’s useless. only one way to find out! 
It is not about position. Position is being reconstructed totally fine. It is about a problem, when you are using world to local transform in WPO. It will be the same for previous and current frame. If you use that for rotation axis, the WPO for previous frame will be erroneous.
The best way to illustrate is to attach any mesh to the camera(Motion blur enabled in pp), placed in front of it, and use WPO with rotate about axis around local axis, and put a constant into the angle. Final vertex positions with WPO for current and previous frame should match. But they don’t and when camera is moved and rotated fast, the mesh will wobble insanely.
do you mean when using the Transform node with world->local? in this case I don’t get if what you want is for something to be exposed to the material editor (I don’t know where you’d use a PreviousLocalToWorld node in conjunction with RotateAboutAxis. previous frame switch perhaps?)… or if it’s simply a bug that you’d like to see fixed (properly handling the previous frame internally)
since Ive planned to try to use rotate about axis soon, I can probably have a look at the example you mention. though most likely I won’t be able to solve anything and I’ll just second you in requesting whatever needs to be requested
TransformVector material expression with local as source or destination should automatically be compiled with previous frame transform, when being compiled for previous frame. **It does not. **
It is not a bug, but lack of this feature is a complete showstopper for any local rotations in WPO, if world-local relation changes over time.
Ideally, the change should be applied to all material expressions concerned, but just having the matrix accessible in pixel/vertexshaderparameters would be enough, since we have previous switch material expression.
so is this what you mean? :eek:
Yes, exactly.
well I get the same issue even if I don’t use a transform node
^^ that’s enough to produce the bad motionblur
and of course unhooking WPO “gets rid of the issue”
wait. WPO unhooked now:
I had to rotate the camera really fast to get it though. I guess this is expected behavior
but with the RotateAboutAxis, the result of my first screenshot is just from normal walking
Your pivot position is also fed by a data, that has no replacement in previous frame, also providing erroneous calculations.
yeah I figured as much
in any case, is this an issue for non-moving actors?
for example here I have the cube spinning really fast but I don’t move the character.
I have Motionblur and TAA enabled, though I had to disable DFAO otherwise it’s really bad. but I don’t get any ghosting or blurring, all I get are hard/jittery edges
ok something with alpha makes it really evident when using TAA
so, yeah
For the issue to be present, all of the following has to be true:
so indeed it only affects moving objects. or is there any reason to change the object’s local to world transform on a static object?
btw enabling ‘Accurate Velocities for Vertex Deformation’ in the project settings fixed the bad ghosting on my static spinning grass. of course it doesn’t help with the movable cube though (but for now I have no need for movable objects requiring RotateAboutAxis)
Object being static kinda implies that point number two from the list above is not met, so it won’t constitute a problem.