Do you have plans to fix tex3Dlod in Metal in Unity? This is still broken, has been for years, as of 2019.1.10…
Consider submitting bug report
Already submitted a while ago… 
1 Like
Might not do anything, but you could try writing your shader in D3D11 HLSL using _textureObject.SampleLevel(sampler, uvw, lod) instead of tex3Dlod(_samplerObject, float4(uvw, lod)).
// define texture and sampler state objects separately instead of using a single sampler3D
Texture3D _My3DTexture;
SamplerState sampler_My3DTexture;
// in the vert or frag function
half4 col = _My3DTexture.SampleLevel(sampler_My3DTexture, uvw, lod);
Most likely this still won’t work, but it’s worth a try?
Hey,
I’ve had a look in our bug database, to see what’s going on here, and learned that QA closed your metal bug report as a duplicate of the “same” issue on webgl.
However I think it’s highly unlikely that it really is the same underlying issue, but rather the same API is broken on 2 platforms for 2 platform-specific reasons.
So, I’ve spoken to the metal team and we agree that the duplicate bug should be reopened and decoupled from the webgl one. So hopefully this will mean that the metal bug gets looked at soon(ish)!
Apologies that this one had slipped through the cracks!
3 Likes
I have tracked this down to a combination of tex3Dlod and using a “continue” statement in a for loop. Removing the continue statement, while making the result look not quite right, does fix the tex3D lookup. Any ideas why this would happen only on metal? OpenGL and DX and Vulkan are quite happy with the continue statement. No shader warnings or errors on any platform, including MAC and iOS.
From what I can tell, the continue statement is getting the shader in a funny state where it will pop out of the entire for loop early, regardless of whether the continue statement is executed. Probably due to the shader running all the code regardless of if statements maybe? I would have expected the continue to not fire at all, as I wrapped it in an if statement around a uniform that was set to 0.
The for loop and all the if statements had UNITY_LOOP and UNITY_BRANCH applied.
Now that I have identified the problem, I have rewritten the shader to not use a continue, but to apply if statements further down inside the for loop to skip sections using a new variable. I will test WebGL to see if it is fixed by this also and post back.
1 Like
WebGL is still broken even without the continue statement. Tex3Dlod just does not work in WebGL 1.0 or 2.0 at all.
1 Like
Is there a bug logged for this anywhere so I can track whether this ever gets fixed? Many customers want WebGL with these clouds, but right now it is impossible…
Yep, the WebGL one is here: https://issuetracker.unity3d.com/issues/webgl-3d-texture-lookups-tex3dlod-in-shader-are-always-0 If you and your customers vote on it, it will get pushed up in our prioritisation scheme.
And the Metal one, for completeness: https://issuetracker.unity3d.com/issues/metal-shader-does-not-work-on-metal-and-does-not-produce-any-errors-or-warnings (This one is currently marked as Won’t Fix, but that’s not really accurate - QA are re-assessing it because we were having trouble running the large attached project and creating a new minimal repro didn’t show any error. If you’re reading this, and it’s your bug report, feel free to supply a simple small repro to aid us in fixing it)
Hi all, thanks for this thread. The Metal variant of the bug is still marked Wont Fix, thought I would confirm that it is still open and/or check if theres a new status. Thanks!
Hey @therealcowhunter , I’ll send this post over!
I just checked the Metal and discovered we have resolved that bug as user error. I posted this comment on the issue tracker about it: