(18-05-2021, 02:52 PM)DryGinStudios Wrote: Ok I did that and won some FPS.. still, it goes a bit too low... anything else I can do?

(18-05-2021, 02:54 PM)josemendez Wrote: You could try using a larger timestep too, eg 0.03. Then set the max fixed timestep to 0.06 to limit Unity to 2 physics updates per frame.

Assuming you're using the Burst backend, and that the bottleneck is indeed the simulation (FixedUpdate) not much else can be done. Maybe use less density iterations, less substeps, etc. until performance  is acceptable without quality suffering too much. Fluid simulation is really expensive, so it won't perform well in lower-end devices in general.

(18-05-2021, 02:54 PM)josemendez Wrote: You could try using a larger timestep too, eg 0.03. Then set the max fixed timestep to 0.06 to limit Unity to 2 physics updates per frame.

Assuming you're using the Burst backend, and that the bottleneck is indeed the simulation (FixedUpdate) not much else can be done. Maybe use less density iterations, less substeps, etc. until performance  is acceptable without quality suffering too much. Fluid simulation is really expensive, so it won't perform well in lower-end devices in general.

(18-05-2021, 10:44 PM)DryGinStudios Wrote: Is there a way to make the liquid move faster? whatever speed value I change, it doesn't seem to impact the speed of the liquid.

(18-05-2021, 10:44 PM)DryGinStudios Wrote: What's are the option I need to check to gain performance? I don't see in the documentation an IMPACT on performance on option. You tell me density iterations less substeps... I don't know where are those options. Density iterations are in the material?

(18-05-2021, 10:44 PM)DryGinStudios Wrote: Does Constraints have an impact on performance?

(18-05-2021, 10:44 PM)DryGinStudios Wrote: Is there a guide somewhere like... where to start on performance and each option with their cost so I can try to tweak everything! Would be awesome.

(19-05-2021, 07:44 AM)josemendez Wrote: There isn't any physical attribute (mass, density, etc) that you can change to make an object "move faster", in absence of external forces/accelerations. Not fluids, not any other body (eg. rigidbodies). Unless a external agent changes their velocity, all objects will keep moving with whatever velocity they currently have. This is a fundamental law of physics, and applies to all physics engines: if you create a sphere in Unity, there's no parameter that will let you control how fast it rolls down an inclined plane for instance.

You can always change the velocity of individual fluid particles, using the particle API:
http://obi.virtualmethodstudio.com/tutorials/scriptingparticles.html

You can also change Unity's timescale to a value > 1, for a "fastforward" effect to all physics in your game.


Timestep and iterations control quality vs performance in all existing physics engines, Obi is no exception. The manual's introduction section contains an in-depth explanation of the impact these have in the simulation:
http://obi.virtualmethodstudio.com/tutorials/convergence.html

Timestep size: there's two ways to change the timestep size: changing Unity's fixed timestep value (found in ProjectSettings->Time, this will affect all physics in your scene), or by using more substeps in Obi (found in the ObiFixedUpdater component, this will only affect Obi). Using more substeps will chop up the fixed timestep into a number of smaller "substeps", resulting in a smaller effective timestep size.

Iterations: can be changed in the ObiSolver component. You can individually tweak the amount of iterations spent on each constraint type, see:
http://obi.virtualmethodstudio.com/tutorials/obisolver.html

In Unity's physics engine you can also adjust the amount of iterations, you can find them in the physics manager: https://docs.unity3d.com/Manual/class-PhysicsManager.html. However it only differentiates between position and velocity iterations, so it doesn't give you nearly as much control as Obi does.

Note that time stepping and iterations are basic simulation concepts, that you should already be familiar with if using an advanced engine such as Obi. They are the foundation on which all physics engines are built, you can find lots of online resources regarding this: https://www.reddit.com/r/Unity3D/comments/g8dsgn/fixed_timestep_and_velocityposition_iterations/


Constraints are the main performance bottleneck in any physics engine. The more constraints are there in the scene, and the more time the engine spends enforcing them, the costlier the simulation. For instance, if you have 1000 rigidbodies colliding with each other in Unity (each contact between 2 bodies is a constraint), the simulation will be much more expensive than having 1000 rigidbodies that don't collide at all. Also, using 6 iterations means the engine will go over all constraints 6 times per timestep, which is more expensive than iterating 5, 4, 3... times.


