Yes.

In the last paragraph, the support function is mainly implemented in model spaces, is this just in terms of using it because many physics engines only keep model spaces in memory?

C_dot is expected to violate the constraint whenever the two objects are closing on one another. The velocity constraint JV + b >= 0 is only enforced when there’s actual penetration.

Thanks. The issue was my contact normal. I didn’t do the transformation correctly between by code and the 3d model code I’m working with (which is left handed).

I have one comment about the line C_dot : JV+b >= 0. Either I misunderstood something, or maybe there needs to be a clarification. It seems that if the contact normal always points from object A to object B then C_dot will always be less than 0 if the two objects are closing on one another (even when not making contact). There has to be something to flip the sign, like having the normal direct be scaled by the sign of the penetration depth.

Nothing immediately comes to mind. Unfortunately, I can only give the boring suggestion of stepping through the calculations to figure out where the upward velocity component comes from.

Most things seem to work well, however if I place the cube on an incline it will automatically slide UP the incline.

Any thoughts on where that sort of error might be?

You don’t have to update the entire exposure map all the time. And depending on the use case, there are better ways to implement and update exposure maps. The focus of this tutorial is not on exposure maps through; it’s about optimization techniques.

one thing I’m not sure about, how would you scale that to work with a larger map? I presume it’s not going to be enough to check all “cells” in the map for distance to the player…
my best guess would be querying the map with a rectangle around the red cube ,in a similar fashion to querying a quad tree? (as in return all cells inside this rect)

thanks again 🙂

Can you elaborate some more on the singularity condition? I tried to implement something myself with the help of this and some other sources and I try to understand some more.

It depends on the software library you use, but provided it is Unity it seems that first you check the squared norm of the imaginary part? A square norm of zero on the imaginary part would imply an identity quaternion, or a N*360 degree rotation, which the “meat” of the algorithm already would handle implicitly by returning two identity quaternions, at least analytically speaking. Is this then for coping with numerical issues when being very close to identity perhaps?

If q is an identity quaternion, “Vector3 rotatedTwistAxis = q * twistAxis” should be a no-op. Then “Vector3 swingAxis = Vector3.Cross(twistAxis, rotatedTwistAxis);” will always be a zero vector.

That implies that swing will be returned as an identity quaternion, but twist on the other hand will be “// always twist 180 degree on singularity
twist = Quaternion.AngleAxis(180.0f, twistAxis); ”
a rotation of 180 degrees. But, it is there, so I guess it solves some problem?

Here is a thread wich a discussion on the subject: https://math.stackexchange.com/questions/4031687/singularity-of-swing-twist-decomposition