I was watching a tutorial on how to do scripting of games in Unity recently and was excited to see that they offer "kinematic" motion. I knew I needed to ask for that here.
Let me explain. In Sansar, an object with a collision mesh can be left static or dynamic. If you want it to move at all, it must be dynamic. Almost all of the scripted dynamics you've seen from me, like hinged doors, rely on a physics fudge that approximates what in Unity is kinematic motion. See, most of my dynamics scripts set the mass of the dynamic object (e.g., door) to zero so it does not fall under the force of gravity. My scripts are setting the position and orientation of these objects very rapidly, thus creating the illusion of motion.
One nasty problem with this trick is that zero-mass objects do not behave as you would expect them to when you throw things at them, run into them, or try to walk on top of them. They typically jitter rapidly as the script is continually updating them. They certainly do not stop you from walking through them, as one might expect of a door. And sometimes they outright throw you across the scene. It's all very unnatural.
I've been working on the alternative, where I let objects have a mass and where I use complex stabilization mechanisms that are based quite literally on rocket science. You can stand and walk on them, they can kick you out of the way if they run into you. They act much more like you would expect physical, moving objects to act. But they are not entirely stable. Attempts to rapidly move them can cause their stabilization algorithms to overcompensate in a way that give engineers of real dynamic systems sleepless nights trying to overcome. They are costly in computing power, suffer from occasional jittery behavior, and can be very difficult to configure. Thus, this technique is not a good general solution for something as simple as a functional door.
Then there's Unity's kinematic motion. In that model, a rigid body like a door is not affected by gravity and cannot be pushed out of the way by a user or dynamic object striking it. It moves, yet it itself is immovable. This is the behavior we are also familiar with in Second Life with doors and some other kinds of scripted animated objects. This is also identical to the motions we see with animated mesh right now. Cerberus' steamship in Darkwood Forest illustrates smooth motion of an object that is essentially kinematic in its motion. You can ride it and it can push you out of the way, but you cannot affect it.
Kinematic motion can dramatically cut down the burden on the physics engine. Because nothing can move a kinematic dynamic object, there's no need to compute the forces acting on it, which makes it the same, moment by moment, as land, trees, and other static objects with collision meshes. That leaves only loose objects you can throw around (and avatars walking around) as objects needing collision computations.
One key to why animated mesh objects can be ridden as vehicles is that their positions are determined by continuous math functions that can be used to compute their velocity in any moment along the path. That velocity gets imparted to anyone riding. This is also why dynamic objects like my hover platforms can be ridden as vehicles, too. Their motions are not determined by frequent updates of position. Rather they are determined by moment to moment velocity computations. Ideally, kinematic motion would work like this, too. While setting position should make it possible for an estimate of velocity computations, a better bet would be for a script to impart linear velocities and rotations and simply update them along the way. Traveling in a circle would, for example, be accomplished by stringing together a series of straight-line motions in the simplest case. But knowing this velocity would make it easy to get riders on board and do other smoothly continuous physics-y things.
So why is scripted kinematic motion highly desirable? Here's a summary of some reasons:
- Increased dynamics without increased physics burden
- Scripted smooth motion without gravity causing jitter
- Continuously smooth motion calculations
- Greatly reduced frequency of update function calls in script
- Simplified motion calculations
- Lower barrier to entry for scripters
- Easy to ride vehicles and moving parts
- Easy to create movable barriers like doors
- Machines don't fly apart because of casual interactions
Are there any downsides? There is one esoteric downside. Namely, you can't really "push back" on a kinematic dynamic object. Or if you step on a platform floating in the water, for instance, it won't bounce a little like you might expect. Honestly, this is more than made up for in the massive increase in content creation potential and decrease in likelihood of physics engine crashes, IMO. Also, if I created a door using the dynamic stabilization mechanism I described above, you still couldn't really push back, because the algorithm has no way to recognize that you're doing it and respond in some natural way.
In all honesty, I cannot currently see any downsides at all. None. But the potential is huge, I think.
If you agree with me, please do up-vote this post. And I welcome all comments, for and against.