2
$\begingroup$

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.

$\endgroup$
1
  • 1
    $\begingroup$ A couple of thoughts: 1) since you imported the objects, be sure that you have applied scale & other transforms before using the objects. 2) Sometimes Blender will cache sim results which are corrupt, so be sure to 'rewind' the simulation to the beginning when running it. You can also manually force the cache to clear. 3) Re: the meshes jamming together, you can add a 'collision margin' in the rigid body sensitivity settings, or increase the solver iterations, to mitigate this. HTH -Z $\endgroup$
    – zippy
    Oct 5, 2020 at 4:24

2 Answers 2

0
$\begingroup$

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.

$\endgroup$
0
$\begingroup$

I've just ran into this actually. After watching it over and experimenting a few times I think in edit mode you're actually simulating with the Convex Hull mesh.

Here is a quick video https://i.stack.imgur.com/QjtJ6.jpg

If you swap to Convex Hull, you get the same result as edit mode. You generally don't want a Convex hull for more complex collisions as it won't properly fit your mesh.

$\endgroup$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .