Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Bug / Crash  Fluid renders in editor, not in build
#1
Exclamación 
We are using OBI on the standard render pipeline. Our water renders fine in-editor, but when built is invisible. There are no shader or burst related errors in the player log. I've also disabled all shader stripping.

Does anyone know why water would render in the editor but not a build, besides shader stripping?

I've tried reaching out to the OBI team about this, but their mailer is blocking me as spam with the following error:
Code:
mail-node.dondominio.com gave this error:
Decision Engine classified the mail item was rejected because of IP Block (from outbound normal IP pools) -> 554 5.7.1 Service unavailable; Client host [40.107.236.120] blocked using bl.spamcop.net;

We had been talking, but after a few E-mails back and forth they started rejecting my E-mails as spam.
Reply
#2
(17-05-2024, 02:37 AM)Terabytetim Wrote: I've tried reaching out to the OBI team about this, but their mailer is blocking me as spam with the following error:
Code:
mail-node.dondominio.com gave this error:
Decision Engine classified the mail item was rejected because of IP Block (from outbound normal IP pools) -> 554 5.7.1 Service unavailable; Client host [40.107.236.120] blocked using bl.spamcop.net;
We had been talking, but after a few E-mails back and forth they started rejecting my E-mails as spam.

Hi!

Sorry about this! Which email account did you use to contact us regarding this error? That way I can check our previous conversation and get up to speed regarding this issue.

(17-05-2024, 02:37 AM)Terabytetim Wrote: We are using OBI on the standard render pipeline. Our water renders fine in-editor, but when built is invisible. There are no shader or burst related errors in the player log. I've also disabled all shader stripping.
Does anyone know why water would render in the editor but not a build, besides shader stripping?

- Is it only fluid rendering that's failing, or both simulation and rendering? If you enable the "render" checkbox in ObiParticleRenderer, do particles appear in the build?
- What platform are you building for? Also, which solver backend are you using (Burst or Oni)?

I ask these questions because you mentioned there's no errors in the console, if any of the shaders used for fluid rendering were missing or not properly compiling for your platform, the console/logs should contain the following error : "Obi Fluid Renderer not supported in this platform."

If this is not the case, it sounds like the entire physics backend is either missing or unsupported. This is usually the case with Oni, since it has much more limited platform support than Burst.

kind regards,
Reply
#3
Thank you for the quick reply! We're trying to wrap up this project, and only just now noticed this error in builds.


Quote:Sorry about this! Which email account did you use to contact us regarding this error?


tim.williams@binteractive.com - although our original discussion was about rendering issues in the URP and issues getting our simulation working well. We eventually switched to the Standard render pipeline, which allowed us to render the water the way we wanted.


Quote:Is it only fluid rendering that's failing, or both simulation and rendering? If you enable the "render" checkbox in ObiParticleRenderer, do particles appear in the build?


Only the rendering is failing; Enabling that checkbox, I see balls falling where I'd expect water to be. Disabling it, no water is seen.


Quote:What platform are you building for? Also, which solver backend are you using (Burst or Oni)?


Windows, and Burst.


Quote:I ask these questions because you mentioned there's no errors in the console, if any of the shaders used for fluid rendering were missing or not properly compiling for your platform, the console/logs should contain the following error : "Obi Fluid Renderer not supported in this platform."


I am not seeing this or any other errors in the built player log. I've disabled shader stripping in the project, and even added every single shader file I could find used by Obi to the "Always Included" list.

A bit stumped at this point, I thought it might be Burst but have confirmed that's building with the player.
Reply
#4
(17-05-2024, 08:00 AM)josemendez Wrote: Hi!

Sorry about this! Which email account did you use to contact us regarding this error? That way I can check our previous conversation and get up to speed regarding this issue.


- Is it only fluid rendering that's failing, or both simulation and rendering? If you enable the "render" checkbox in ObiParticleRenderer, do particles appear in the build?
- What platform are you building for? Also, which solver backend are you using (Burst or Oni)?

I ask these questions because you mentioned there's no errors in the console, if any of the shaders used for fluid rendering were missing or not properly compiling for your platform, the console/logs should contain the following error : "Obi Fluid Renderer not supported in this platform."

If this is not the case, it sounds like the entire physics backend is either missing or unsupported. This is usually the case with Oni, since it has much more limited platform support than Burst.

kind regards,

Any thoughts on this? We are still unable to build our game for testing
Reply
#5
Hi!

So it seems that simulation is indeed working - and only rendering fails - since you're able to see the fluid particles in the build. I've tried building for Windows and didn't have any issues regarding rendering (never had any similar reports either) so this must be something specific to your project.

Would it be possible for you to share a project that exhibits this issue, by sending it to support(at)virtualmethodstudio.com? This way we can diagnose it and solve the problem faster.

