Help Does Obi Disregard Convex Mesh Colliders?

[virtushda]

It's my understanding that a convex mesh collider is considered non-hollow and much more performant than a standard mesh collider, at least inside PhysX.
Obi does not seem to care about that however...

I know about and love Obi's SDF colliders, but no support for non-uniform scaling is a huge deal-breaker for our use-case.

Setup: All convex and primitive colliders!


Results: Yes this setup works perfectly with SDF collision!

[josemendez]

It's my understanding that a convex mesh collider is considered non-hollow and much more performant than a standard mesh collider, at least inside PhysX.
Obi does not seem to care about that however...

I know about and love Obi's SDF colliders, but no support for non-uniform scaling is a huge deal-breaker for our use-case.

Setup: All convex and primitive colliders!


Results: Yes this setup works perfectly with SDF collision!

All MeshColliders are considered concave in Obi. The reason for this is that Unity's API does not expose any representation of convex mesh collider: no plane list, no point/edges, nothing. All we can work with is the original mesh.

[virtushda]

All MeshColliders are considered concave in Obi. The reason for this is that Unity's API does not expose any representation of convex mesh collider: no plane list, no point/edges, nothing. All we can work with is the original mesh.

Damn.
Are there any plans to add non-uniform scaling support to SDF colliders?

Thanks either way!

[josemendez]

Damn.
Are there any plans to add non-uniform scaling support to SDF colliders?

Thanks either way!

It's a shame, but non-uniform scaling won't ever work with distance fields due to their very nature: they precalculate the distance between all points in the bounding box of an object, and the surface of an object. Essentially, the length of a lot of lines.

So imagine a line of length 10: if you scale the line uniformly in all axes by 50%, it's safe to say its length is also scaled by 50%: 5 instead of 10.
However, if you scale the line 50% in one axis, but only 25% in the other two axes, the above no longer holds true: there's no clear way to determine what the line length is, except for re-calculating it from scratch which completely defeats the purpose of distance fields. 

[virtushda]

Thanks for the explanation, that makes sense.

Just going out on a limb here, but would it be too costly to essentially transform particles into non-scaled SDF space and then back?

[josemendez]

Thanks for the explanation, that makes sense.

Just going out on a limb here, but would it be too costly to essentially transform particles into non-scaled SDF space and then back?

This is already being done for all colliders, since contacts must be generated with both collider data and particle data on the same space, and multiple colliders might collide with different solvers (thus different spaces). So particle data is transformed from solver space to collider space when generating contacts, then all contacts are transformed back to solver space.

Thing is, distance between points is invariant under rotation and translation, but not under scale. So even when transforming into SDF space, the distances we read back from the SDF are all wrong, because they were pre-calculated from a non-scaled mesh and then stored. For uniform scale values, we can scale the value stored in the SDF, but this trick does not work for non-uniform scale.

A transform that preserves distance between points is called a rigid transform. If you've ever used the Unity.Mathematics package, you will see there's a RigidTransform struct that only contains rotation and translation, no scaling (for this very reason: https://docs.unity3d.com/Packages/com.un...sform.html). Once you throw scaling into the mix, you get an affine transform.

See: https://en.wikipedia.org/wiki/Rigid_transformation

[virtushda]

Makes sense, thanks for going more in-depth!

I'll only bug you with one last thing... 

If you decide to make Obi Convex Collider a thing at some point, there's an MIT-licensed library for convex hull generation that could save you a lot of time!
https://github.com/OskarSigvardsson/unity-quickhull

[josemendez]

Makes sense, thanks for going more in-depth!

I'll only bug you with one last thing... 

If you decide to make Obi Convex Collider a thing at some point, there's an MIT-licensed library for convex hull generation that could save you a lot of time!
https://github.com/OskarSigvardsson/unity-quickhull

Have tough of it before, same for PolygonCollider2D (the only colllider type not supported at all, basically due to the same reason...no API way to get Unity's triangulation). In 2D, I tried to do roll out my own triangulation algorithm (Delaunay) but the resulting triangulation was different from Unity's, and so the collision behavior was different at edges due to speculative collision ghost contacts.

Long story short, I fear that my convex hull and Unity's end up not being exactly the same, and this will be perceived as a bug. Will experiment with it some more though, as convex shapes can be made solid, so they are much more robust than concave ones without the memory consumption and limitations of a distance field. Thanks for the link!