Help Fluid not rendering in build

[Barliesque]

I've just upgraded to Obi Fluid 7--removed the previous version before adding the new package.  I've got it running well in the Editor, but in an actual build (for Windows PC) the Fluid Mesh is not rendered.  Any suggestions?

[josemendez]

I've just upgraded to Obi Fluid 7--removed the previous version before adding the new package.  I've got it running well in the Editor, but in an actual build (for Windows PC) the Fluid Mesh is not rendered.  Any suggestions?

Hi,

I'm unable to reproduce this, fluid renders fine in windows builds for us. Which backend are you using (Burst or Compute?) Which render pipeline? Unity version?

kind regards,

[Barliesque]

Hi,

I'm unable to reproduce this, fluid renders fine in windows builds for us. Which backend are you using (Burst or Compute?) Which render pipeline? Unity version?

kind regards,

Unity 2022.3.20
URP 14.0.10
Burst 1.8.17

I have Obi Solver using the Compute backend.  Testing in Editor, I get decent performance with Compute, but with Burst the frame rate bogs right down.  I've made a test build using Burst, and the same thing happens.

Possibly related, the following shader error comes up during the building process:

Shader error in 'Shader Graphs/IndirectTransparent': invalid subscript 'shadowCoord' at 2024/usaf-hangar-hush-house/HushHouse.Unity/Library/PackageCache/com.unity.shadergraph@14.0.10/Editor/Generation/Targets/BuiltIn/Editor/ShaderGraph/Includes/Varyings.hlsl(132) (on d3d11)

Compiling Subshader: 1, Pass: DepthOnly, Vertex program with _MAIN_LIGHT_SHADOWS _SHADOWS_SOFT
Platform defines: SHADER_API_DESKTOP UNITY_ENABLE_DETAIL_NORMALMAP UNITY_ENABLE_REFLECTION_BUFFERS UNITY_LIGHTMAP_FULL_HDR UNITY_LIGHT_PROBE_PROXY_VOLUME UNITY_PBS_USE_BRDF1 UNITY_SPECCUBE_BLENDING UNITY_SPECCUBE_BOX_PROJECTION UNITY_USE_DITHER_MASK_FOR_ALPHABLENDED_SHADOWS
Disabled keywords: INSTANCING_ON SHADER_API_GLES30 UNITY_ASTC_NORMALMAP_ENCODING UNITY_COLORSPACE_GAMMA UNITY_FRAMEBUFFER_FETCH_AVAILABLE UNITY_HALF_PRECISION_FRAGMENT_SHADER_REGISTERS UNITY_HARDWARE_TIER1 UNITY_HARDWARE_TIER2 UNITY_HARDWARE_TIER3 UNITY_LIGHTMAP_DLDR_ENCODING UNITY_LIGHTMAP_RGBM_ENCODING UNITY_METAL_SHADOWS_USE_POINT_FILTERING UNITY_NO_DXT5nm UNITY_NO_FULL_STANDARD_SHADER UNITY_NO_SCREENSPACE_SHADOWS UNITY_PBS_USE_BRDF2 UNITY_PBS_USE_BRDF3 UNITY_PRETRANSFORM_TO_DISPLAY_ORIENTATION UNITY_UNIFIED_SHADER_PRECISION_MODEL UNITY_VIRTUAL_TEXTURING _MAIN_LIGHT_SHADOWS_CASCADE

...though I'd have thought if this was the cause of the problem, it wouldn't work in the Editor either.

---

A few more details...

I have Obi Fluid Surface Mesher set to Opaque.
I'm using a normal map, but no diffuse map.

Renderer features in use: (in order)
1) Obi Fluid Renderer
2) Screen Space Ambient Occlusion
3) Beautify

The URP pipeline asset has Depth Texture & Opaque Texture enabled, as well as SRP Batcher--but not Dynamic Batching.

The Camera has post-processing enabled and a second overlay camera in the stack.

[Barliesque]

Here's an export of the effect itself, so you can check any other Solver & Emitter settings.

By the way, in case you have any suggestions for how I might adjust my settings for better results, here's a video of what I'm trying to simulate: https://www.youtube.com/watch?v=tL-CCwUe8FU

[josemendez]

I have Obi Solver using the Compute backend.  Testing in Editor, I get decent performance with Compute, but with Burst the frame rate bogs right down. 

This is to be expected: Burst performs the simulation in the CPU while Compute uses the GPU. Compute should be at least an order of magnitude faster than Burst for relatively large scenes. For desktop targets, Compute should be used most of the time. For low-end mobile, Burst generally performs better.

Possibly related, the following shader error comes up during the building process:

This is a bug in ShaderGraph. Open up IndirectTransparent.shadergraph, and in the graph inspector, remove the Active Targets you're not using (in your case, Built-in). Doing this will get rid of the message.

I have Obi Fluid Surface Mesher set to Opaque.
I'm using a normal map, but no diffuse map.

Using normal or diffuse maps shouldn't make any difference.

Renderer features in use: (in order)
1) Obi Fluid Renderer

No need to have an ObiFluidRenderer feature if your fluid is Opaque. The renderer feature extracts a thickness buffer and a refraction buffer to be used with transparent fluids, but it's useless for opaque.

Will investigate this further and get back to you.

[Barliesque]

This is a bug in ShaderGraph. Open up IndirectTransparent.shadergraph, and in the graph inspector, remove the Active Targets you're not using (in your case, Built-in). Doing this will get rid of the message.

Good to know.

No need to have an ObiFluidRenderer feature if your fluid is Opaque. The renderer feature extracts a thickness buffer and a refraction buffer to be used with transparent fluids, but it's useless for opaque.

Ah, of course.

Will investigate this further and get back to you.

Thanks for your help. I'm hoping to get this resolved in the next few days.

[josemendez]

Hi,

Your FireRetardant prefab had several ObiParticleRenderer components with no materials. While this worked fine in the editor, it threw an exception in the build, skipping any further rendering. A quick workaround would be to simply disable the unused particle renderers.

However it stands to reason that any renderers using no material should be simply ignored -both in the editor as in builds- instead of raising an exception. We've patched this behavior. If you wish to apply the patch to your project, replace ProceduralRenderBatch.cs with the file you'll find attached to this post.

The reason why rendering worked in the editor but not in the build is because Unity's GetInstanceID() method -which we use to compare objects and build render batches- returns 0 for null in the editor, but instead raises a NullRefException in the build. This difference in behavior is not mentioned in the documentation and led us to assume it would behave the same in the editor and in a build. Furthermore, the documentation states that GetInstanceID() never returns 0 which is incorrect as it *does* return 0 for null objects in the editor.

We've reached out to Unity so that they correct GetInstanceID's documentation so that it matches its actual behavior.

kind regards

[Barliesque]

Excellent! Thank you.

The reason why rendering worked in the editor but not in the build is because Unity's GetInstanceID() method -which we use to compare objects and build render batches- returns 0 for null in the editor, but instead raises a NullRefException in the build. This difference in behavior is not mentioned in the documentation and led us to assume it would behave the same in the editor and in a build. Furthermore, the documentation states that GetInstanceID() never returns 0 which is incorrect as it *does* return 0 for null objects in the editor.

We've reached out to Unity so that they correct GetInstanceID's documentation so that it matches its actual behavior.

Seems to me that should be reported as a bug, rather than a documentation error. It stands to reason that the behavior of GetInstanceID() should be consistent between editor and builds.

Anyway, problem solved! Thank you again.