I’ve got a thin wireframe-like object in my project that has lots of artifacting with a basic Translucent material and that has the following constraints:
- has to ignore depth (or be impossible to occlude behind something else via a WPO hack or something)
- has to be Translucent (for access to SceneColor node which I use for a few things)
- has to be Unlit/Emissive
- has to be visually stable in motion (“motion” here basically meaning relative to the camera/screen)
- has to be visually stable with motion blur
- ideally is not vulnerable to DOF as it is typically rendered close to the camera
What I’ve observed is that - especially in 5.6 onwards - TSR tends to completely reject thin emissive lines like this. You can tell by simply using the VisualizeReprojection buffer.
The result is that any kind of thin moving Translucent Unlit object like a wire will have this blotchy aliased look that seems entirely consistent with a TSR rejection, or there may be more happening.
In 5.4 I could make this emissive object look presentable enough without doing anything fancy in the Translucent material, but I’ve found that in 5.6+ the TSR rejections are killing my ability to iterate on the look of this object.
I could try enabling “output depth and velocity” but then I get DOF artifacts, and even in the case that I turn off DOF completely as a hack, it still tends to have the TSR rejection blotchiness.
If I put it after Motion Blur in the Translucency pass, then it also has zero antialiasing and looks super jagged. If I don’t output depth and velocity, then any motion blur tends to destroy the object.
So my question is what combo of material settings is ideal for a
- moving
- thin, wire-like
- emissive/unlit
object to be stable with regards to TSR? Thanks!
Steps to Reproduce
Open “test” map. PIE, observe floating wireframe cube.
Hi there,
I’ve noted that there appears to be an issue with the wireframe material mode specifically in 5.6+ which appears to be a regression. Since you said wireframe “like” object, can you confirm that you are actually using a material with wireframe enabled? Or was this just set in the example project to give a quick example? I note that using a thin mesh (without setting the material to wireframe) results in much more stable visual output.
Regards,
Lance Chaney
Hi Lance,
Let’s say that I’m using legit wireframe mode for now, but I have perceived this to be an issue whether I use a legitimate wireframe mode material or if I make a “wireframe-like” object using WPO to mathematically construct a very very thin line that is invariant to depth. In your case, even though you have probably made a skinny mesh relatively speaking, it is in absolute terms unlikely to be sub-pixel skinny like a wireframe mode material or like a generated mesh that is actually designed to be that skinny, and so it would probably “solve” the issue by virtue of being thicker.
To me the issue seems to come down to screenspace thickness of an object and how TSR/AA/motion blur handles that rather than the question of actual geometry in 3d space. (but I’d love to be wrong!)
Maybe if you can pinpoint the regression in wireframe mode, that would be interesting to know if that is indeed the cause…
Ryan
I’ve tracked down the cause and created a bug report for the specific case that I can replicate. The public issue tracker will be located here once it has been triaged by epic: https://issues.unrealengine.com/issue/UE-355673. Basically there appears to be a precision / variant issue introduced in commit CL 39929164, which can cause incorrect velocity rendering. However, I could only replicate any issues with this when using a translucent wireframe material with with Output Depth and Velocity enabled. Reverting this commit fixes the issue for this particular test case. I’ve attached a git patch that effectively reverts this change that can be applied to 5.7.
One thing to note is that for TSR to work on a transparent material, it must be set to Output Depth and Velocity. Without this the transparent mesh will smear under motion, wireframe or not. I’ve tested this behavior in several engine versions (including 5.4, 5.5, 5.6) and couldn’t see any visual different without Output Depth and Velocity enabled. In the case the Output Depth and Velocity is enabled, there is a clear difference between 5.5 and 5.6, where the 5.6 version exhibits very noticeable crawling artifacts due to the bug I have just reported.
I note you mentioned that you tried enabling Output Depth and Velocity, but were getting some kind of depth of field artifacts. Could you clarify your setup for this and what exactly you are observing in this case?
I did do some tests with very thin objects without wireframe enabled on their material. As long as Output Depth and Velocity are enabled, these only started to break down when the line became close to, or less than 1 pixel in thickness. The wireframe meshes output by wireframe materials have fairly thick lines compared to this.
In the case of using WPO to create a depth invariant thin line, there could also be some interaction with WPO that could causing your issues. Considering this, and your depth of field issues, It might be good to get a closer reproduction to what you are actually using in your project, assuming this patch doesn’t fix your issues.
Regards,
Lance Chaney
Thanks, Lance! I will give this a try for the wireframe and also for my WPO-generated lines and report back.
No worries. Let me know how it goes.
Regards,
Lance Chaney