Improving collision between dynamic and kinematic entities

[Norbo]

Here's some general tips:

-Under/overdampedness is related to the ratio of stiffness versus damping. A very stiff spring with no damping will oscillate. A weak spring with lots of damping will move like sludge towards the target without overshooting. There's a sweet spot where the object can get to the target as fast as possible without overshooting; the default ratio is fairly close to it.

-So, if you see the spring oscillating back and forth a bunch, decrease stiffness or increase damping.

-Conversely, if you see the spring moving way too slowly like it's in molasses, increase the stiffness or decrease the damping.

-The absolute value of the damping and stiffness is related to how heavy the spring-connected objects are. Heavy objects with high constants will behave similar to light objects with low constants.

-Using nonzero BaseCorrectiveVelocity can help if you just need a faster constant approach. Combining this with an overdamped spring might be useful.

-MaxCorrectiveVelocity can be used to prevent excess speed. For example, if the object starts a ways away from the goal, the spring might pull really hard. Capping that could be useful. Be careful with this- it can very easily obscure the spring's behavior such that it becomes quite hard to tune if you aren't wary ("why doesn't changing stiffness do anything anymore darn it!"-syndrome).

-If everything just gets out of whack and doesn't seem to be responding as expected, set everything back to defaults (especially MaxCorrectiveVelocity/MaximumForce).

So while I can't give you exact numbers that will work in your simulation, the above can help guide the configuration. Just remember not to change a bunch of parameters at once- incremental change things is the key to easy tuning.

[snoozbuster]

Alright, I'll keep that in mind... My ideal spring doesn't really reach the goal as fast as possible; but rather it keeps a uniform velocity as much as possible. Machines that reach the goal really fast look kind of silly. To achieve this, would you recommend decreasing stiffness without decreasing damping?

[Norbo]

A fully constant correction speed can be achieved by settings BaseCorrectiveSpeed to the desired speed and setting the StiffnessConstant to 0. The DampingConstant can be decreased to make the constraint more violable if desired.

Another option is to keep BaseCorrectiveSpeed at 0, but to set the MaxCorrectiveVelocity to the desired speed. With that, the constraint will not exceed the desired speed, and when it reaches the goal, it will undergo a brief period of deceleration (if the StiffnessConstant and DampingConstant are such that the spring is critically damped or underdamped). You may need to reduce both the stiffness and damping (by the same amount if you want to preserve the ratio) to make the final deceleration more noticeable. However, it appears there's a bug with the SingleEntityLinearMotor's handling of MaxCorrectiveVelocity. I'll fix that real quick. Edit: Done!

[snoozbuster]

A fully constant correction speed can be achieved by settings BaseCorrectiveSpeed to the desired speed and setting the StiffnessConstant to 0. The DampingConstant can be decreased to make the constraint more violable if desired. Another option is to keep BaseCorrectiveSpeed at 0, but to set the MaxCorrectiveVelocity to the desired speed.

Alright... I'll play with this, too. It's still tending to crush boxes, though, even though the mass of the machines and boxes are the same, and the motor's settings are mostly unchanged (all I do is set MaxCorrectiveSpeed to the distance to travel in the case of translation machines and leave rotation unchanged).

[Norbo]

Decreasing damping and stiffness together (by the same factor to maintain the ratio) will stop the crushing. Technically using a maximum force will stop it too, but I'd recommend just weakening the spring directly before using more configuration parameters.

[snoozbuster]

Decreasing damping and stiffness together (by the same factor to maintain the ratio).

The stiffness is zero... I'm thinking making the damping zero is not going to help.

[Norbo]

"Decreasing damping and stiffness together (by the same factor to maintain the ratio)" applies generally, regardless of what the starting values are.

If stiffness starts at 0 and the damping constant starts at 40000, multiplying both by 0.5 results in 0 stiffness and 20000 damping. So, the ratio is maintained; the spring is just half as strong.

[snoozbuster]

Riiiiight.... I assumed you meant from the initial values.

[snoozbuster]

So, the other problem I'm having is I have a machine that's basically a platform with some rollers on it, and when you activate it it rotates 90 degrees. However, I can't get the rollers and the platform to stay synced, because whenever I have a tube in a machine I do some special handling to make it work with the built-in rollers of the tube. This is only really a problem with this type of machine that uses an offset. Right now I use the same matrix-thing you described to me when I was trying to get that + machine to work way back when, and since I'm changing the goal every frame I set the BaseCorrectiveVelocity to the distance to travel this frame divided by space.TimeStepSettings.TimeStepDuration, but the rollers move just a little bit ahead of the platform... Any idea how to make it better?

Also, I saw what you did with the build notes for that build where you fixed the typo. I lol'd.

[Norbo]

Right now I use the same matrix-thing you described to me when I was trying to get that + machine to work way back when, and since I'm changing the goal every frame I set the BaseCorrectiveVelocity to the distance to travel this frame divided by space.TimeStepSettings.TimeStepDuration, but the rollers move just a little bit ahead of the platform... Any idea how to make it better?

The spring's probably not capable of bringing the object to a complete halt after rocketing it forward with distance/dt velocity. Making it more rigid could reduce the effect. Another option would be to go with the "slow down on approach" method I mentioned earlier, which might allow you to get closer (or bias towards being a bit behind instead of ahead).

Moving a bunch of unconnected objects move with separate motors while trying to keep them looking like a unified whole can be tricky. It's possible to get close with tuning, but the 'proper' method is either to use kinematics that have perfectly rigid motion or to use a true constrained structure such that the objects are actually physically connected. Remember, if the objects aren't in danger of causing crushing, you can still use kinematics.

Also, I saw what you did with the build notes for that build where you fixed the typo. I lol'd.

[snoozbuster]

use a true constrained structure such that the objects are actually physically connected.

What would this look like?

[Norbo]

The RobotArmDemo, for example. Something that actually uses constraints to bind entitites together rather than trying to move every object independently.

[snoozbuster]

Alright. I'll take a looksee. I would assume these binding constraints would have to be rather rigid?

[Norbo]

I would assume these binding constraints would have to be rather rigid?

That depends on the circumstances (effective mass dependent on the constraint, desired behavior). Probably don't want them to be super-duper gooey, though. The RobotArmDemo uses pretty much all default settings.

[snoozbuster]

So, if I were to create a RevoluteJoint that attached the base of some machine to the world entity and specify the center of rotation as the anchor, and then a number of RevoluteJoints (or possibly SwivelHingeJoints that don't use the hinge) that attach the base of the machine to the containing objects, would I be able to then modify the goal of the first RevoluteJoint to change the rotation and position of all the containing objects as well? Then, would I be able to modify the goals of the second layer of Revolute/SwivelHingeJoints seperately to create individual rotation while still retaining the rotation from the first joint? Is that how they work?

More conscisely, joints operate on a sort of bone-like hierarchy, where connected joints' transforms trickle down, but work seperately from any other non-connected motors and constraints acting on those entities, correct? If that's the case (and I believe it's at least close), perhaps a conversion to joints will be rather useful and simpler than my current approach with motors. Rollers not part of a machine could be attached to the world entity via RevoluteJoint, and rollers attached to a machine just have their RevoluteJoint modified. Or something like that. Right? Null connections are like being attached to nothing, correct? I would assume that's what connection to a kinetic entity would do, but then are the objects connected to it pulled towards it?