Consequences of a 0 margin

[sparkprime]

On second thoughts I think it's probably OK. I was thinking that the planes were defining the hull from 0,0,0 but this need not be the case. E.g. the following planes ought to be fine:

(0,0,1, -1)
(0,0,1, -2)
(0,1,0, -1)
(0,1,0, -2)
(1,0,0, -1)
(1,0,0, -2)

I.e. (assuming i got this right) a cube of the following points:

(-1,-1,-1)
(-1,-1,-2)
(-1,-2,-1)
(-1,-2,-2)
(-2,-1,-1)
(-2,-1,-2)
(-2,-2,-1)
(-2,-2,-2)

[dphil]

I tried those vertices you stated, and I got the following for the planes (via stdout from the code):

(1, 0, 0, 1)
(0, 1, 0, 1)
(0, 0, 1, 1)
(-1, 0, 0, -2)
(0, -1, 0, -2)
(0, 0, -1, -2)

Which means that the orientation of the planes is toward their "outward" face, such that the w-value is always negative if the plane is facing away from the origin (and positive otherwise). And indeed this will always be the case in a convex hull that contains the origin (all planes face "away"), but NOT otherwise, confirming your original doubts. So indeed simply checking if (plane[3]+margin >= 0) only ensures valid shrinkage for hulls containing the origin (even then, it could miss ones that are large enough but not centred on the origin), and was in fact dismissing entirely any hulls that do not contain the origin, as they will necessarily have one or more planes with a positive w-value already. So *that's* why my simulation's errors were "fixed"; not because it was only doing shrinking where appropriate but because it wasn't even attempting it at all for all my convex hulls except the one that was lucky enough to contain the origin!

I guess I'll devote a bit more brainpower to this tomorrow, though I'm open to suggestions.

(fyi, I did a couple more tests, and it even seems ok if the objects vertices are all shrunk to the same point; the problem comes as soon as they start to flip directions across the object's centre, for example if you put a margin of 0.51 on a 1x1x1 cube and then shrink it)

[sparkprime]

Upon adding the check, I found I was getting errors in all of my collision meshes that use this feature This is because so many of them are made out of hulls that do not intersect (0,0,0). I'm not sure if there is actually a problem with those meshes or whether the check is over-conservative though.

[sparkprime]

A few things I can think of that might be worth trying:

* Adding to the parameter instead of subtracting from it, when it is positive (probably the easiest)
* Re-calculate the plane equations so that the parameter is always negative by flipping the normal (probably equivalent to the above)
* Translating the hull to 0,0,0 by using an invented centre calculated by averaging the vertexes, doing the shrink, and translating it back again

I am not completely convinced that the >0 thing is actually a problem, though.

[sparkprime]

Any news on this? Does anyone know what the code does and what it can tolerate?