Say I want to make a physics bowl containing some fluid that you can stir. I would make a bowl model, and then create a bunch of box colliders roughly tracing the shape of he the bowl since Unity only supports convex colliders for rigidbody physics.
Obi doesn't have any problems with concave colliders, looks like the convex check box on the referenced mesh collider is just ignored by the obi collider that uses it. But I still can't have my concave bowl because Obi seems to require an enabled, non-trigger Unity collider component to work. That means any mesh collider on the bowl will also inevitably affect the regular rigidbody physics, and the rigidbody will always be forced to use a convex version of the mesh collider that obi uses.
Am I missing something or is there no way to have a concave rigidbody that interacts with obi particles?
(17-03-2022, 03:43 PM)locque Wrote: [ -> ]Say I want to make a physics bowl containing some fluid that you can stir. I would make a bowl model, and then create a bunch of box colliders roughly tracing the shape of he the bowl since Unity only supports convex colliders for rigidbody physics.
Obi doesn't have any problems with concave colliders, looks like the convex check box on the referenced mesh collider is just ignored by the obi collider that uses it. But I still can't have my concave bowl because Obi seems to require an enabled, non-trigger Unity collider component to work. That means any mesh collider on the bowl will also inevitably affect the regular rigidbody physics, and the rigidbody will always be forced to use a convex version of the mesh collider that obi uses.
Am I missing something or is there no way to have a concave rigidbody that interacts with obi particles?
Hi!
Not sure I understand your use case: Unity simply does not support non-kinematic concave MeshColliders, however Obi does.
So in the case of a bowl, Obi will use its original, concave mesh to collide against even if Unity isn’t capable of doing that. That’s why convex MeshColliders are regarded concave in Obi.
You can approximate your bowl with boxes or any other primitive so both Unity and Obi can regard it as concave. Or, use a distance field if you want Obi to use a more accurate representation of it instead of a bunch of boxes.
Also, in case you want a collider to affect particles only:
remember that Unity’s and Obi’s collision filtering/layer systems are separate: you can make a Unity collider ignore other colliders, but still have particles collide against it if that’s what you want.
Quote:Also, in case you want a collider to affect particles only:
remember that Unity’s and Obi’s collision filtering/layers system are separate: you can make a Unity collider ignore other colliders, but still have particles collide against it if that’s what you want.
I'm afraid that does not work, that's the first thing I thought about too.
The layer is per gameobject, not per collider. And I would need to have one collider on the layer that interacts with the world and another one on a layer that doesn't on the same gameobject that the unity rigidbody is on. I can't create a child object for the obi collider either since the obi rigidbody needs to be on the same gameobject as the unity rigidbody, otherwise it will just create an additional unity rigidbody for itself on the child object.
I would like to try the distance field approach, but I can't get anything generated from my own meshes. I read the manual page for distance fields and made sure there are no holes in my mesh, but the generator still doesn't output anything for it. Also tried to set the import settings according to the sample bowl model with enabled read/write and legacy unweighted normals, but still nothing.
(17-03-2022, 04:13 PM)locque Wrote: [ -> ]I would like to try the distance field approach, but I can't get anything generated from my own meshes. I read the manual page for distance fields and made sure there are no holes in my mesh, but the generator still doesn't output anything for it. Also tried to set the import settings according to the sample bowl model with enabled read/write and legacy unweighted normals, but still nothing.
https://imgur.com/a/BBNohI1
Okay so the generation technically does work, but for an object the size of a bowl you have to turn down the max error to the absolute minimum to even be able to see a slight smear of something in the preview window. Also turning up max depth produces something that physically resembles the bowl, but is too broken to collide with any fluid at all. Changing the size is not really an option either since I have to work with real world units.
I suppose distance field is not the way to go, but I can't find a solution for the mesh collider either. Approximating this rounded shape with box colliders is off the table too, particles always find their way through the cracks or get stuck on slightly overlapping corners or edges.
(17-03-2022, 04:13 PM)locque Wrote: [ -> ]I'm afraid that does not work, that's the first thing I thought about too.
The layer is per gameobject, not per collider. And I would need to have one collider on the layer that interacts with the world and another one on a layer that doesn't on the same gameobject that the unity rigidbody is on. I can't create a child object for the obi collider either since the obi rigidbody needs to be on the same gameobject as the unity rigidbody, otherwise it will just create an additional unity rigidbody for itself on the child object.
Can’t you just have two gameobjects, each with their respective collider component and the rigidbody as their parent? This is functionally identical to having two colliders and a rigidbody on the same object. Colliders always work with the first rigidbody they find up their hierarchy.
Obi’s components are just wrappers over Unity’s own components, and work the exact same way: if you add a ObiCollider component to a collider, a ObiRigidbody will automatically be added to the first rigidbody up its hierarchy.
Tbh i’ve never seen a use case limited by the fact that layers are per-object and not per-component, that’s why I ask.
(17-03-2022, 06:26 PM)locque Wrote: [ -> ]https://imgur.com/a/BBNohI1
Okay so the generation technically does work, but for an object the size of a bowl you have to turn down the max error to the absolute minimum to even be able to see a slight smear of something in the preview window. Also turning up max depth produces something that physically resembles the bowl, but is too broken to collide with any fluid at all. Changing the size is not really an option either since I have to work with real world units.
The max error is expressed in mesh space, so if your mesh is very small, the error should be accordingly small too. For instance if your mesh is 10 cm in size and the maximum error is 1cm, that means that you’re ok with 10% distance error which is huge.
That preview looks fine to me. Could you define “broken” in this context? Distance fields are generally fairly robust.
(17-03-2022, 06:39 PM)josemendez Wrote: [ -> ]Can’t you just have two gameobjects, each with their respective collider component and the rigidbody as their parent? This is functionally identical to having two colliders and a rigidbody on the same object. Colliders always work with the first rigidbody they find up their hierarchy.
Obi’s components are just wrappers over Unity’s own components, and work the exact same way: if you add a ObiCollider component to a collider, a ObiRigidbody will automatically be added to the first rigidbody up its hierarchy.
Tbh i’ve never seen a use case limited by the fact that layers are per-object and not per-component, that’s why I ask.
Okay I managed to solve it for now, I guess you can have the obi collider on a child object of the rigidbody. I assumed this would'nt work because last time I tried that it automatically added an obi rigidbody and Unity rigidbody along with it. Maybe I misclicked and created an obi rigidbody instead of an obi collider.
Thanks for your help once again!
(17-03-2022, 06:46 PM)josemendez Wrote: [ -> ]The max error is expressed in mesh space, so if your mesh is very small, the error should be accordingly small too. For instance if your mesh is 10 cm in size and the maximum error is 1cm, that means that you’re ok with 10% distance error which is huge.
That preview looks fine to me. Could you define “broken” in this context? Distance fields are generally fairly robust.
Broken as in no collision with particles at all, as if there was no collider.
Do distance fields work for moving objects / rigidbodies? I didn't see anything about that in the manual, and the samples only ever use them for static environment models.
(17-03-2022, 06:50 PM)locque Wrote: [ -> ]Broken as in no collision with particles at all, as if there was no collider.
Do distance fields work for moving objects / rigidbodies? I didn't see anything about that in the manual, and the samples only ever use them for static environment models.
Distance fields work fine for moving objects/rigidbodies too. The only limitation is that they cannot be non-uniformly scaled (scale must be the same on all 3 axis). Otherwise they should work fine! In many cases they’re preferred to MeshColliders as they’re more robust and considerably cheaper.
If you can share the bowl mesh you’re using I’ll be glad to take a closer look.
Cheers,
(17-03-2022, 07:01 PM)josemendez Wrote: [ -> ]Distance fields work fine for moving objects/rigidbodies too. The only limitation is that they cannot be non-uniformly scaled (scale must be the same on all 3 axis). Otherwise they should work fine! In many cases they’re preferred to MeshColliders as they’re more robust and considerably cheaper.
If you can share the bowl mesh you’re using I’ll be glad to take a closer look.
Cheers,
Here's the mesh:
https://skfb.ly/otAMw
Would be great if there was a way to use the distance field, turns out my VR framework automatically assigns a layer to the the children of all gameobjects you can interact with, including the obi collider which I set to a layer that doesn't collide with anything. Fixable, but would be nice if there was an easier solution for separating unity and obi collisions on rigidbodies.
(17-03-2022, 07:11 PM)locque Wrote: [ -> ]Here's the mesh: https://skfb.ly/otAMw
Would be great if there was a way to use the distance field, turns out my VR framework automatically assigns a layer to the the children of all gameobjects you can interact with, including the obi collider which I set to a layer that doesn't collide with anything. Fixable, but would be nice if there was an easier solution for separating unity and obi collisions on rigidbodies.
Hi,
Tried out your mesh, I've recorded a video with my setup:
Things to watch out for:
- The distance field preview uses ray marching trough a (finite resolution) 3d texture, not the actual ASDF tree data. So it might not capture very thin features even though the distance field accounts for them. This is the case with the bowl's walls, they don't show up in the preview unless you use a extremely small error value. However the field will be accurate enough for collision detection way before these thin walls show up in the preview.
- Wall thickness: the bowl's walls are quite thin and at this tiny scale, it's easy to get tunneling. Slightly increasing the ObiCollider's
thickness value will offset the distance field a bit, enough to improve robustness.
- Relative mass:
If the fluid is much denser than the bowl, particles will go right trough it. I believe this is the issue in your case. All iterative physics engines have trouble with large mass ratios, and Unity's is no exception to this (try placing a 1000 kg rigidbody on top of a 1kg rigidbody to see what I mean). You can set the fluid's density in the emitter blueprint. The default is 1000 kg/m3, for a 1 kg bowl I used 10 kg/m3 which results in lighter fluid.
let me know if I can be of further help,