There are four kinds of craft.shape for use with rigidbodies: box, sphere, capsule, and model.
Box, sphere, and capsule shapes all detect collisions with voxels, but model shapes do not.
This seems like a bug; the attached project demonstrates this inconsistency.
@UberGoober Maybe not a bug. The box, sphere, and capsule are all defined shapes and their edges can be easily calculated to be used for collision. Model shapes could be any shape, so their edges can’t be easily calculated for collisions. For simplicity of code, maybe the calculations were left out. If you really need a collision for the model, you could wrap the capsule, box, or sphere around it to check for those collisions.
what’s the point of a physics body that doesn’t report collisions? does it collide with other objects?
@dave1707 and @skar did you look at the sample project? It demonstrates that model shapes detect collisions just fine when they’re colliding with other rigidbody shapes.
So to your point, dave, the complexity of handling irregular-shape collisions is already something Codea does without apparent difficulty.
It simply, for some reason, won’t detect collisions between model shapes and voxels—and because it seems to be only a problem for this one kind of shape in this one isolated case, it seems a lot like a bug to me.
@UberGoober I ran your example and saw that the 3 simple shapes (sphere, cube, and capsule) collided with the voxel and the robot didn’t. I guess I didn’t pay attention to the robot colliding further down. So ignore what I mentioned above. Whether it’s a bug or not is for TLL to determine because I don’t know.
Maybe I didn’t mention this properly in the documentation but the model collision shape only really works well for static collisions (i.e. when other dynamic objects collide with the static model). This is a limitation of bullet3d. There is a technique called convex decomposition, but I have not integrated it since even the latest state of the art techniques still tend to fail on a lot of edgecases. The Roblox developers have greatly improved the state of the art for their engine but the code is not publicly available 
@John yes that would be very good to have in the documentation. The example in the reference uses a STATIC type but it doesn’t explain why.
@UberGoober yeah fair enough