But the volume resolve is not part of the forward pipeline at all?
I actually think we eventually will have to go in the opposite direction. The final ShadingView::render order should be…
So the world volume should be deferred but the world itself don't, is that right?
There is a bit of a design problem when things to too much effect centric instead of being data centric.
The problem is that trying to force the volume pipeline into the geometry pipeline…
Maybe one last polish you can do, is to reset TAA if overscan changes, because the motion vectors are wrong in this case.
Unless I'm missing something, Film::init already takes care of…
Just confirming that the committed fix does, indeed, solve the issue on my end.
@HooglyBoogly That code only runs after a brush stroke, and only if the PBVH is in PBVH_FACE mode, which didn't seem to be the case when I've debugged it. In any case, even forcing it to run…
How about moving the comment to the header file?
/* Perform VelocityGeometryData offset computation and copy into the geometry step buffer.
* Should be called after all the vertex…
Honestly, I'm not a big fan of splitting viewport/render code like that if it isn`t necessary. We have plenty of bugs/regressions of features working in the viewport but not on render, and I…
I've added it back to geometry_steps_fill.
I've removed the "Now that vertex buffers are guaranteed to be updated", since that's not something that the function itself can actually guarantee.