All of this is common to all physics engines. The manual does not aggregate every performance-sensitive parameter in a single place, however when a parameter affects performance, the manual explains what the tradeoff is. Keep in mind that timestep size and iterations are the most important ones.

(19-05-2021, 04:49 PM)DryGinStudios Wrote: Ok, thanks for all the information! I'm tweaking performance and I continue my prototype. I got one quick question. I'm trying to put textMeshPro over the liquid and it's not working.How can I put textmeshpro over the liquid? Thanks!

(19-05-2021, 04:49 PM)DryGinStudios Wrote: I even tried 2 camera but the liquid is draw on both camera even if I put NONE for culling mask.

(19-05-2021, 04:49 PM)DryGinStudios Wrote: Oh yeah last question (sorry I ask so many questions). I see in the maze example that we can check for OnCollision and I integrated it and it work but what I need is more a OnTriggerEnter and OnTriggerLeave to know how many of the liquid particles are in the zone. What is your suggestion for the best way of doing this?

(20-05-2021, 07:43 AM)josemendez Wrote: Hi!

Being transparent, fluids are renderer after all opaque objects. Then, the z-buffer is used to discard fragments that lie behind already rendered objects.

Whether an object is considered transparent or opaque, depends on the shader it is using. What material/shader are you using for your text?


Fluids are not an "independent" object so to speak, rendering is a full-screen post process. So they're unaffected by culling masks.


Enter/Leave events can be easily calculated from the raw list of contacts: If a contact appears in the list, but didn't appear last frame, it's an "Enter"event. Similarly, if a contact that appeared last frame does not appear in the current frame, it's an "Exit" event.

If a contact was there in the previous frame and is still there, it's an "Stay" event.

If you don't want to write your own, you can use the ObiContactEventDispatcher component for this: sorts the contact lists, and determines enter/exit/stay events in linear time. These are exposed as UnityEvents that you can subscribe to. You will find it at /Obi/Scripts/Common/Utils/ObiContactEventDispatcher.cs.

(20-05-2021, 12:56 PM)DryGinStudios Wrote: I'm using the standard shader that come with textmeshpro, I'm using even the overlay that is suppose to be over everything. Take note that it's working when using textMeshpro in a canvas. It's just working when using TextMeshPro as a 3d object whatever the shader I use.

(20-05-2021, 12:56 PM)DryGinStudios Wrote: As for the ObiContactEventDispatcher... I feel like it's going to be heavy on the CPU? I'm going to test it today! Is there an example in the fluid scenes that use it?

(20-05-2021, 01:45 PM)josemendez Wrote: Can't reproduce any issues with the built-in textmeshpro shader. It appears behind the fluid when behind it, and in front of it when in front:




What render pipeline are you using? (note that URP does not allow to mix transparent objects with fluid, due to a limitation in how URP renderer features work).
Also, what are your fluid renderer settings?


Depends on how many contacts per frame you have, but should be fairly light: its total cost is O(nlogn) on the amount of contacts, due to the sorting step.
No sample scenes use it, but it's very straightforward to use. Let me know if you need help.

(20-05-2021, 01:45 PM)josemendez Wrote: Can't reproduce any issues with the built-in textmeshpro shader. It appears behind the fluid when behind it, and in front of it when in front:




What render pipeline are you using? (note that URP does not allow to mix transparent objects with fluid, due to a limitation in how URP renderer features work).
Also, what are your fluid renderer settings?


Depends on how many contacts per frame you have, but should be fairly light: its total cost is O(nlogn) on the amount of contacts, due to the sorting step.
No sample scenes use it, but it's very straightforward to use. Let me know if you need help.

DryGinStudios Wrote: The enter even seems only to be on the first particles in a collider. The Stay even does seem to work but once again I don't have when one particle leave as the LEAVE event is only triggered when all particles leave the collider (or it seems to be.)

Quote:I can get how many enter and it works correctly with the maze example but I can't figure out when it leaves the BoxCollider2d. You said to use the raw data of contact but I can't find where this is. I could in an Update function check each contact from the raw list to check if the contact is with the collider but I can't find that list.