kind regards,
Reply
#6
(21-05-2024, 07:47 AM)josemendez Wrote: Hi!

So it seems that simulation is indeed working - and only rendering fails - since you're able to see the fluid particles in the build. I've tried building for Windows and didn't have any issues regarding rendering (never had any similar reports either) so this must be something specific to your project.

Would it be possible for you to share a project that exhibits this issue, by sending it to support(at)virtualmethodstudio.com? This way we can diagnose it and solve the problem faster.

kind regards,

I have packaged and sent a project with this issue to that address, thank you
Reply
#7
(21-05-2024, 06:32 PM)Terabytetim Wrote: I have packaged and sent a project with this issue to that address, thank you

Hi,

Just letting you know we just answered your email. Let me know if we can be of further help.

kind regards,
Reply
#8
(22-05-2024, 08:57 AM)josemendez Wrote: Hi,

Just letting you know we just answered your email. Let me know if we can be of further help.

kind regards,

Thank you! I will try your suggested fix and reply later today
Reply
#9
(22-05-2024, 08:57 AM)josemendez Wrote: Hi,

Just letting you know we just answered your email. Let me know if we can be of further help.

kind regards,

Hi, I have lost the ability to communicate with the support team again. I'm getting the same message mentioned in my OP about being suspected of spam. Here is the message and attachments I was trying to send

Thank you for the quick response,

Quote:For 2D collisions to work, solvers must be at Z = 0

Ah!! I did not see that Z = 0 requirement in the docs. This fixes 2D collisions.
Quote:The underlying collision detection pipeline is the exact same, so is the math used for collision response.
Thanks for the info, I was unaware of this. I’ll keep the 3D colliders then, they work well.

Quote:Does your profiling data point to collisions as a bottleneck?

I initially thought so, but upon disabling most colliders I’m still seeing performance drops; I need to address issues with my blueprint/scene setup.
 
If you don’t mind looking, I’ve attached images of my settings and a CPU profiler sample in timeline mode. This was with only 10 colliders in the scene. You can also find the profiler data export here: https://www.dropbox.com/scl/fi/5hqyh465o...0ygow&dl=1
 
I’m targeting 30FPS on Windows PC. The scene is 2D, except for a 3D car. The game starts running at 42FPS, but often after a few seconds slows to 10-20FPS. Though strangely it sometimes maintains 42FPS the entire game. In the profiler data export, you can see the game starts off rendering decently, then drops significantly in FPS midway through.
 
Besides lowering my blueprint resolution, are there any settings I could change to improve performance?
 
Main reason I’m avoiding a resolution change is my particles are already big on screen due to how close the camera is to the scene (9m from water)
 
Best,
Tim.
Reply
#10
Hi Tim,

The first thing that stands out in your profiler pic is that physics are being updated >6 times per frame (6 visible calls to FixedBehaviorUpdate). It typically is unnecessary to update physics more than once or twice.

This is likely because your maximum allowed timestep is too high, or your timestep too small, leading to a death spiraling situation where physics must be updated more than once per frame to catch up with rendering. Took a look at your project's Time manager , your fixed timestep is set to 0.005 and your max timestep to 0.33, this instructs Unity to update physics at most 0.33/0.005 = 66(!) times per frame leading to extreme performance drops. For reference, typical values for these parameters are max allowed timestep = 0.04 - 0.1, and fixed timestep = 0.01 - 0.02.

Regarding your fluid blueprint parameters, they don't make much sense either. Your atmospheric pressure is set to a negative value, which will try and force fluid particles to expand into the surrounding atmosphere as much as possible like a gas would - should be the exact opposite if you want a smooth fluid stream. Viscosity is set to 0 which allows particles to move completely independent from each other - not what you'd want for a smooth stream, where particles all move in roughly the same direction -. Vorticity is also non-zero, which will cause the fluid to swirl as much as possible instead of keeping an steady trajectory. I think your project compensates for these parameter choices by using a really small timestep, in an attempt to get a smooth stream of fluid despite most fluid parameters forcing otherwise.

Some values I'd suggest:

Time:
- Fixed Timestep = 0.01
- Max allowed timestep = 0.02

Blueprint:
- Smoothing = 2.5
- Viscosity = 0.2
- Buoyancy = -0.1
- Atmospheric drag = 0
- Amospheric pressure = 0
- Vorticity = 0

Emitter:
- Emitter speed = 1.2

As a side note, if you're profiling this in the editor (as opposed to a build) make sure that your Jobs Debugger, Safety Checks and Leak Detection are disabled (found in the Jobs menu) since it will very negatively affect performance. With the changes suggested above I'm getting around 250 fps in your scene, on a Windows 10 PC w/ Core i5 CPU.

kind regards,
Reply