Help Simple and efficient way to make Obi Fluid rise/lower in a cylinder container

[zkkzkk32312]

Hello,

I am looking for some help to make a simple Oil Fluid project that are

-Contained in a cylinder container for its entire life (liquid in a tank)
-Has the ability to rise up and lower down (to the max height of the tank or to empty tank)
-Uses the less amount of resources because of the limited functionality required as listed above

So far I was able to use the burst mesh emitter to fill the tank when the scene start
but I am getting terrible FPS from the blueprint that I am using (this is my assumption, my blueprint's settings is the problem?)
240 fps vs 20 fps when the sovler is enabled vs disabled


josemendez if you can give me any hint it will be awsome.

thanks,
Zack

[josemendez]

Hi Zack,

Without knowing what your blueprint settings are, it's difficult to tell. Not only those affect performance, though. Solver settings and Time settings do too.

Edit: if you're using the Burst backend, also make sure you don't have the jobs debugger and other performance hogs enabled. See:
http://obi.virtualmethodstudio.com/tutor...kends.html

[zkkzkk32312]

i am using the Solver settings that are found in the "FluidViscosity" example scene.


for the blueprint it is also based on the "Viscous" blueprint. but I am tweaking the values for performance.


it has less resolution and less capacity which I think should be less taxing on resources?
but in the acutaly FluidViscosity scene I can still get over 100 fps, but in my custom cylinder scene im only getting about 25.


About the burst compiler and job system,
can it only be used for Obi in a project?
or is it a project wide change?
i have other component in the project that will not work with Burst and JobSystem so I don't know if I can use those.

[josemendez]

i am using the Solver settings that are found in the "FluidViscosity" example scene.


for the blueprint it is also based on the "Viscous" blueprint. but I am tweaking the values for performance.


it has less resolution and less capacity which I think should be less taxing on resources?
but in the acutaly FluidViscosity scene I can still get over 100 fps, but in my custom cylinder scene im only getting about 25.


About the burst compiler and job system,
can it only be used for Obi in a project?
or is it a project wide change?
i have other component in the project that will not work with Burst and JobSystem so I don't know if I can use those.

Are you using MeshColliders by any chance? They’re *very* expensive (as stated in Unity’s docs) and become even more expensive if many particles are in constant contact with them, or if their mesh is very dense.  Using distance fields is recommended instead.

There’s many other settings in the project that can affect performance, using the profiler will tell you what’s taking up most time. Once you know, it’s generally easy to figure out what needs adjusting.

Burst and jobs will be used for whatever requires them in your project. They’re not a project wide change. If only Obi makes use of them, they won’t be used anywhere else (but still, your project will contain Burst-compiled code nonetheless).

[zkkzkk32312]

hey,

yes I am using mesh colliders for the tank,
but its relatively low poly, only 150 verts and 98 tris.

so I tested it with Burst,
it starts with 20 fps but goes up to around 55 after a few seconds.
I shell keep tweaking the values on solver/blueprint.

do you have any suggestion on runtime particles adding/removing?

Zack

[josemendez]

hey,

yes I am using mesh colliders for the tank,
but its relatively low poly, only 150 verts and 98 tris.

so I tested it with Burst,
it starts with 20 fps but goes up to around 55 after a few seconds.
I shell keep tweaking the values on solver/blueprint.

do you have any suggestion on runtime particles adding/removing?

Zack

Hi, 

If your particles are big enough, each one might need to collide with many triangles in the mesh collider. This can quickly add up to thousands of contacts, even with relatively few particles. Distance fields guarantee only one contact per particle (just like primitive colliders) and are much more robust.

Tweaking things at random in hopes to improve performance is going to take a lot of time and effort. Use the profiler, it will tell you exactly what needs to be adjusted. If you need i can help you interpret your profiler data.

By default Burst uses asynchronous compilation, so the first few frames will be noticeably slower in editor. You can force synchronous compilation in the burst menu. See: http://obi.virtualmethodstudio.com/tutor...kends.html

You can’t add/remove particles at runtime unless they’re part of an emitter(*).That would cause runtime memory allocation and GC spikes, which are highly undesirable. For this reason, Obi always preallocates memory if possible, and avoids runtime allocation.

(*)Just call emitter.Emit() and emitter.KillParticle() when needed. These activate/deactivate existing particles in the emitter particle pool, no alloc.

[zkkzkk32312]

(*)Just call emitter.Emit() and emitter.KillParticle() when needed. These activate/deactivate existing particles in the emitter particle pool, no alloc.

Hey thanks for the info again Josemendez,

what would happen if the emitter is Burst/VoxelShape?
I am now thinking maybe Burst/VoxelShape emitter wouldn't work well with what I am after here.

the .Emit() and .KillParticle() makes sense to me if their emission is Steam.

is it possible to start the scene with Burst emission then change it to Stream after so I can use the .Emit() and .KillParticle() ?

Zack

[josemendez]

Hey thanks for the info again Josemendez,

what would happen if the emitter is Burst/VoxelShape?
I am now thinking maybe Burst/VoxelShape emitter wouldn't work well with what I am after here.
the .Emit() and .KillParticle() makes sense to me if their emission is Steam.

Would work the same as with as with Stream emission mode.

is it possible to start the scene with Burst emission then change it to Stream after so I can use the .Emit() and .KillParticle() ?

Zack

Yes, it's possible, but I'm not sure why you'd want to do that.