Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Mobile performance
#7
(13-05-2021, 07:43 AM)josemendez Wrote: 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 Sonrisa.

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


Messages In This Thread
Mobile performance - by DryGinStudios - 12-05-2021, 04:05 PM
RE: Mobile performance - by josemendez - 12-05-2021, 04:55 PM
RE: Mobile performance - by DryGinStudios - 12-05-2021, 05:18 PM
RE: Mobile performance - by DryGinStudios - 12-05-2021, 08:04 PM
RE: Mobile performance - by josemendez - 13-05-2021, 07:43 AM
RE: Mobile performance - by DryGinStudios - 13-05-2021, 12:32 PM
RE: Mobile performance - by DryGinStudios - 12-05-2021, 09:10 PM
RE: Mobile performance - by DryGinStudios - 17-05-2021, 10:02 PM
RE: Mobile performance - by josemendez - 18-05-2021, 07:45 AM
RE: Mobile performance - by DryGinStudios - 18-05-2021, 02:52 PM
RE: Mobile performance - by josemendez - 18-05-2021, 02:54 PM
RE: Mobile performance - by DryGinStudios - 18-05-2021, 10:44 PM
RE: Mobile performance - by josemendez - 19-05-2021, 07:44 AM
RE: Mobile performance - by DryGinStudios - 19-05-2021, 04:49 PM
RE: Mobile performance - by josemendez - 20-05-2021, 07:43 AM
RE: Mobile performance - by DryGinStudios - 20-05-2021, 12:56 PM
RE: Mobile performance - by josemendez - 20-05-2021, 01:45 PM
RE: Mobile performance - by DryGinStudios - 20-05-2021, 03:56 PM
RE: Mobile performance - by josemendez - 20-05-2021, 08:53 PM