Help Fluids sucked into colliders

[Voolg]

Hi,

Here is a video illustrating the issue: https://youtu.be/37qQ8HVPaqs

The two cubes have a simple script controlling their rigidbody's velocity. If there is some fluid on top of them, and you can see that it get sucked into the cubes' colliders as the cubes gain velocity (despite not moving since they already touch the ground).

This is a simplified example, my real case scenario is that I have fluid in a container moved by the player (using RB velocity only). But when I place the container on a surface (with still some velocity as it is still grabbed by the player), suddenly all the fluid clips through the colliders because of the exact situation illustrated above in the video.

Please note that I took care of changing the rigidbody velocity only, and that a closed container can shake extremely hard without having any fluid tunneling. The issue only occurs when the container touches another collider.

Some additional notes:
- Weirdly enough, when I copy pasted the example above (video) in a new blank scene with only the essential items, I didn't get the issue. But after reloading the new scene, the clipping appeared again against *some* cubes, not all. Despite being exact duplicates.
- I tried in some Obi example scenes (in another, clean project) and got the same issue (eg raclette or viscosity: added RB moving script and set the RB to non kinematic, more mass and no gravity)
- I am in URP

[josemendez]

Hi,

Here is a video illustrating the issue: https://youtu.be/37qQ8HVPaqs

The two cubes have a simple script controlling their rigidbody's velocity. If there is some fluid on top of them, and you can see that it get sucked into the cubes' colliders as the cubes gain velocity (despite not moving since they already touch the ground).

This is a simplified example, my real case scenario is that I have fluid in a container moved by the player (using RB velocity only). But when I place the container on a surface (with still some velocity as it is still grabbed by the player), suddenly all the fluid clips through the colliders because of the exact situation illustrated above in the video.

Please note that I took care of changing the rigidbody velocity only, and that a closed container can shake extremely hard without having any fluid tunneling. The issue only occurs when the container touches another collider.

Some additional notes:
- Weirdly enough, when I copy pasted the example above (video) in a new blank scene with only the essential items, I didn't get the issue. But after reloading the new scene, the clipping appeared again against *some* cubes, not all. Despite being exact duplicates.
- I tried in some Obi example scenes (in another, clean project) and got the same issue (eg raclette or viscosity: added RB moving script and set the RB to non kinematic, more mass and no gravity)
- I am in URP

Velocity in Obi (and most physics engines) is interpreted as a sort of "oracle" that can be used to tell where an object is going to be at the start of the next simulation frame. This is used during collision detection to accurately predict object movement and calculate collisions accordingly.

If an object has non-zero velocity but ends up behaving as if it effectively had zero velocity (that is, not moving at all), Obi will be misled into believing the object will move when it actually won't. In the video, the fluid behaves as if the cubes were falling since their velocity in the Y axis is negative. Doesn't make any sense for an object to have falling velocity if it's not actually falling.

Under normal circumstances there should be no situation in which a rigidbody has non-zero velocity at the end of a simulation step but doesn't move during the next step, regardless of it being kinematic or non-kinematic:

- A kinematic rigidbody in Obi calculates its velocity as (currentPos - previousPos)/timeDelta. So if it hasn't changed its position during a frame, its velocity is guaranteed to be zero. 
- A non-kinematic rigidbody is moved by the physics engine to the position dictated by its velocity, and velocity is adjusted during the simulation as a result of collision response. So if an object is resting on top of a static collider, its relative velocity towards that collider is also guaranteed to be zero.

If you're forcing the velocity of a rigidbody to a custom value, you must do it in a way that's consistent with Obi's update cycle. Otherwise results will vary, specially since the order in which Unity calls FixedUpdate() -and all other callbacks- for different objects is undefined and may change for different runs of the same scene. This explains why it happens for some objects but not others, and happens in some scenes upon reloading them: depending on whether the ObiSolver's FixedUpdate is called before or after your object's FixedUpdate(), a variety of things can happen.

Obi exposes many callback events that you can use to run code at certain points of the simulation of a specific solver:
http://obi.virtualmethodstudio.com/manua...olver.html

You may also explicitly set script execution order to ensure velocities are updated correctly.

kind regards,

[Voolg]

Thank you for the detailed explanation, I appreciate. Using AddForce is more tricky but it seems to solve the problem.

It also seems that closing a container makes the particles inside very likely to clip through if the container falls on the ground, somehow, as opposed to having the upper side left open (like a bowl).

I am now trying to let the player move any container fast without having anything spilling around (which I know is not a realistic behavior). I am not asking anyone to solve things for me, but if you have any kind of tip or suggestion it would be very welcome, as I fail to make any progress on this so far. Translating the position of particles inside the container (a bowl) by updating their position doesn't work well for example.

---

Maybe there is a way to force particles being "kinematic" for example? I think I fail to properly control them manually because physic forces continue to be applied at the same time.