Mobile performance

[DryGinStudios]

So... created a new project, 2020.3.7f1 in URP. Added the obi fluid and tested on android the SimpleFluid scene. I got a galaxy s20 (very performant) and I had 15 fps. I added all the latest burst, job, mathematic.

I get to 30 fps when reducing the max dpi of the screen to 300.

I've built multiple games for android with physics (Dots Physics too) and I've never seen such bad performance so I'm sure something is wrong.

I read that the SimpleFluid was mobile optimized so how come I have 15 fps out of the box on one of the best cellphones on the market.

Is it normal? Is there something I don't understand?

Regards,

Paul-André

[josemendez]

So... created a new project, 2020.3.7f1 in URP. Added the obi fluid and tested on android the SimpleFluid scene. I got a galaxy s20 (very performant) and I had 15 fps. I added all the latest burst, job, mathematic.

I get to 30 fps when reducing the max dpi of the screen to 300.

I've built multiple games for android with physics (Dots Physics too) and I've never seen such bad performance so I'm sure something is wrong.

I read that the SimpleFluid was mobile optimized so how come I have 15 fps out of the box on one of the best cellphones on the market.

Is it normal? Is there something I don't understand?

Regards,

Paul-André

Hi,

Mobile devices are generally fill-rate limited. Modern mobile devices have very high-density screens, to make things worse. Fluid rendering is also extremely expensive, so combine all 3 and you get bad performance if rendering at full resolution.

