Blender Non-Linear Animation System
Project Definition
There is no built-in system for complex animation re-use. Motion data cannot be superimposed or combined, or transferred from one character to another.
Blender’s current IK system does not provide consistent results. Holding down KEYPAD_9 often shows the IK system “settling” into position, even though the animation frame has not changed. This problem is becomes more apparent when using more complex animation systems.
The IK solver often does not provide correct results, as the 2d nature of the IK system sometimes prevents optimal solutions for complex 3d IKA chains.
When the user cancels an IK-controlled manipulation with ESCKEY, the IK system does not always correctly revert to the initial state. Coupled with the lack of undo, this makes precise positioning a difficult task.
Blender’s existing skeletal animation cannot be used in gameBlender.
The current mesh deformation system is not directly compatible with hardware accelerated skinning methods, which would be of use in gameBlender.
There is currently no suitable interface for adjusting keyframes across multiple objects.
An IKA skeleton is currently composed of multiple objects. This clutters the workspace (with several objects representing what is conceptually a single object) and provides greater opportunity for user error.
A code interface will be created to allow different application modules to access IK solving services. Client modules will instantiate an IK solver object, load it with the necessary data to describe the IK system and call the solving function. The results can then be retrieved and stored and the IK solver object can be deleted.
The solver stresses deterministic and correct results: the same frame rendered on different computers at different times will deliver the same results.
Improved deformation volume calculation (more intuitive).
Per-vertex deformation allows the user to specify which bones control which vertices.
Limbs no longer store their effector location – just their rotations (Kinematic constraints can be used to simulate this behavior when required). This allows the user to mix IK and FK techniques freely while animating, as well as removing the need to perform IK calculations on every frame.
Animation applied to an armature is stored in an “action” data block. Actions can be applied to different armatures and can be blended together to allow non-linear animation design.
A consistent interface is proposed for all types of constraint. This replaces some of blender’s existing constraint devices (such as track to and parent to path).
A constraint is used as a filter to object transformations. A transformation is fed to a constraint, which determines if the input should pass or fail. In the case of a fail, the constraint modifies the transformation so that it conforms to a pass. Internally a constraint may reference and gather transformation data from between 0 and n objects as further inputs to the filtering operation.
Kinematic constraints help prevent flipping ikas.
Rotation constraints ensure joints behave in realistic ways.
It is possible to have multiple constraints per object (or per bone, in the case of armatures) and these constraints can be animated over time. This means objects can be parented to different objects at different times in the scene and constraints can be enforced and relaxed as needed.
Provides an interface for visualizing all of the animation parameters of all objects in the scene.
Allows action blocks to be duplicated and blended providing an interface for better use of action blocks.
The NLA system is designed to work with the BlenderCreator code base and as such will be written primarily in C.
Some elements, notably the constraint system, would likely be more flexible if written in C++.
The Architecture Board will assess the impact of the proposed changes.
It is important to note that the following descriptions are suggestions only.
As bones are added to the armature, more entries will appear in the bone column. A scrollbar may be used if the list becomes too long to display comfortably in the button window.
Parenting of bones within the edited armature is similar to the existing means of creating hierarchical relationships in blender. Multiple objects are selected and the parenting command is issued with CTRL+P. Parenting can be dissolved with ALT+P. Note that in this mode it is only possible to parent bones to other bones within the same armature.
TOGBUT_NLA: Specifies whether or not to get animation data from the NLA or from the local action (note that local action data can be incorporated into the NLA data using the LOCAL strip type).
TEXTBUT_LIMB: Allows the user to assign a name to each bone. These names are used when reading and creation an action, as well as when deforming a mesh with vertex groups.
NUMBUT_DIST: The deformation distance is used to deform mesh vertices that do not belong to specific groups. Vertices that are part of vertex groups ignore the deformation distance.
NUMBUT_WEIGHT: The deformation weight is used when weighting the influence of each bone. It is used for vertices that are part of groups, as well as vertices that are being influenced by the deformation distance.
TOGBUT_IK: Only available for bones that are part of a linked chain. When this button is unchecked, IK calculations will not propagate past the start point of the specified bone when performing interactive positioning. Note that kinematic constraints ignore the state of the IK toggle and will always propagate calculations down to the root of the chain.
An interface for creating vertex groups for animation is added to the Mesh object’s edit buttons. Using an interface similar to the material index buttons, vertex groups can be assigned to specific armature limbs. Note that a single vertex can be a member of multiple groups, making smooth skin deformation possible.
The “Name” button is used to assign a meaningful name to each vertex group, though it would also be possible to use the more cryptic “0: Group 0” interface used for material groups. The armature uses the name to determine which vertices to move with which bones.
In order to find enough screen space to display these buttons, it might be necessary to remove the 10 buttons relating to Intersect, Subdivision, Noise, etc (since many of these are duplicated in the WKEY menu, and most of the others could be added there). Or perhaps an interface could be added to toggle between the mesh editing buttons and the vertex grouping buttons.
If a strip is selected in the NLA window, an NLA icon will appear in the ipo window. The only curve available is the “Factor” curve, which designates the blending weight for the linked action.
If
the s elected object has a constraint block, a constraint icon will appear in
the ipo window. Each constraint has an
“Enforcement” curve in addition to its own settings (different constraints have
different curves to animate). If an
object has multiple constraints, they can be accessed using the NumBut next to
the constraint icon (in the same manner as material Ipos).
If the order of the constraints is changed in the BUTS_CONSTRAINT window, the ordering of the constraint ipo slots is updated as well.
All objects and bones that can have object ipos can also have a list of associated constraints. Due to the relative nature of constraints, it is not advisable to make the constraints into a linkable data block – otherwise there might be problems with cyclical constraints, etc.
These buttons allow the user to delete and modify an object’s constraints. Each constraint gets an enforcement curve in the IPO window as well as additional constraint-specific curves. Note that constraints cannot be added in this view: they must be added using the newly changed CONTROL+TKEY command from the 3d window.
Change the order of the constraints by clicking on a collapsed constraint and choosing MOVE UP or MOVE DOWN from the requestor.
Uses a Sequencer-type interface to allow compositing of actions and to create transitions. An associated Ipo curve is used to blend the actions. If no curve is linked to a particular transition, a simple linear blend will be performed.
Displays a broad overview of all objects within a scene.
Add
a predefined action with SHIFT+AKEY>>ACTION. This creates an action strip, which can be positioned in the
timeline. A strip can be created for
the motion currently in the armature with SHIFT+AKEY>>LOCAL. This allows the user to customize a canned
animation on a scene-by-scene basis (for example, making a character turn its
head to face a unique scene object while playing a standard walk cycle). A BVH file can also be used to supply motion
data. In this case constraints applied
to the “Local” channel could be used to fix noise in the BVH data. This is similar to loading an AVI in
blender’s image sequencer.
Pressing
NKEY with an action selected brings up a requestor that sets the play range
(start and end frames) and the number of times to repeat the action. An action strip that has a repeat set for it
will be graphically subdivided in the timeline view.
Stretching the action clips causes the action to be played back at a different speed, but it does not clip the range of motion (this is done with NKEY).
Where two actions overlap, a transition can be created by pressing SHIFT+AKEY>>TRANSITION where transition is one of the available transition types. As with the sequence editor, a motion ipo can be created which will be used to adjust the relative blending strengths of the two actions:
The bone motions of the two actions are averaged together using the weighting factor of the transition ipo curve. This is a good way to start a building a transition between two states (such as standing to walking), though custom animation in the LOCAL channel should probably be used as well.
The bone motions in the second action are added to the equivalent motions in the first action. This is useful to add a bit of noise to canned action.
The bone motions in the second action will override any equivalent motions in the first action. An application of this might be to override the upper body movements of a character’s walk cycle (perhaps to make the character carry an object).
The Action window provides an interface for manipulating the animation curves associated with the bones of an armature.
A hierarchical, collapsible listing of the channels in an action is displayed at the right. A timeline for each channel is shown at the left, with a single keyframe displayed for every key in that channels’s ipo (equivalent to the positions of the keys in “K” mode in the Ipo window). As in the Ipo window “Key” mode, these keys can be moved, joined and duplicated. Multiple keys can be selected with boundary select or shift-right-clicking. Deleting a key in the Action window deletes all of the keys in all of curves for the selected object for the specified frame.
flags
constraints
restMatrix
outputMatrix
segmentList
· Provides a general purpose IK structure that can be used by other higher-level structures and modules.
· Contains the minimal amount of information necessary to solve an IK chain (e.g. no deformation data, display information, etc).
· Preferably implemented as a C++ object.
solver An IK solver object
Creates a new IK Solver structure. Obviously this function will be implemented as the constructor if the IK system is written in C++. It is very likely that we will ultimately want a choice of algorithms that can be chosen by the user depending on the needs of the animation. This can be easily accomplished by overriding the solve function.
Frees an IK Solver structure and its segments. Obviously this will be implemented as the destructor if the IK system is written in C++.
endpoint The end of the segment (in global coordinates). Segment length is implicit.
Allocates and adds a segment to the end of the chain. The start of the segment is assumed to be the end of the previous segment or the root of the system in the case of the first added segment.
segment The segment to constrain.
constraint The constraint to add to the specified segment.
Allows a constraint to be added to a segment in the chain. Note that segments can have multiple constraints. These are evaluated in the order in which they were added. It is up the the IK solver client to ensure that the ordering is correct.
Performs IK calculations based on the chain’s current settings and stores the results (which can be retrieved with getSegmentMatrix). The role of constraints in the solving equation will be determined at a later date. For the IK solver implementation to be considered a success, it must fulfill the aforementioned criteria of predictability and correctness. Speed of solving is a much lower concern. Future development may address this by offering different IK solving methods.
It is very important to note that in order to ensure correct results, any object that makes use of the IK solver’s services should have its parents’ transformations for the current frame calculated first. For example, if the solver is attempting to solve the motions of a leg, the final position of the pelvis on the current frame must already be determined.
location The target location
Specifies the target for solving in global coordinates.
segment The segment under investigation.
matrix A structure to store the result.
Retrieves the transformation matrix from the specified segment. This function is used to retrieve solutions from the solver object after the calculation has been performed.
No functions
No functions at this time. It is important to note that future development may implement a variety of different solvers for different purposes (perhaps with a less deterministic but faster solver for game engine use).
The Armature object replaces the existing IKA system in Blender. It provides a means of deforming a mesh according to motion data provided by Pose objects.
The ipos and constraints for the bones are stored in an “Action” data block. The armature as a whole has its own ipo links, which can be used to transform the entire hierarchy.
The armature stores the names of its bones. Since the bones are a sub-element of the armature, two different armatures can have the same bone names. This is necessary for sharing action libraries. When it is necessary to display a bone’s name it will be prefixed by “objectname»”. So an actor’s left arm might be referred to as “ACTOR»LeftArm”. The left arm of a duplicate of that actor might be named “ACTOR.001»LeftArm”. This system must be discussed with the Architecture Board.
In addition to the volume-based deformation method currently used in blender, per-vertex deformations can be created as well. Vertex groups are stored in the Mesh structure and are created in edit mode. A single vertex can be a member of more than one group. These groups can be assigned to the bones of the armature attached to the mesh and each vertex receives deformation based on which bones it belongs to.
Vertices that do not belong to ANY deformation groups are
deformed using the armature’s displacement volume. Vertices that do belong to displacement groups are completely
unaffected by the deformation volume.
The Armature object will use the services of the new IK solver.
When positioning or rotating the root point of a chain, no IK is performed. All children inherit the transformation of the parent.
While interactively positioning an effector, the solution is based on the previous frame’s positioning.
Pressing ESC during positioning will revert the system back to the exact state it was in when the positioning was started.
While positioning an effector, constraints are computed for every refresh.
When positioning an effector that is not the endpoint of a chain, two solutions are required, one for each half of the chain.
· For all effectors prior to the active effector, a solution is computed. The root point does not move.
· For all effectors after the active effector, a solution is computed from the active effector to the end of the chain which tries to keep the end effector of the chain in its starting position, but which may move it if necessary. Though this can provide unpredictable results, the use of constraints will greatly improve it.
· Constraints are calculated for each effector after it has been positioned and before the next effector is calculated. Kinematic constraints only affect limbs earlier in the chain. The limbs after the constraint only inherit the rotation of the constrained limb.
· As mentioned in the IK solver section, the bones in an IK chain within an armature need not be planar.
· Create limbs with CONTROL+LEFTCLICK, or by selecting an endpoint and pressing EKEY>>EXTRUDE.
· Connected or extruded limbs will form IK chains.
· Delete a limb by selecting it and pressing XKEY>>SELECTED or XKEY>>SEGMENT.
· Separate a limb from a chain by selecting the segment and pressing YKEY.
· A limb can be made the child of another limb using CTRL+PKEY.
· Constraints can be added to bones in this mode. These constraints will always be evaluated before any additional constraints that may be defined in actions applied to this armature.
· Allow Limb position editing for ARMATURE by moving either the start point or the endpoint of each limb.
· When the armature enters edit mode, all limbs revert to their rest positions. When the armature leaves edit mode, the limbs revert to their animated positions (similar to how a deformed mesh behaves).
· The deformation volume is automatically recalculated as soon as the armature leaves edit mode. Deformation distance for each bone is a true capsule shape, rather than a distorted sphere (as in the current implementation).
· Right click on the model to select the entire armature as a single object.
· When the model is selected, the IPO window and BUTS_CONSTRAINT window display the data for the base of the entire hierarchy.
· Insert animation keys for the base of the entire hierarchy by pressing IKEY and selecting from the standard selection of LOC, ROT, etc filters.
· Pressing XKEY deletes the entire armature; bones cannot be added or deleted when not in edit mode.
· Selecting the root while a bone is selected will deselect the bone (even if SHIFT is held down).
Press CONTROL+RIGHTCLICK on an endpoint to select an individual bone or SHIFT+CONTROL+RIGHTCLICK to select multiple bones. When a bone is selected it is highlighted in light blue as opposed to light pink.
Constraints applied to bones in this mode will be stored in the appropriate channels of the current action. These constraints are always evaluated after constraints stored in the bones of an object.
Any of the points in a chain can be selected. The bone for which the point is the ENDPOINT will become the highlighted bone. The exception is if vertex 0 is selected (the start point of the first limb). In this case the first limb will be highlighted.
Moving an endpoint effector (or a midpoint effector) by selecting it and pressing GKEY will cause IK calculations to be performed relative to the previous refreshes’ positioning (using the solving methods mentioned above). Active constraints will be calculated during the positioning process, potentially overriding the user’s input. Once the limb has been positioned, only the ROT of all limbs is stored. In the case of constrained limbs, the rotation that is stored is the result of the constraints.
Moving the root point of a chain will translate the entire chain as well as all children.
Insert animation keys for the bones by selecting the appropriate bones and pressing IKEY. If the selected bone is not the root of a chain the IKEY menu will include 3 options: BONE, CHAIN and ARMATURE AVAIL.
· ROT keys set AVAIL keys for the currently highlighted bone.
· CHAIN AVAIL keys set AVAIL keys for the highlighted bone and all of its children within the same limb.
· ARMATURE AVAIL keys set AVAIL keys for all of the bones in the armature.
Pressing XKEY deletes the entire armature regardless of whether the whole armature is selected or only a single bone.
The ipo of the highlighted bone is displayed in the Ipo window. The name of the highlighted bone is also highlighted in the Action window, and vice versa.
IK chain links (when applicable)
Non IK-linked children
Bone name
Length in blender units
Offset from parent
List of constraints
List of bones
Associated mesh
The current pose
(Additional deformation data?)
· Stores a list of named bones and their hierarchical relationships.
· Stores the current pose. This pose can be updated by associated actions or by NLA data, or by user manipulation in poseMode. The current pose is used by other armature routines when determining deformation and display results.
· Stores a reference to an associated mesh and the deformation information required.
· Normally an armature may only have one action associated to it at any time. The presence of NLA data in the scene overrides this restriction.
mesh Reference to the original, undeformed mesh.
rmesh Deformed mesh data, ready for rendering.
Returns a pointer to some sort of renderable mesh data corresponding to the deformation implied by the current pose. If the mesh contains user-defined vertex groups, the armature uses these to deform the mesh (note that this is the only type of skinning that is expected to have gameBlender support). If the mesh does not have vertex groups, the deformation volume is calculated on the fly based on the rest position of the mesh and the armature.
pose Input pose.
Sets the current pose to the specified pose. Compares the transformations in the current pose to the bones in the armature according to names and transforms the limbs accordingly. If a bone specified in a pose does not exist in the armature, that pose entry ignored.
This function essentially acts as a funnel that allows multiple components to feed animation data into the armature.
Draws a wireframe representation of the armature structure for editmode or debugging purposes.
arm The newly created armature structure.
Creates a new armature and initializes the necessary data structures. No bones are added at this time.
Deletes an armature and releases all associated data.
Handles editmode operations such as adding and removing bones and reshaping the rest position of the armature. Upon leaving editmode, recalculates the deformation volume.
Handles interactive positioning of the armature’s bones.
When manipulating a specific chain in IK mode, a new IK Solver is created at the beginning of the manipulation and is deleted once the operation is complete and the solution has been retrieved.
A toggle for automatic keyframe insertion can be activated, which automatically sets keyframes for affected bones for the current frame whenever the bones are manipulated.
Replaces the armature’s current pose with the pose derived from the current action and NLA data associated with the armature (if any). This overrides any pose already applied to the armature.
Called on FrameChanged events.
While the user drags an armature bone, this function calculates IK for the limb and evaluates constraints for the whole armature (so that bones constrained to the manipulate bone update correctly). When the drag is complete, only the resultant rotations are stored. If the user cancels this operation, the system is restored to the exact state it was in before the operation began.
No functions
An action data block is required to make the bones of an armature move.
An armature can only have one action assigned to it at a time, but the use of an NLA block allows for more complex movement.
Selecting ADD_NEW from the SPACE_ACTION menu while an armature is selected creates an action datablock. Like images and scenes, actions are persistent in the file until they have zero users and are explicitly deleted by clicking on the “X” button.
An action data block stores the multiple ipo links and constraints associated with an armature. For each bone in the armature, the action stores the name and the necessary data block links.
An action can be applied to a different armature than the one it was created from. The action uses the bone names it has stored to compare with the bone names of the armature it is attached to. If the armature has extra bones that are not listed in the action, they are not affected (though they may inherit transformations from their parent bones). If the armature is missing bones that are present in the action, there is no error given, but the motion data for those bones will be ignored, and the names of the missing bones will not be displayed.
The action is responsible for storing constraints on limbs.
Transformation format flags
List of channels
Transformation data
· The pose is the interface used to position an armature. Also provides a flexible means to transfer animation data between blender components and external libraries: any component that can generate a valid pose can drive the motion of an armature object.
· The pose does not contain any constraint data, since the pose is the result of a constrained action: the constraints are already incorporated into the pose. However the pose format may be updated to incorporate constraint data in the future.
· Consists of a header block specifying the order of operations and a list of bones involved in this pose, followed by an arbitrarily sized data block specifying the transformation data. This will make it easier to incorporate motion data from a variety of sources.
· Data can be Euler angles, matrices, quaternions or a combination of Euler transforms and 3x3 matrices.
· Transform order flags: [RST, RTR, SRT, STR, TRS, TSR, M3T, TM3, TM3T, M4, M3, Q4T, etc]
· Rotation order flags: [XYZ, XZY, YXZ, YZX, ZXY, ZYX]
Channel Name
Channel ipo
List of actionChannels
length The length of the action in frames.
Returns the length of the action in frames.
frame The frame of the action to retrieve.
pose A pose object containing the transformation for the specified frame.
Retrieves pose data for the specified frame.
startframe The start frame of the range (usually the previous frame).
endframe The end frame of the range (usually the current frame).
displacement The total displacement of the armature between startframe and endframe.
In the future, actions will store displacement of objects (essentially dLoc info). This function enables the engine to extract the displacement incurred by the current animation.
action A structure containing the new action.
Creates a new action. No limb entries are made at this time; they will be created when keyframes are set.
Deletes an action and unlinks the associated ipo curves.
pose A pose structure containing entries for all of the channels that should be keyed on this frame.
Inserts a keyframe for all of the specified ipo curves in the action based on an input pose.
If a limb is specified in the pose but does not exist in the action, a new limb entry will be added to the action.
channel The name of the channel to add.
Adds a new channel entry to an action.
channel The name of the channel to remove.
Removes a channel entry from an action and unlinks all of the ipos associated with that channel.
keyList A list of keyframes to remove.
Removes one or more keyframes from all ipos of all limbs for the specified frames.
keyList A list of keyframes to modify.
transformation The transformation to apply.
Provides an interface to scale or move the time indices of multiple keyframes.
· The NLA data is associated with the SCENE object, similar to the sequence editor data.
· The NLA block provides an overview of all of the animation data in the scene. Keyframes can be adjusted across multiple objects and in the case of action-based objects (i.e. armatures) animation data can be blended.
Takes as input a list of poses and their blending modes. Returns a pose that is a composite of the inputs. An interface for weighting the inputs may also be required.
inPose The input pose.
outPose The converted output pose.
Converts the format of a pose to a different format. This function is useful for converting data for export to a 3rd party file format.
If it is not possible to convert the data into the specified format, the function returns an error.
pose The pose containing the channel.
channel A reference to the channel to convert.
matrix A structure to contain the matrix after conversion.
Converts a single channel of a pose to a blender-usable 4x4 transformation matrix.
Allows addition, deletion and manipulation of actions associated with objects in the scene.
· A single object can contain multiple constraints.
· The order in which constraints are calculated is significant. This means there must be a means to explicitly define an order for them (Move Up and Move Down). Each constraint operates on the transformation passed to it by the previous constraint.
· Create a constraint by selecting one or more objects and pressing CONTROL+TKEY. A popup menu will appear. The highlighted object will become the target of all of the other selected objects.
· Different constraint types may have different animatable parameters in the constraint’s ipo window.
· Depending on the type, a constraint can have links to 0-n other objects in the scene. How the constraint chooses to use the information it derives from those objects is determined by the specific constraint.
· Each constraint has a set of associated curves in the Constraints IPO view. These curves allow the user to animate the enforcement of each constraint. If an object has multiple constraints, the curves for each constraint can be accessed using the NumBut next to the constraint icon in the Ipo window.
· Circular constraints are not allowed and will produce an error alert if attempted.
· If a constraint cannot be evaluated (due to a missing target for example), it will be ignored.
· Constraints can be copied from one object to another with the CONTROL+CKEY menu (either “ALL” or on a constraint by constraint basis).
For constraints with delta keys (i.e. offsets from the basic constraint), the delta keys are normally evaluated after the basic constraint has been applied.
Causes the child to orient in such a way that it points at the target.
Replaces the “Track To” command currently present in blender and adds the ability to animate tracking relationships. Use DROT to specify an offset.
The child object obtains location and rotation information from the path, based on the value of the “time” ipo curve.
Replaces “Parent to Path” in the current blender.
Causes the selected limb to try and solve itself and its parents to touch the target. Limbs that are after the constrained limb in the chain only inherit the rotation: they are not considered a part of the solution. Note that this limb may be moved by a kinematic constraint on a limb later in the chain.
This constraint can affect the position of bones which appear earlier in the limb. This is contrary to the behavior of most constraints, which only operate on the limb they are attached to.
Child inherits transformations of the target. This replaces the existing parenting relationship, and allows parenting relationships to be animated over time. Note that an object can now be the child of multiple objects, which can provide odd results if both relationships are fully enforced.
Copies the target’s local rotation to the child. Uses the child’s DROT to specify an offset.
Copies the target’s local scale to the child. Uses the child’s DSIZE to specify an offset.
Copies the target’s local translation to the child. Uses the child’s DLOC to specify an offset.
Replaces “Vertex Parent”
Prevents the object’s rotations from exceeding a specified threshold.
Includes TOG_BUTS for X, Y and Z components.
Prevents the object’s translations from exceeding a specified threshold.
Includes TOG_BUTS for X, Y and Z components.
Prevents the object’s scaling from exceeding a specified threshold.
Includes TOG_BUTS for X, Y and Z components.
When converting actions to gameBlender, kinematic constraints on armature bones that only refer to other armature bones (i.e. constraints with no dependencies outside of the armature) can be pre-evaluated to speed realtime playback.
It may not be possible to convert certain types of constraints to gameBlender mode. An example would be kinematic constraints that point to objects extern to the armature of the action being converted. In this case the constraint is simply ignored when converting the action to gameBlender.
Constraint ipos
· The first phase of implementation replaces existing blender relationships with the new constraint system. I.e. parenting, tracking and path relationships.
· The second phase adds new constraints: rotation, kinematics, location.
· Some constraints are only valid in certain modes. For example, some constraints might not work in the game mode.
· Preferably implemented as a C++ object.
transformIn The input transformation.
transformOut The constrained output transformation.
Given an object transformation (in the form of a series of xyz parameters for translation, scaling, rotation), the constraint returns a corresponding set of transformations that conform to the constraint’s restrictions.
If the constraint cannot be evaluated because one or more of the operator objects does not exist or is otherwise inaccessible, the constraint makes no modification to the input data and returns it untouched.
Draws a wireframe or shaded representation of the constraint where possible. Examples would be dotted lines to illustrate parenting or tracking relationships or arcs to illustrate rotational constraints.
Allows addition, deletion and editing of the constraints associated with an object.
An estimate of the required tasks is presented below.
· Write headers and design data structures.
· Design layout of graphical interfaces.
· Implement ik solver object
· Use the new solver in the existing IKA structure. This serves as both a proof that the ik solver object is functional, as well as providing an immediate feature improvement to the user community.
· Instantiate an Armature object and create a data structure for it.
· Implement edit and pose modes for armature.
· Prepare a framework to allow edit and pose modes to assign constraint channels.
· Implement kinematic constraints for armatures.
· Implement creation, editing and playback of action data for armatures.
· Ensure armatures are converted to the game engine and can be used to deform game meshes with smooth-skinning.
· Implement an interface to allow the game engine to play actions for armature objects.
· Export motion blending and pose functions for use by the game engine
· Add non-linear motion blending capabilities to the game engine.
· Implement parenting, tracking and path constraints.
· Convert existing blender relationships to new constraints system.
· Rotate and scale like, translate to constraints.
· Provide an interface for blending actions for use within the linear rendering engine.
· Allow for global manipulation of animation data within a scene.
|
|
|
|
|
|
|
|
|
|
|
Data
Links (currently obsolete)