Architecture (Comparing - Part 3)
|Table of contents|
Both XSI and Maya represent scene data using a graph structure. The exact workings are beyond the scope of this article, but for plug-in writers some knowledge of the differences can be critical.
In Maya a fundamental building block for representing scene data is called a Node. The actual state of each node is represented by its Attributes. An attribute can be a fundamental piece of data like an integer or a string, or complex data like an array, or even binary data. In XSI, the rough equivalent of a Node is the ProjectItem and the equivalent of an attribute is a Parameter .
The primary representation of scene content for both Maya and XSI is a “DAG” structure. All the content of a scene is placed into a hierarchy of parent/child relationships. In XSI this hierarchy is visible in the scene explorer.
In Maya there is also the concept of a Dependency Graph, which is viewable in the Hypergraph window. XSI has no equivalent view, but it does maintain a similar concept of dependency between data. In Maya, nodes are connected together by connecting an output attribute on one node to an input attribute on another node.
Outside the XSI render tree a special type of object called an Operator maintains input and output ports which make connections to XSI objects and establish the dependency relationship. XSI also supports specialized dependency relationships such as Proxy Parameters, Overrides and Expressions.
XSI Shader nodes are connected together in a similar fashion to the Maya dependency graph, with the output of each shader node connected to a parameter on another Shader or the Material.
Maya has the concept of DAG paths, which is a string listing the necessary traversal to reach from the root node of the scene to a specific object. XSI also uses a similar approach to provide a unique name for an object, this is called the FullName. In Maya it is specifed as “|ParentObj|Child” and in XSI it is specifed as “ParentObj.Child”.
In Maya, multiple paths through the DAG may refer to the same object, for example when using instancing. In XSI the same thing can happen, for example when using a shared material.
XSI has a concept of NameSpace that establishes rules about when two objects can have the same name. For example two x3dobjects cannot have the same name if they are a part of the same model. For this reason it is not always necessary for the fullname of an object to include all the Parent/Child information that would define its exact position in the DAG. So, although “model_a.parentA.parentB.child” may be a valid string for resolving an object, “model_a.child” may be the actual fullname.
Navigating the Hierarchy
In both products the structuring of objects is very important.
In Maya the listRelatives command provides access to the objects nested beneath a particular node. XSI provides SIObject.NestedObjects and there are also specialized object model properties that provide access to the nested elements based on their type, for example X3DObject.Children, SceneItem.Properties and Primitive.Geometry.
To find the parent the equivalent to Maya's listRelatives –parent is SIObject.Parent
The closest XSI equivalent to a Maya Attribute is the Parameter.
|Read value||getAttr||GetValue (Command) and Parameter.Value (Object Model)|
|Set value||setAttr||SetValue and Parameter.Value|
|List all parameters||listAttr||ProjectItem.Parameters|
|Attribute info||AttributeQuery||Properties of Parameter object, e.g. Parameter.Min|
(XSI does use the term Attribute, but this is for simple object data that is not exposed on Property Pages, for example View.GetAttributeValue, Particle.Attributes and PPGLayout.GetAttribute)
In Maya "Dynamic Attributes" can be used to store extra data on Nodes. XSI uses the CustomProperty objects to store user data inside the scene. Each custom property can have its own set of custom defined Parameters and can be nested underneath almost any object in the scene. For example a Shader can have a CustomProperty object nested underneath it.
XSI also offers of types of Custom Data, including custom keywords, ParticleAttributes, UserDataBlobs, and UserDataMaps.
Custom Nodes and Operators
Maya allows users to write custom nodes for the Dependency Graph. In XSI users can write custom operators. These operators can establish complex relationships between components of a scene, generate geometry, and other powerful tasks but they are also limited: they cannot change a geometry, interact inside a simulation, or act as true custom objects.
Maya uses a push-pull design. Operators in XSI are evaluated entirely based on “pull”.
In Maya, the size, rotation and position of an object is managed by a transform node. The actual geometry node is nested underneath its transform node. In XSI this same information is stored inside Parameters of the Kinematics object, which is a Property nested underneath the X3Dobject. The XSI Kinematic objects contains both a Global and Local transformation for each object.
Function curves (fcurves) in XSI are not considered “nodes” of the scene graph. However they are fully exposed in the SDK.
|Object||AnimCurve Node||FCurve object (not a type of ProjectItem)|
|List of all animated attributes on object||keyframe –query object||ProjectItem.AnimatedParameters|
|Retrieve the FCurve||Keyframe –query object.name_of_param_with_Fcurve||Parameter.Source|
|Determine if an attribute can be animated||listAnimatable||Parameter.Animatable,Parameter.Keyable|
|Evaluate at any time||Keyframe –query –time X –eval object.name_of_param_with_FCurve||Fcurve.Eval|
- Comparing XSI SDK and Maya SDK
- Scripting Basics (Comparing - Part 1)
- Built-In Functionality (Comparing - Part 2)
- Architecture (Comparing - Part 3)
- Custom User Interface (Comparing - Part 4)
- C++ Support (Comparing - Part 5)