Humanoid animation
Annex C
(normative)
VRML binding
C.1 General
C.1.1 Introduction
This annex specifies the functionality of this International Standard as a set
of VRML prototypes that can be instantiated as nodes within a VRML world. VRML
is specified in ISO/IEC 14772-1.
C.1.2 Topics
Table C.1 lists the topics of this annex.
C.2 Humanoid
PROTO Humanoid [
field
SFVec3f bboxCenter
0 0 0
field
SFVec3f bboxSize
-1 -1 -1
exposedField SFVec3f
center
0 0 0
exposedField MFString
info
[ ]
exposedField MFNode
joints
[ ]
exposedField SFString
name
""
exposedField SFRotation rotation
0 0 1 0
exposedField SFVec3f
scale
1 1 1
exposedField SFRotation scaleOrientation
0 0 1 0
exposedField MFNode
segments
[ ]
exposedField MFNode
sites
[ ]
exposedField MFNode
skeleton
[ ]
exposedField MFNode
skin
[ ]
exposedField SFNode
skinCoord
NULL
exposedField SFNode
skinNormal
NULL
exposedField SFVec3f
translation
0 0 0
exposedField SFString
version
"2.0"
exposedField MFNode
viewpoints
[ ]
]
The name field provides a name for the Humanoid
node,
by
which it can be identified by an application at runtime. That name
shall
also be used as the DEF name of the Humanoid node itself, but
with a distinguishing prefix in front of it. That prefix can be
anything,
but shall be the same for all the Humanoid nodes in a particular
humanoid. The name field shall be present, so that
the humanoid can be identified at
runtime.
The geometry of an H-Anim figure can be described in
two ways.
The first way is within the scene graph of the joint hierarchy, which
is
described in the skeleton field of the Humanoid node. Geometry defined within
Segment
nodes
of this joint hierarchy describe the body as separate geometric
pieces. This method, while computationally efficient, has certain visual
anomalies
(such as seams or creases) that detract from the appearance of the H-Anim figure. The second way of describing the geometry of an H-Anim figure is as a continuous piece of geometry, within the skin
field
of the Humanoid node. For this
method, point and normal
vector data sets are first defined in the skinCoord and skinNormal
fields (in the form of Coordinate
and Normal nodes, respectively). This data is defined in this manner to allow
it
to be referenced by two different entities within the definition of the
Humanoid
node. The first entitiy is one or more IndexedFaceSet nodes that define the surface of the geometry of the humanoid
within the skin field. In most cases, this surface will be
a single IndexedFaceSet node. However, the surface can also be defined as multiple
IndexedFaceSet nodes. It is possible that depending on the implementation of the
IndexedFaceSet nodes and the configuration of the H-Anim figure, multiple
IndexedFaceSet nodes may provide better performance by isolating the continuous mesh
changes
to localized surfaces.
C.3 Joint
PROTO Joint [
exposedField
SFVec3f
center
0 0 0
exposedField
MFNode
children
[ ]
exposedField
MFFloat
llimit
[ ]
exposedField
SFRotation
limitOrientation 0 0 1 0
exposedField
SFString
name
""
exposedField
SFRotation
rotation
0 0 1 0
exposedField
SFVec3f
scale
1 1 1
exposedField
SFRotation scaleOrientation 0 0 1 0
exposedField
MFInt32
skinCoordIndex [ ]
exposedField
MFFloat
skinCoordWeight [ ]
exposedField
MFFloat
stiffness [
0 0 0 ]
exposedField
SFVec3f
translation
0 0 0
exposedField
MFFloat
ulimit
[ ]
]
The name
field is used for identifying the joints at runtime.
Each Joint object shall have a name that matches the name
field
for that Joint object, but with a
distinguishing prefix in front of it.
That prefix can be anything, but shall be the same for all the
Joint nodes in a particular humanoid. The distinguishing prefix is useful in
the case of static routing to the Joint nodes
of multiple humanoids
in the same representation. If only a single humanoid is stored in a
VRML file, the
prefix
shall be “hanim_” (for Humanoid
Animation).EXAMPLE The
left shoulder would have a name of "hanim_l_shoulder".
The name is used for static routing, which typically connects
OrientationInterpolator nodes
in the humanoid representation to the joints. The name field shall be
present,
so that applications are able to identify the Joint
node at runtime.
C.4 Segment
PROTO Segment [
field
SFVec3f
bboxCenter
0 0 0
field
SFVec3f
bboxSize
-1 -1 -1
exposedField
SFVec3f
centerOfMass 0 0 0
exposedField
MFNode
children [ ]
exposedField
SFNode
coord
NULL
exposedField
MFNode
displacers [ ]
exposedField
SFFloat
mass
-1
exposedField
MFFloat
momentsOfInertia [ 0 0 0
0 0 0
0 0 0 ]
exposedField
SFString
name
""
eventIn
MFNode addChildren
eventIn
MFNode removeChildren
]
The name field shall be present, so that the Segment node
can be identified at runtime. The name
field is used for identifying
the Segment nodes at runtime. Each Segment node shall
have a name that matches the name field for that Segment
node,
but
with a distinguishing prefix in front of it. That prefix can be
anything,
but shall be the same for all the Segment
nodes in a particular
humanoid. The distinguishing prefix is useful in the case of static
routing
to the Segment nodes of multiple humanoids
in the same file. If
only a single humanoid is stored in a file, the prefix shall be “hanim_”
(for Humanoid Animation).EXAMPLE The left thigh would have a name of “hanim_l_thigh”.
The name is used for
static routing and the name field, which shall be present, is
used
by applications to identify the Segment
node at runtime.
C.5 Site
PROTO Site [
exposedField
SFVec3f
center
0 0 0
exposedField
MFNode
children [ ]
exposedField
SFString
name
""
exposedField
SFRotation
rotation 0 0 1 0
exposedField
SFVec3f
scale
1 1 1
exposedField
SFRotation
scaleOrientation 0 0 1 0
exposedField
SFVec3f
translation 0 0 0
eventIn
MFNode addChildren
eventIn
MFNode removeChildren
]
The name field shall be present, so that the Site node
can be identified at runtime. The name
field is used for identifying
the Site objects at runtime. If
used as an end effector, the Site node shall have a name consisting of the name of the Segment
node
to which it is attached, with a “_tip”
suffix appended.
EXAMPLE The end effector Site node on the right index
finger would be named
“r_index_distal_tip”, and the Site node would be a child
of the “r_index_distal” Segment object.
Site
nodes
that are used to define camera locations shall have a “_view”
suffix appended. Site nodes that are not end
effectors and not
camera locations shall have a “_pt”
suffix. Site nodes
that are required by an application but are not defined in this
International Standard
shall be prefixed with “x_”. Each Site node shall have a name that matches the name field for that Site
node, but with a
distinguishing
prefix in front of it. That prefix can be anything, but shall be the same for
all the Site nodes in a particular
humanoid. The distinguishing
prefix is useful in the case of static routing to the Site nodes
of multiple humanoids in the same file. If only a single humanoid is
stored
in a file, the prefix shall be “hanim_”.
EXAMPLE The right index finger would have a name of "hanim_r_index_distal_tip".
The name is used for static routing and the name field,
which
shall be present, is used by applications to identify the Site
node at runtime.
C.6 Displacer
PROTO displacer [
exposedField MFInt32
coordIndex
[ ]
exposedField MFVec3f displacements
[ ]
exposedField SFString
name
""
exposedField SFFloat
weight 0.0
]
The name field provides a name for the Displacer node, by
which it can be identified by an application at runtime. That name
shall
also be used as the DEF name of the Displacer node itself, but
with a distinguishing prefix in front of it. That prefix can be
anything,
but shall be the same for all the Displacer nodes in a particular
humanoid. The name field shall be present, so that
the Displacer node can be identified at runtime. Displacer nodes that are used to identify
features shall have a name with a “_feature”
suffix. Displacer nodes that are used to
move a feature shall
be given a name with an “_action”
suffix, usually with an additional
pre-suffix to indicate the kind of motion (such as “l_eyebrow_raiser_action”). Displacer nodes that correspond to a
particular configuration of the vertices shall
have a “_config” suffix.