Collected News Pack Part 2/2 - Drag[en]gine

For a single news post there had been too much going on hence I split the news into two with a larger one posted first and the smaller one coming now. What is large or small though is difficult as it has been all intervened somehow. So I decided to split the technical parts into a smaller news post.

Animator Instances

Animators should be nothing new to watchers of this engine. They obtained now a change though which also had been required for making the Conversation System easier to implement and these are Animator Instance. To put it simple the animation system has been split into two worker parts which had been so far all handled by one system: Animators and Animator Instances. Animators take over now the task of defining how animations are produced. This works the same as in the past but now they are independent. For this Animator Instances have been introduced. These take on the job to actually apply an Animator to your game actors. Hence an animator itself can now be shared so multiple elements in the game world can use the same Animator. This has various effects. It reduces the memory foot print, allows reusing animation systems more easily and improves animation speed since modules know about sharing now and can improve animation production where possible.

With animator instances existing another interesting feature can be created without extra work: Animation Retargeting. Retargeting is a process in which animations are mapped between objects with differing rigs. There exists different ways to do this but in general it's not easy and requires extra work. With the new Animation Instances though this process becomes a no-brainer. Animators have a Rig and Animation assigned while Animation Instances have a Component assigned (which in turns has a Model, Skin and Rig). As you can see two Rig resources exist, one in the Animator and one in the Component linked to the Animator Instance. If the two are the same all is fine. But if they are different automatic retargeting is done. Hence if you use an Animator on a Component with a different Rig the engine fixes the animations for you automatically. This is all it takes for retargeting, just use a Component with a different Rig. More about this later.

Another change is that animators have now a list of Affected Bones. So far only Rules had such a list defining which bones are affected. This new list determines now which bones the entire animator affects. Useful to optimize animations like Facial Animation or Gestures.

Inverse Kinematics Improvements

The Inverse Kinematic Rule has been improved with a few changes. One change is fixing the ugly jittering that plagued the IK Rule since some time now. A modification to the code helped to remove the jittering so IK is now looking good again.

Another addition are IK Limits to the Rig resource. Inside Rig resources you can now define limits for IK. These limits define how far bones in the Rig are allowed to be rotated as well as how stiff these rotations are. IK Rules can now take advantage of these informations if they find them in Rigs. So you do not have to mess with IK Rules to add these limits. If a Rig has IK limits they are used. If a Rig has no IK limits they are ignored. An easy to use system.

Relative Movement Attachment

As mentioned some time ago Colliders can be attached to others so the Physics Module takes care of such dependent movement. To assist in making actors ride platforms as well as other movement relative to other objects a new attachment type has been added, the Relative Movement attachment type. A collider attached to another collider using the Relative Movement attachment type takes over the movement and rotation "changes" of the parent collider but otherwise moves independently. Hence for an elevator a collider attached like this will take over all movement the elevator does (in all directions) while still allowing the collider (player) to move freely around. This makes implementing such systems very simple as the game developer does not have to worry in what order or if at all objects move. The Physics Module takes care about handling this relationship properly.

The Epsylon game for example adds a new property to Actor classes, the RideCollider property. When a player steps on a suitable object he is attached to the object using Relative Movement. From that time on the movement works the same as before but the object applies the movement to the player too. As soon as the player jumps off or walks off the object he is detached. Implementing actors and moving platforms this way is very simply and mostly automatic.

Miscellaneous

In addition some smaller additions have been made not worth an own section. For one Rigged Colliders (aka colliders having only a Rig not a Component) are now supported as non-static colliders. This can be useful for AI handling especially with complex AIs composing of elements able to move/rotate relative to each other.

Furthermore the locomotion for human actors has been improved. Movement should be more agreeable now and the 1st person view should also be less "strange".

Outlook

Next batch of work includes tackling driver related issues as well as AI or Sound related work, whichever comes first.