I have a display bug that cropped up when I upgraded from 4.13 to 4.14. I use a translucent water plane and a translucent cloud layer. These pop in an out with tiny camera movements as can be seen in this example video:
This only happens in a packaged build. PIE works without error. This didn’t occur in 4.13. This happens both with the forward renderer and deferred rendering. If I clear the level so that it is just the water plane, it still happens though much less frequent.
I’ve tried everything I can think of. What is the best way to debug this to know if this is an engine bug or some issue with my content?
More info: It turns out that the issue happens in stand alone game from editor as well, which helps iteration so much now that I don’t have to package to test. I was also able to look at wire frame, and the ocean and sky are still there, so it doesn’t seem to be an occlusion issue, but instead something to do with the translucency materials not rendering anything.
Hi dustums,
That almost looks like a bounds issue, but I doubt that is what’s going on. Are you using the water planes provided by epic? I would like to see if I can reproduce this on my end.
The best way is for you to either provide a small sample project that reproduces the issue. You can PM me on the forums, my name is .
Or give me a list of steps so that I may reproduce this on my end.
,
Ed
Thank you so much, Ed. I’ve boiled down the simplest material that fails in my project. It’s as simple as using the Scene Color as the base color (see attached image) I also show a version that is a bit easier to see in level since Scene Color as Base Color is basically another version of 100% translucent (though you can still see it due to lighting).
Sadly though this doesn’t fail in a fresh project, so I know this isn’t enough for you to debug. But maybe it might spark an idea in you to guide me in the right direction?
What I’m going to do now is strip down my project to bare bones so I can send you a failing sample that is reasonable in size. Maybe as I strip down my project I’ll find the thing that makes the problem go away.
I don’t see anything wrong in your material, I would take a look at the static mesh that you have applied your water material to. Maybe try applying your water material to a simple cube from the basic tab. Then scale it up a bit so that it fills the horizon and see if the flickering occurs. I have a feeling that the issue may be with your mesh.
Feel free to comment here once you are done narrowing things down.
I had already tried the material on a basic cube before I ever posted here, and it fails (guess I should have mentioned that). I had sent you a PM on the forums with a stripped down build for repro, but I’ll post the link here:
https://www.dropbox.com/s/sv3bl2s32z7s0a6/Pegs%20Mini.zip?dl=0
This is a bare bones build with most of my code and assets stripped out. It’s just a bare level containing a cube with the simple material. It mostly doesn’t even pop; it just doesn’t display at all in stand alone (though appears fine in PIE). If you try really hard you can get it to pop in and out.
Currently I’m in the painful process of rebuilding my project from scratch by taking a blank C++ project and copying over my code and migrating my assets. So far the problem hasn’t manifested itself yet. So a bare bones old build breaks but a rather complex new build isn’t failing yet. Does this suggest it was a 4.13 to 4.14 migration issue?
Hi Dustums,
Thank you for providing the project. This is actually caused by the config folder in your project. This may be a conversion issue where some values get modified in the config folder when converting to 4.14.
Since this folder gets generated at runtime you can delete it (granted you will have to redo any config settings you had specific to your project). The issue gets resolved after deleting the config folder and running the project.
let me know if that helps,
Thank you for looking into that. Deleting the config directory isn’t really a solution but more of a “nuke the site from orbit” work-around. There’s lots of needed stuff in my config files :). However, this did guide to to find just which line was causing the issue, and it was this:
[SystemSettings]
r.rhicmdbypass=0
Now, I’m not sure why I put this in my config, and not sure what turning off the Rendering Hardware Interface bypass really means. I must have read online somewhere that this was good for VR or dynamically lit scenes or something?
The question is though, is it a bug in 4.14 that using the command r.rhicmdbypass=0 makes Scene Color fail in translucent materials, or is that to be expected and for some reason it didn’t fail in 4.13? What exactly does the RHI command bypass do?
Sad news. Removing r.rhicmdbypass=0 fixed the issue in my main build for Standalone from Editor, but the issue is still there in my packaged build. Time to beat my head into the wall some more.
Update: I found the line that caused the issue in my packaged build:
r.SceneColorFormat=2
I also know where I got these settings. It was from Unreal documentation for VR:
It recommends both of these troublesome line:
r.SceneColorFormat=2
r.rhicmdbypass=0
So either there is a bug introduced in 14.4, or that VR documentation should be updated so others don’t fall into this trap.
WIth further checking it looks like r.rhicmdbypass=0 was a red herring. The real culprit was r.SceneColorFormat=2. With that removed, r.rhicmdbypass=0 doesn’t seem to cause any problem. What exactly does r.SceneColorFormat do? This seems to be related to scaling?
r.SceneColorFormat defines the memory layout (RGBA) used for the scene color.
(affects performance, mostly through bandwidth, quality especially with translucency).
- 0: PF_B8G8R8A8 32Bit (mostly for testing, likely to unusable with HDR)
- 1: PF_A2B10G10R10 32Bit
- 2: PF_FloatR11G11B10 32Bit
- 3: PF_FloatRGB 32Bit
- 4: PF_FloatRGBA 64Bit (default setting, might be overkill, especially if translucency is mostly using SeparateTranslucency)
- 5: PF_A32B32G32R32F 128Bit (unreasonable but good for testing)
Keep in mind that the console variables may change their influence and or meaning between engine versions. This seems to be one of those cases which is why I recommended deleting your config to see if that solved the issue.
That doesn’t explain why the objects that are using scene color would outright disappear and that seems like a bug. I’m glad you found a workaround. I will take a look at those variables and see if there was a regression.
,
1 Like
so much for the help, Ed. So I tried r.SceneColorFormat=3 and it fails too. That means I have to use a 64Bit scene color buffer. My project is for VR where every bit of performance is critical, so having to double the size of the color buffer doesn’t seem ideal. Hopefully that could be filed as a bug please?
If it doesn’t get fixed, then at the least the document page XR Best Practices in Unreal Engine | Unreal Engine 5.1 Documentation should be updated so that others don’t fall into this trap (though I guess is you aren’t doing SceneColor lookups in your materials, this isn’t a problem).
Thank you again!
I tested your sample project on the newly released 14.1 hotfix and didn’t reproduce your issue in standalone. Would you mind testing on your end to see if this has been resolved?
Yep! That fixed it.
Great news is that I’m back in business with a 32 bit Scene Color buffer.
Bummer news is that I could have just taken off the last week goofing and wouldn’t have wasted any of your time either. But got to report the bugs we find, right?
again.
I appreciate how proactive you are. That helps us find issues and fix them and that benefits everyone!
