Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Help  Looks nice on editor but not iOS device
#1
Hello! I am using obi fluid it works nicely looking on editor, but not on iOS device 

what could be issue ? 

please check screenshots


[Image: IMG-1014.png]
[Image: IMG-1013.png]
[Image: Screenshot-2025-09-02-at-12-14-14.png]
[Image: Screenshot-2025-09-02-at-12-14-09.png]
Reply
#2
Hi,

Which of those are taken from the device, and which ones from the editor? What do you mean by "not nicely looking"? Is the problem the square-is shape in the bottom screenshots?

Also, which render pipeline are you using? Which simulation backend? Unity version? iOS version?

kind regards
Reply
#3
(02-09-2025, 10:26 AM)josemendez Wrote: Hi,

Which of those are taken from the device, and which ones from the editor? What do you mean by "not nicely looking"? Is the problem the square-is shape in the bottom screenshots?

Also, which render pipeline are you using? Which simulation backend? Unity version? iOS version?

kind regards


Hey Jose thanks for quick response! 

Unity 6.2 , Xcode 16.4  device version 18.0.0 
I use mobile renderer URP pipeline 
I use burst backend 

bottom 2 screenshot from editor it looks smooth and nice , however first and second image from device which very jittering and looking bad not smooth 

https://www.dropbox.com/scl/fi/75ytbufzn...w18va&dl=0

https://www.dropbox.com/scl/fi/ugz2lpmrx...1998h&dl=0


Can you check this video please

https://www.dropbox.com/scl/fi/hz5o1qfrm...3x9rc&dl=0
Reply
#4
Hi,

I'm unable to reproduce this. By the looks of the screenshots/video, it's some kind of z-fighting taking place when rendering the fluid's color texture buffer. This is caused by the transparent mesh being rendered atop a second version of the same mesh, resulting in some triangles in the mesh randomly being discarded or occluded.

My advice would be to use Unity's frame debugger to debug rendering on the actual device, see what's causing the z-fighting problem. If you need help interpreting the debugger's info we can help.

As a last resort, you could write a custom shader that simply passes vertex color to the final fragment, unmodified (not modulated by thickness, not refracted). This does away with the need to use an intermediate color buffer and will likely bypass this problem completely. It only requires a small modification to the built-in shaders: instead of grabbing color from the color buffer, grab it from mesh vertices directly. This bypasses the use of texture buffers entirely and is likely to fix the problem.

Here's the original version of TransparentFluidSurface.subshader:
[Image: cDrGLv5.png]

Here's the change that's necessary in TransparentFluidSurface. During absorption, instead of sampling color from the texture buffer sample it from the vertex color. For thickness, use a constant value instead of the one read from the buffer:
[Image: mIejYrn.png]

kind regards,
Reply