Remove the isHollow parameter from collider shapes

[aaronfranke]

The draft spec README currently has this isHollow boolean value:

However you can request the shapes to be created as a shell instead by enabling the isHollow parameter - in this case a rigid body inside the shape should collide with the inside of the shell.

I don't think that this is a helpful or desired feature.

• Hollow shapes can be created by using a trimesh collider shape. For example, if you want a hollow box in a glTF file, an asset creator can just create a trimesh collider shape using a box mesh.

• Most physics engines that I know of do not support hollow shapes directly. This property's existence complicates the implementation in those physics engines for not much of a benefit. In fact, it could be that many implementations choose to simply not implement isHollow, and then any glTF files using isHollow will not load correctly in those implementations.

• I don't believe the use case is very strong. I have never seen anyone desiring a hollow primitive collider shape. I don't have any market research to back this up, but I suspect that this will be a rarely used feature.

For all of the above reasons, I propose that isHollow be removed from the spec.

[eoineoineoin]

I think I agree with you here on removing the attribute; I don't see a lot of support for hollow shapes out there (and the USD Physics specification does not have a similar attribute)

For the record, though I think it is a useful feature; it allows you to confine a body to a particular region with a higher degree of control over the permitted range of motion than a joint offers.

As you've observed, even if a physics engine does not support hollow shapes, you can implement a similar effect by triangulating the collider and flipping the triangle normals. This can be done purely in the application which imports the glTF, when it talks to the physics engine.

So, I'd make the claim that a physics engine which doesn't support "hollow" shapes can easily approximate them, but you can't go the other direction. By forcing content creators to take similar steps when generating their assets, it comes with several downsides:

1. Extra work for the artist (maybe mitigated by tooling)
2. You've forced a discretization of the collider; spheres, cylinders and capsules will no longer be smooth.
3. The physics engine loses the ability to have optimized collision-detection routines, which will negatively impact performance. You can't have a "collider-versus-hollow-sphere" function; you need a "collider-versus-triangulated-mesh"

[aaronfranke]

Good points, I agree with your reasoning here. Having it as a dedicated feature that preserves smoothness and allows some physics engines to optimize it makes sense as an argument even though I oppose isHollow being in the standard.

This is the same reasoning that I 100% support the cylinder shape, even though many game engines don't support it and will need to approximate using a convex hull shape. However, cylinders are a very common and useful shape for many purposes, while hollow shapes is a much more niche feature. It makes sense to support cylinders but not hollow shapes because cylinders are much more common even though both features are things that some physics engines may not support directly and both can be approximated.

[eoineoineoin]

While I think this is a cool feature, which enables interesting use-cases, I think it's a comparatively niche feature. Combined with the limited support for hollow shapes in existing engines, I think it adds enough complexity for a potential integrator that it should be dropped. Not opposed to re-adding this in a future iteration, though.