Rigid body physics only applied correctly in edit mode I'm confronted with a weird problem in blender's rigid body physics, where the simulation is only applied correctly if the active objects are in edit mode. My test scene: one simple cube and two pallets (euro pallets for logistics) are falling from about 10 meters height onto a simple ground plane. The pallets are real sized and also real weighted. All actives falling for Newton's sake, but the collision on the ground is going wrong. There is a translational impact but no rotational on collision.
The normals are all pointing outwards, but the collision isn't applied correctly, not even close. To check the normals I had to switch to edit mode, did then accidentally hit space, and saw the simulation surprisingly well applied. Almost, because the collision has to be set to convex hull. If set to mesh, both pallets seem to weirdly jam together during collision, almost like the displayed wireframe vertices get stuck together. Sounds silly, but obviously the simulation use the displayed auxilliary mesh overlay for collision, instead of the actual object's data...
The next funny behavior is the fact that the simulation is also rendered correctly in evee or cycles output only if the actives are in edit mode. I don't think that an editor state should yield different output results.
I'm a bit clueless what's going wrong. I've the feeling that something messed up with the pallet's local coordinate system, but I don't know how to fix it.
Btw, I don't know whether it's related or not...but the pallet's appended from another .blend file and there it was imported from an fusion360 exported .fbx file, where I had to fix the scale.
Thanks @zippy for your answer. I checked the mesh again and have to admit that I missed to look on the scaling properties, although the dimensions were fine, it was scaled by factor 0.013;) Now everything collides fine in object mode, too.
Thus you shouldn't play around at 2 am I think;)
The observed behavior makes completely sense now, because the integration steps for the solver are too far away from each other because of the (actual) size.