At what point does it become unfeasible/"not possible" to use a combination of simple colliders to approximate a mesh? The mesh I'm using is for the hull of a ship (about 270 vertices, needs to be dynamic), so it's pretty round and would require quite a few boxes to make the approximation believable.
It's primarily an issue of authoring. For example, if the shape lacks any boxy regularity (like, say, a voxel grid), then trying to fit dozens of boxes to it will be a huge pain. In constrast, there are a lot of tools for automatically generating convex hull decompositions of meshes to varying levels of fidelity.
Performance can be a secondary issue. If the desired level of fidelity is sufficiently high, the required number of spheres/boxes/capsules may make it slower than just using fewer ConvexHulls.
Even if I use simple colliders to represent my meshes in this case, once I get around to terrain generation I'll need to use a mesh object, and the fact that my test mesh cube (not part of a compound) doesn't work either is a little worrying.
That is indeed odd. If you have a .obj file that reproduces the issue, I could stick it into the demos and see if it behaves the same. (Although I would like to figure out why the demos aren't working for you, since you probably aren't alone in that regard.)
Also, by "mobile object" do you mean an object that will be part of a simulation which is run on a mobile device?
Just any object capable of movement, so a kinematic or dynamic body. Dynamic bodies are more concerning since kinematics can't respond to collisions anyway (infinite mass and all that). The core issue is avoiding situations where two infinitely thin triangles need to generate reliable contacts over time, since they just won't.
(Notably, meshes with solidity solve this issue and v1 supported them, but the universal recommendation was 'never use them' for performance reasons. I just dropped the feature. I might revisit this down the line with a more clever approach, but until then, dynamic meshes are evil.)
One other thing I've been wondering...what number of child shapes would benefit from using a BigCompound instead of a regular one? 10? 50? 100?
There's not a fixed threshold, but <4 will very likely prefer a Compound, while >20 will very likely prefer a BigCompound. The only way to know for sure is to measure for a particular use case. BigCompound is a relatively 'safe' choice in that, even when it is slower, the overhead isn't that big of a deal. In contrast, a Compound with 3000 elements in it can be
very slow due to not having any acceleration structure.