13-05-2021, 07:43 AM
(This post was last modified: 13-05-2021, 07:57 AM by josemendez.)
(12-05-2021, 08:04 PM)DryGinStudios Wrote: 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
Quote: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.
(12-05-2021, 08:04 PM)DryGinStudios Wrote: 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).
(12-05-2021, 08:04 PM)DryGinStudios Wrote: 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 .