iOS rendering error - precision error with AWP or Distance shader nodes

hey folks,

I’ve really been struggling with an issue here. I’m almost 100% there’s an issue with how unreal is building shaders for iOS (possibly other mobile platforms, but I can’t confirm). I’m trying to reveal a material over the whole environment from a world position using some basic distance math but when building for iOS the results are completely broken. All the different preview modes work great (SM4, SM5, ES2), but when it gets on to the platform everything falls apart. I have [another question][1] going to try and solve it, but with no luck. At least over there, you can see the result of the error with the supplied images.

But out of all my tests, I really feel like there may be an issue with either the AbsoluteWorldPosition, distance, or division shader nodes. I doubt it’s the div. node, but the other two seem to be the culprits. Would someone be able to confirm?

This is the math that’s causing my problem. Again - only when built an iOS device.

Any help is very much appreciated.

You don’t have enough depth with medium and low precision GLSL values in the fragment shader to do that kind of math and get accurate results. You could try moving the calculation to the vertex stage using Customized UVs ( Customized UVs | Unreal Engine Documentation ), depending on the kind of mesh you’re using. You might need to subdivide it a few times if it’s a plane or just a few large triangles. Vertex shaders will run with full precision (instead of half precision), and will be cheaper since it won’t be calculated per-pixel.

I’ll give that a shot and see what happens. I’m going to suggest (wherever that may be. Forums, I guess) to have the ES2 preview simulate the precision so that it’s not a surprise when doing a build.

All this because unreal doesn’t support custom Post processes on mobile. I hope that changes once Metal is completely supported / integrated.

Simulating the precision would be difficult, it would have to be somehow injected into each operation in the shader. Plus it can and will behave differently on different hardware and platforms. It’s not impossible, though. The easiest way to get a real check of how it’s working is to look at it on the device :slight_smile:

indeed, but if Epic actually wants to be a serious contender with Unity for the mobile market then those are the types of things they need to make sure work very well.

Unity has the same “problem”

so I transferred everything to the vertex shader but with no luck, I have the exact same result unfortunately. I’ll create a video to show my problem.

just realized that I can’t capture the video because the problem only exists on the device. Not sure how to go about show this problem.

the more this goes on, the less I’m thinking it’s actually a precision error. Especially now that I have it all calculated in the customizedUVs and the result I’m getting is the exact same.

Normally low precision returns garbage. This is not my case, it’s returning a very smooth/clean but wrong result.

Hi Floggins -

I am not seeing the same results you are describing. Using only the math you are showing above and a Texture I am able to feed the math into a UV and get the results I would expect both using a Material Function and without.

Here is a screenshot of my results on an iPhone5s:

Can you provide the full Material and Material Function for testing, screenshots of said materials, or explain in detail how you are using the math specific to the material causing your issue?

Thank You

Eric Ketchum

hi Eric, thanks for the reply. I’ll definitely do that as soon as I get to my machine. But in the meantime - in the Scale input I’m setting the offset. If this offset goes over a certain value, it no longer works. The value is around 250. Over that it ramps up exponentially, resulting in the whole world being covered as if the falloff (hardness) is set to infinity.

If you look here at another question (this thread is a bug as opposed to an regular question), you can see a little closer how I’m using it. Just so you know - the animation I’m doing now is a simple clamped sin wave for debugging fed from a blueprint. Eventually this will be driven by gameplay. This actually makes me wondering if the bug is coming from blueprint instead of from the shader editor. I’ve output (print to screen) the result of my blueprint script to see if it was generating any strange values. Everything was ok, but I guess that doesn’t mean it’s working properly in a build. When I get to my pc I’ll also put the debug sin*time in the shader to see if it has the same result.

hey Eric, is there somewhere I can direct message you to send you a link to the project? I have no clue how to extract all the pieces so that you can import it. The export tool does not seem to take along the dependencies of the selected item. At least that’s how it seems. It’s probably just easier to share the whole thing, but I would rather not post the link to that here.

Hi Floggins -

You may private message me via the Engine Forums.

Eric Ketchum

Hi Floggins -

I was able to get a reproduction of the error internally and have submitted a bug report as UE-25532. As we investigate a solution and cause I will keep you informed here of the outcome.

Thank you for your assistance -

Eric Ketchum

fantastic! thanks for the feedback. So I guess you don’t need my projects anymore?

That’s correct. Thank you for your assistance.

hey Eric! sorry to be a pain, but I was just curious if there’s been any progress on UE-25532? Thanks!

hi folks, Eric…

does anyone have any sort of ETA on this? thanks!

Hi Floggins -

Our engineers are actively working on the issue currently, but it does not look like it will be ready by the 4.11 release. As soon as I have a fix I will post back here with the Github pull for you though.

ok, thanks Eric