You should use downsampling in the fluid renderer, as suggested in the manual (bottom part of this page:
http://obi.virtualmethodstudio.com/tutor...ering.html)

Also, if you’ve installed burst, jobs, etc make sure you’re using the Burst backend and that no warning appears in the ObiSolver component, telling you that it will fall back to Oni.

Let me know how it goes. Kind regards,

[DryGinStudios]

Hi,

Mobile devices are generally fill-rate limited. Modern mobile devices have very high-density screens, to make things worse. Fluid rendering is also extremely expensive, so combine all 3 and you get bad performance if rendering at full resolution.

You should use downsampling in the fluid renderer, as suggested in the manual (bottom part of this page:
http://obi.virtualmethodstudio.com/tutor...ering.html)

Also, if you’ve installed burst, jobs, etc make sure you’re using the Burst backend and that no warning appears in the ObiSolver component, telling you that it will fall back to Oni.

Let me know how it goes. Kind regards,

Everything is fine with the Burst and no warning is there (I had at first before installing all correct components). I tested FluidViscosity and I got 60 fps without problem with this one. My question was mostly as to why the scene SimpleFluid is supposed to be mobile-ready and on one of the best cellphones on the market, I got 15 fps... is that expected or I got a bad configuration somewhere? I'll get later today the downsampling and everything... Thank for any help.

[DryGinStudios]

Hi,

Mobile devices are generally fill-rate limited. Modern mobile devices have very high-density screens, to make things worse. Fluid rendering is also extremely expensive, so combine all 3 and you get bad performance if rendering at full resolution.

You should use downsampling in the fluid renderer, as suggested in the manual (bottom part of this page:
http://obi.virtualmethodstudio.com/tutor...ering.html)

Also, if you’ve installed burst, jobs, etc make sure you’re using the Burst backend and that no warning appears in the ObiSolver component, telling you that it will fall back to Oni.

Let me know how it goes. Kind regards,

Ok so... after further investigation, I modified the fluid rendering and removed the reconstruction and I get 60 fps in the simple fluid example... so it was a configuration issue! I was almost sure but couldn't figure out where... It took me some time to figure out because I'm using URP, changing on the camera the fluid renderer was doing nothing LOL. Now... What do you think would be the best settings , in the simpleFuid scene, it makes it look like PAINT...? I'm prototyping ideas and I need the BEST performance too so any clever idea about how to make the performance even better than removing deconstruction is welcome. Are you looking about putting the physics into DOTS physics? I did that in one of my engines and the performance gain was massive.

[DryGinStudios]

When I use only Surface Reconstruction, the liquid because invisible. It becomes visible back only if I remove the TestEnvironment.

Any idea?

[josemendez]

Ok so... after further investigation, I modified the fluid rendering and removed the reconstruction and I get 60 fps in the simple fluid example... so it was a configuration issue! I was almost sure but couldn't figure out where... It took me some time to figure out because I'm using URP, changing on the camera the fluid renderer was doing nothing LOL.

Hi,

The ObiFluidRenderer component in the camera is only used in built-in pipeline.  Quoting the manual:
http://obi.virtualmethodstudio.com/tutor...ering.html

Setting up fluid rendering is done in a slightly different way depending on which scriptable render pipeline you're using:

Built-in
Add a ObiFluidRenderer component to each camera you need to be able to render fluid.
Universal (URP)
Add a ObiFluidRendererFeature to your pipeline's renderer feature list.

ObiFluidRenderer is not needed or used in URP (since URP uses RendererFeatures), so it has no effect on rendering. Note all sample scenes are built for the built-in pipeline, URP is opt-in.

Now... What do you think would be the best settings , in the simpleFuid scene, it makes it look like PAINT...? I'm prototyping ideas and I need the BEST performance too so any clever idea about how to make the performance even better than removing deconstruction is welcome.

There's a lot of ways of improving performance. I'd start by profiling your game in the device, identify what's taking up most time, and focusing on that. Might be rendering, might be simulation. In mobile devices rendering is usually the bottleneck due to their lack of fillrate, but once that's sorted out, simulation will eventually begin to be the new bottleneck, and susceptible of optimization.

With surface reconstruction disabled, you will lose lighting since there's no surface normals to use in lighting. This is generally used for simple 2D unlit fluid, with a variety of blending modes (additive, multiplicative or alpha blended). Your best bet for a paint-like look without surface reconstruction is to use alpha blending and enable writing to the z-buffer (tick the "particle z-write" checkbox in the renderer).

Are you looking about putting the physics into DOTS physics? I did that in one of my engines and the performance gain was massive.

We are already using Jobs, Burst, and SoA memory layout, the same technology used by DOTS physics. Even before that existed, we used a custom multithreaded/vectorized engine written in C++ (the "Oni" backend). Fluid simulation is orders of magnitude more expensive than rigidbody simulation, running single-threaded or having no vectorization is simply not an option.

Think that a small amount of 3D fluid requires 1000-1500 particles, most of them interacting with around 40-80 particles in their neighborhood, and that all these interactions are evaluated several times per frame (as many as substeps*iterations). Best-case scenario math using 4 substeps, 1 iteration (the default): 1000*40*4 = 160000 constraint evaluations per frame. On top of that you have to add anisotropy calculations to find particle shapes, which involves a matrix SVD (singular value decomposition) per-particle, and then rendering. Simply can't be done without DOTS .

[DryGinStudios]

Hi,

The ObiFluidRenderer component in the camera is only used in built-in pipeline.  Quoting the manual:
http://obi.virtualmethodstudio.com/tutor...ering.html


ObiFluidRenderer is not needed or used in URP (since URP uses RendererFeatures), so it has no effect on rendering. Note all sample scenes are built for the built-in pipeline, URP is opt-in.


There's a lot of ways of improving performance. I'd start by profiling your game in the device, identify what's taking up most time, and focusing on that. Might be rendering, might be simulation. In mobile devices rendering is usually the bottleneck due to their lack of fillrate, but once that's sorted out, simulation will eventually begin to be the new bottleneck, and susceptible of optimization.

With surface reconstruction disabled, you will lose lighting since there's no surface normals to use in lighting. This is generally used for simple 2D unlit fluid, with a variety of blending modes (additive, multiplicative or alpha blended). Your best bet for a paint-like look without surface reconstruction is to use alpha blending and enable writing to the z-buffer (tick the "particle z-write" checkbox in the renderer).


We are already using Jobs, Burst, and SoA memory layout, the same technology used by DOTS physics. Even before that existed, we used a custom multithreaded/vectorized engine written in C++ (the "Oni" backend). Fluid simulation is orders of magnitude more expensive than rigidbody simulation, running single-threaded or having no vectorization is simply not an option.

Think that a small amount of 3D fluid requires 1000-1500 particles, most of them interacting with around 40-80 particles in their neighborhood, and that all these interactions are evaluated several times per frame (as many as substeps*iterations). Best-case scenario math using 4 substeps, 1 iteration (the default): 1000*40*4 = 160000 constraint evaluations per frame. On top of that you have to add anisotropy calculations to find particle shapes, which involves a matrix SVD (singular value decomposition) per-particle, and then rendering. Simply can't be done without DOTS .

Thanks for the answer! I'll continue my investigation and testing and I'll get back to you

[DryGinStudios]

So I tested more with my ideas and I do have 60 fps for my testing on my good cell, but I have really bad performance on an older device. I have no reconstruction and I'm not sure where to check to get better performance now.

Rendering isn't a problem. When profiling, it seems to be in ObiFixedUpdater.FixedUpdate.

Any ideas?

[josemendez]

So I tested more with my ideas and I do have 60 fps for my testing on my good cell, but I have really bad performance on an older device. I have no reconstruction and I'm not sure where to check to get better performance now.

Rendering isn't a problem. When profiling, it seems to be in ObiFixedUpdater.FixedUpdate.

Any ideas?

Hi,

How many times does FixedUpdate get called per frame? ("Calls" column in the profiler, hierarchy mode). If it's getting called more than once, this is a symptom of death spiralling.

This is an issue that affects all engines that use a fixed timestepping scheme, like Unity. It happens when the device can't update physics fast enough to keep up with wall-clock time.

Quick fix is to reduce Unity's max fixed timestep to a value that' a small multiple of the timestep. Eg, if you're using a timestep of 0.02, use a max fixed timestep of 0.04 or 0.06.

[DryGinStudios]

Hi,

How many times does FixedUpdate get called per frame? ("Calls" column in the profiler, hierarchy mode). If it's getting called more than once, this is a symptom of death spiralling.

This is an issue that affects all engines that use a fixed timestepping scheme, like Unity. It happens when the device can't update physics fast enough to keep up with wall-clock time.

Quick fix is to reduce Unity's max fixed timestep to a value that' a small multiple of the timestep. Eg, if you're using a timestep of 0.02, use a max fixed timestep of 0.04 or 0.06.

Ok I did that and won some FPS.. still, it goes a bit too low... anything else I can do?