Iso/iec jtc 1/sc 29 N

Graphics

The following graphics related nodes are used in ARAF: Appearance, Color, LineProperties, LinearGradient, Material, Material2D, Rectangle, Shape, SBVCAnimationV2, SBBone, SBSegment, SBSite, SBSkinnedModel, MorphShape, Coordinate, TextureCoordinate, Normal, IndexedFaceSet, IndexedLineSet.

Appearance

XSD Description

Functionality and semantics

As defined in ISO/IEC 14772-1:1997, section 6.3.

The Appearance node specifies the visual properties of geometry. The value for each of the fields in this node may be NULL. However, if the field is non-NULL, it shall contain one node of the appropriate type.

The material field, if specified, shall contain a Material node. If the material field is NULL or unspecified, lighting is off (all lights are ignored during rendering of the object that references this Appearance) and the unlit object colour is (1, 1, 1). Details of the VRML lighting model are in 4.14, Lighting model.

The texture field, if specified, shall contain one of the various types of texture nodes (ImageTexture, MovieTexture, or PixelTexture). If the texture node is NULL or the texture field is unspecified, the object that references this Appearance is not textured.

The textureTransform field, if specified, shall contain a TextureTransform node. If the textureTransform is NULL or unspecified, the textureTransform field has no effect.

Additional specification - ISO/IEC 14496-11 (BIFS), section 7.2.2.6.2.

The material field, if non-NULL, shall contain either a Material node or a Material2D node depending on the type of geometry node used in the geometry field of the Shape node that contains the Appearance node. The list below shows the geometry nodes that require a Material node, those that require a Material2D node and those where either may apply:

• 
  Material2D only: Circle, Curve2D, IndexedFaceSet2D, IndexedLineSet2D, PointSet2D, Rectangle;
  
• 
  Material only: Box, Cone, Cylinder, ElevationGrid, Extrusion, IndexedFaceSet, IndexedLineSet, PointSet, Sphere;
  
• 
  Material2D or Material: Bitmap, Text.
  

Inside a Shape node in a 2D context, if no Appearance and therefore no Material2D is defined, the default values and behavior of the Material2D node shall be used. In a 3D context, the default behavior is specified in ISO/IEC14772-1 (the object is unlit and has color 1 1 1).

Color

XSD Description

Functionality and semantics

As specified in ISO/IEC 14772-1:1997, section 6.9.

This node defines a set of RGB colours to be used in the fields of another node.

Color nodes are only used to specify multiple colours for a single geometric shape, such as colours for the faces or vertices of an IndexedFaceSet. A Material node is used to specify the overall material parameters of lit geometry. If both a Material node and a Color node are specified for a geometric shape, the colours shall replace the diffuse component of the material.

RGB or RGBA textures take precedence over colours; specifying both an RGB or RGBA texture and a Color node for geometric shape will result in the Color node being ignored.

LineProperties

XSD Description

Functionality and semantics

As defined in ISO/IEC 14496-11 (BIFS), section 7.2.2.75.2.

The LineProperties node specifies line parameters used in 2D and 3D rendering.

The lineColor field specifies the color with which to draw the lines and outlines of 2D geometries.

The lineStyle field shall contain the line style type to apply to lines. The allowed values are:

lineStyle	Description
0	solid
1	dash
2	dot
3	dash-dot
4	dash-dash-dot
5	dash-dot-dot

The terminal shall draw each line style in a manner that is distiguishable from each other line style. The width field determines the width, in the local coordinate system, of rendered lines. The width is not subject to the local transformation. The cap and join style to be used are as follows. The wide lines should end with a square form flush with the end of the lines.

LinearGradient

XSD Description

Functionality and semantics

As defined in ISO/IEC 14496-11 (BIFS), section 7.2.2.76.2.

The LinearGradient node is a texture ode that generates a texture procedurally. startPoint and endPoint define the gradient vector, in percentage of the bounds of the object.

key represents a location along the gradient vector, expressed in percentage of its length. At each location, an RGB color is specified in keyValue. Opacity for each color value can be specified. By default, colors are 100% opaque. One value of opacity can be specified meaning all color values have the same opacity, else an opacity must be specified for each color value.

transform is an optional parameter that defines how the coordinate system of the gradient can be transformed from the gradient coordinate system onto the target coordinate system. By default, the gradient coordinate system is the same as the object it is applied to. This allows effects such as skewing the gradient.

Only a 2D Transformation node (e.g. Transform2D, TransformMatrix2D) can be present here.

spreadMethod can be pad (0), reflect (1), or repeat (2). It indicates what happens if the gradient starts or ends inside the bounds of the object. Pad means that the last color is used, reflect says to reflect the gradient pattern start-to-end, end-to-start, … repeatedly until the target object is filled, and repeat says to repeat the gradient pattern start-to-end, start-to-end, … until the target object is filled.

opacity for each color value can be specified. By default, colors are 100% opaque. One value of opacity can be specifed meaning all color values have the same opacity, else an opacity must be specified for each color value.

Material

XSD Description

Functionality and semantics

As specified in ISO/IEC 14772-1:1997, section 6.27.

The Material node specifies surface material properties for associated geometry nodes and is used by the VRML lighting equations during rendering. All of the fields in the Material node range from 0.0 to 1.0.

The fields in the Material node determine how light reflects off an object to create colour:

1. 
   The ambientIntensity field specifies how much ambient light from light sources this surface shall reflect. Ambient light is omnidirectional and depends only on the number of light sources, not their positions with respect to the surface. Ambient colour is calculated as ambientIntensity × diffuseColor.
   
2. 
   The diffuseColor field reflects all VRML light sources depending on the angle of the surface with respect to the light source. The more directly the surface faces the light, the more diffuse light reflects.
   
3. 
   The emissiveColor field models "glowing" objects. This can be useful for displaying pre-lit models (where the light energy of the room is computed explicitly), or for displaying scientific data.
   
4. 
   The specularColor and shininess fields determine the specular highlights (e.g., the shiny spots on an apple). When the angle from the light to the surface is close to the angle from the surface to the viewer, the specularColor is added to the diffuse and ambient colour calculations. Lower shininess values produce soft glows, while higher values result in sharper, smaller highlights.
   
5. 
   The transparency field specifies how "clear" an object is, with 1.0 being completely transparent, and 0.0 completely opaque.
   

Material2D

XSD Description

Functionality and semantics

As defined in ISO/IEC 14496-11 (BIFS), section 7.2.2.80.2.

The Material2D node specifies the characteristics of a rendered 2D Shape. Material2D shall be used as the material field of an Appearance node in certain circumstances (see ISO/IEC 14496-11, section 7.2.2.6.2). The emissiveColor field specifies the color of the 2D Shape. If the shape is not filled, the interior is not drawn. The filled field specifies whether rendered nodes are filled or drawn using lines. This field affects IndexedFaceSet2D, Circle and Rectangle nodes. If the rendered node is not filled the line shall be drawn centered on the rendered node outline. That means that half the line will fall inside the rendered node, and the other half outside.

The lineProps field contains information about line rendering in the form of a LineProperties node. When filled is true, if lineProps is null, no outline is drawn; if lineProps is non-null, an outline is drawn using lineProps information. When filled is false and lineProps is null, an outline is drawn with default width (1), default style (solid) and as line color the emissive color of the Material2D. When filled is false and lineProps is defined, line color, width and style are taken from the lineProps node. See ISO/IEC 14496-11, section 7.2.2.75 for more information on LineProperties.

The transparency field specifies the transparency of the 2D Shape and applies both to the filled interior as well as to the outline when drawn. The part of the line which lies outside of the geometry shall not be sensitive to pointer activity. When mapping texture onto a geometry and an outline is to be drawn, the texture shall first mapped onto the geometry, where the geometry dimensions are those without an outline. Then after the geometry is textured the outline shall be drawn.

Rectangle

XSD Description

Functionality and semantics

As defined in ISO/IEC 14496-11 (BIFS), section 7.2.2.110.2.

This node specifies a rectangle centered at (0,0) in the local coordinate system. The size field specifies the horizontal and vertical size of the rendered rectangle.

Shape

XSD Description

Functionality and semantics

As specified in ISO/IEC 14772-1:1997, section 6.41.

The Shape node has two fields, appearance and geometry, which are used to create rendered objects in the world. The appearance field contains an Appearance node that specifies the visual attributes (e.g., material and texture) to be applied to the geometry. The geometry field contains a geometry node. The specified geometry node is rendered with the specified appearance nodes applied.

4.14, Lighting model, contains details of the VRML lighting model and the interaction between Appearance nodes and geometry nodes.

If the geometry field is NULL, the object is not drawn.

SBVCAnimationV2

XSD Description

Functionality and semantics

As specified in ISO/IEC 14496-16:2006, section 4.7.1.7.

This node is an extension of the SBVCAnimation node and the added functionality consists in streaming control and animation data collection. The BBA stream can be controlled as a elementary media stream, and can be used in connection with the MediaControl node.

The virtualCharacters field specifies a list of SBSkinnedModel nodes. The length of the list can be 1 or greater.

The url field refers to the BBA stream which contains encoded animation data related to the SBSkinnedModel nodes from the virtualCharacters list and is used for outband bitstreams. The animation will be extracted from the first element of the animation URL list and if the case when it is not available the following element will be used.

The loop, startTime, and stopTime exposedFields and the isActive eventOut, and their effects on the SBVCAnimationV2 node, are similar with the ones described by VRML specifications (ISO/IEC 14772-1:1997) for AudioClip, MovieTexture, and TimeSensor nodes and are described as follows.

The values of the exposedFields are used to determine when the node becomes active or inactive.

The SBVCAnimationV2 node can execute for 0 or more cycles. A cycle is defined by field data within the node. If, at the end of a cycle, the value of loop is FALSE, execution is terminated. Conversely, if loop is TRUE at the end of a cycle, a time-dependent node continues execution into the next cycle. A time-dependent node with loop TRUE at the end of every cycle continues cycling forever if startTime >= stopTime, or until stopTime if startTime < stopTime.

The SBVCAnimationV2 node generates an isActive TRUE event when it becomes active and generates an isActive FALSE event when it becomes inactive. These are the only times at which an isActive event is generated. In particular, isActive events are not sent at each tick of a simulation.

The SBVCAnimationV2 node is inactive until its startTime is reached. When time now becomes greater than or equal to startTime, an isActive TRUE event is generated and the SBVCAnimationV2 node becomes active (now refers to the time at which the player is simulating and displaying the virtual world). When a SBVCAnimationV2 node is read from a mp4 file and the ROUTEs specified within the mp4 file have been established, the node should determine if it is active and, if so, generate an isActive TRUE event and begin generating any other necessary events. However, if a SBVCAnimationV2 node would have become inactive at any time before the reading of the mp4 file, no events are generated upon the completion of the read.

An active SBVCAnimationV2 node will become inactive when stopTime is reached if stopTime > startTime. The value of stopTime is ignored if stopTime <= startTime. Also, an active SBVCAnimationV2 node will become inactive at the end of the current cycle if loop is FALSE. If an active SBVCAnimationV2 node receives a set_loop FALSE event, execution continues until the end of the current cycle or until stopTime (if stopTime > startTime), whichever occurs first. The termination at the end of cycle can be overridden by a subsequent set_loop TRUE event.

Any set_startTime events to an active SBVCAnimationV2 node are ignored. Any set_stopTime event where stopTime <= startTime sent to an active SBVCAnimationV2 node is also ignored. A set_stopTime event where startTime < stopTime <= now sent to an active SBVCAnimationV2 node results in events being generated as if stopTime has just been reached. That is, final events, including an isActive FALSE, are generated and the node becomes inactive. The stopTime_changed event will have the set_stopTime value.

A SBVCAnimationV2 node may be restarted while it is active by sending a set_stopTime event equal to the current time (which will cause the node to become inactive) and a set_startTime event, setting it to the current time or any time in the future. These events will have the same time stamp and should be processed as set_stopTime, then set_startTime to produce the correct behaviour.

The speed exposedField controls playback speed. It does not affect the delivery of the stream attached to the SBVCAnimationV2 node. For streaming media, value of speed other than 1 shall be ignored.

A SBVCAnimationV2 shall display first frame if speed is 0. For positive values of speed, the frame that an active SBVCAnimationV2 will display at time now corresponds to the frame at animation time (i.e., in the animation’s local time base with frame 0 at time 0, at speed = 1):

fmod (now - startTime, duration/speed)

If speed is negative, then the frame to display is the frame at animation time:

duration + fmod(now - startTime, duration/speed).

When a SBVCAnimationV2 becomes inactive, the frame corresponding to the time at which the SBVCAnimationV2 became inactive shall persist. The speed exposedField indicates how fast the movie shall be played. A speed of 2 indicates the animation plays twice as fast. Note that the duration_changed eventOut is not affected by the speed exposedField. set_speed events shall be ignored while the animation is playing.

An event shall be generated via the duration_changed field whenever a change is made to the startTime or stopTime fields. An event shall also be triggered if these fields are changed simultaneously, even if the duration does not actually change.

activeUrlIndex allows to select or to combine specific animation resource referred in the url[] field. When this field is instantiated the behavior of the url[] field changes from the alternative selection into a combined selection. In the case of alternative mode, if the first resource in the url[] field is not available, the second one will be used, and so on. In the combined mode the following cases can occur:

(1) activeUrlIndex has one field: the resource from url[] that has this index is used for animation. When the activeUrlIndex is updated a transition between to the old animation (frame) and the new one is performed. The transition use linear interpolation for translation, center and scale and SLERP for spherical data as rotation and scaleOrientation. The time of transition is specified by using the transitionTime field.

(2) activeUrlIndex has several fields: a composition between the two resources is performed by the terminal: for the bones that are common in two or more resources a mean procedure has to be applied. The mean is computed by using linear interpolation for translation, center and scale and SLERP for spherical data as rotation and scaleOrientation.

In all the cases, when a transition between two animation resources is needed, when the transitionTime is not zero, a interpolation must be performed by the player. The transitionTime is specified in miliseconds.

SBBone

XSD Description

Functionality and semantics

As specified in 14496-1:2002 6.8.1.1.2.

SBBone node specifies data related to one bone from the skeleton.

The boneID field is a unique identifier which allows that the bone to be addressed at animation run-time.

The center field specifies a translation offset from the origin of the local coordinate system.

The translation field specifies a translation to the bone coordinate system.

The rotation field specifies a rotation of the bone coordinate system.

The scale field specifies a non-uniform scale of the bone coordinate system. scale values shall be greater than zero.

The scaleOrientation specifies a rotation of the bone coordinate system before the scale (to specify scales in arbitrary orientations). The scaleOrientation applies only to the scale operation.

The possible geometric 3D transformation consists of (in order): 1) (possibly) non-uniform scale about an arbitrary point, 2) a rotation about an arbitrary point and axis and 3) a translation.

The rotationOrder field specifies the rotation order when deals with the decomposition of the rotation in respect with system coordinate axes.

Two ways of specifying the influence region of the bone are allowed:

The skinCoordIndex field contains a list of indices of all skin vertices affected by the current bone. Mostly, the skin influence region of bone will contain vertices from the 3D neighborhood of the bone, but special cases of influence are also accepted.

The skinCoordWeight field contains a list of weights (one per vertex listed in skinCoordIndex) that measures the contribution of the current bone to the vertex in question. The length skinCoordIndex is equal with the length of skinCoordWeight. The sum of all skinCoordWeight related to the same vertex must be 1.

The endpoint field specifies the bone 3D end point and is used to compute the bone length.

The sectionInner field is a list of inner influence region radii for different sections.

The sectionOuter field is a list of outer influence region radii for different sections.

The sectionPosition field is a list of positions of all the sections defined by the designer.

The falloff field specifies the function between the amplitude affectedness and distance: -1 for x³, 0 for x², 1 for x, 2 for sinx, 3 for x^1/2 and 4 for x^1/3.

The two schemes can be used independently or in combination, in which case the individual vertex weights take precedence.

The ikChainPosition field specifies the position of the bone in the kinematics chain. If the bone is the root of the IK chain then ikChainPosition=1. In this case, when applying IK scheme, only the orientation of the bone is changed. If the bone is last in the kinematics chain ikChainPosition=2. In this case, the animation stream has to include the desired position of the bone (X, Y and Z world coordinates). If ikChainPosition=3 the bone belongs to the IK chain but is not the first or the last one in the chain. In this case, position and orientation of the bone are computed by the IK procedure. Finally, if the bone does not belong to any IK chain (ikChainPosition=0), it is necessary to transmit the bone local transformation in order to animate the bone. If an animation stream contains motion information about a bone which has ikChainPosition 1, this information will be ignored. If an animation stream contains motion information about a bone which has ikChainPosition 3, this means that the animation producer wants to ensure the orientation of the bone and the IK solver will use this value as a constrain.

The ikYawLimit field consists in a pair of min/max values which limit the bone rotation with respect to the X axis.

The ikPitchLimit field consists in a pair of min/max values which limit the bone rotation with respect to the Y axis.

The ikRollLimit field consists in a pair of min/max values which limit the bone rotation with respect to the Z axis.

The ikTxLimit field consists in a pair of min/max values which limit the bone translation in the X direction.

The ikTyLimit field consists in a pair of min/max values which limit the bone translation in the Y direction.

The ikTzLimit field consists in a pair of min/max values which limit the bone translation in the Z direction.

The SBBone node is used as a building block to describe the hierarchy of the articulated model by attaching one or more child objects. The children field has the same semantic as used in BIFS Error: Reference source not found; the absolute geometric transformation of any child of a bone is obtained through a composition with the bone-parent transformation.

SBSegment

XSD Description

Functionality and semantics

As specified in 14496-1:2002 6.8.1.2.2.

The name field must be present, so that the SBSegment can be identified at runtime. Each SBSegment should have a DEF name that matches the name field for that Segment, but with a distinguishing prefix in front of it.

The mass field is the total mass of the segment.

The centerOfMass field is the location within the segment of its center of mass. Note that a zero value was chosen for the mass in order to give a clear indication that no mass value is available.

The momentsOfInertia field contains the moment of inertia matrix. The first three elements are the first row of the 3x3 matrix, the next three elements are the second row, and the final three elements are the third row.

The children field can be any object attached at this level of the skeleton, including a SBSkinnedModel.

An SBSegment node is a grouping node especially introduced to address two issues:

1. 
   The first one is to the requirement to separate different parts from the skinned model into deformation-independent parts. Between two deformation-independent parts the geometrical transformation of one of them do not imply skin deformations on the other. This is essential for run-time animation optimization. The SBSegment node may contain as a child an SBSkinnedModel node (see the SBSkinnedModel node description below). Portions of the model which are not part of the seamless mesh can be attached to the skeleton hierarchy by using an SBSegment node;
   
2. 
   The second deals with the requirement to attach standalone 3D objects at different parts of the skeleton hierarchy. For example, a ring can be attached to a finger; the ring geometry and attributes are defined outside of skinned model but the ring will have the same local geometrical transformation as the attached bone.
   

SBSite

XSD Description

Functionality and semantics

As specified in 14496-1:2002 6.8.1.3.2

The center field specifies a translation offset and can be used to compute a bone length. The rotation field specifies a rotation of the coordinate system of the SBSite node.

The scale field specifies a non-uniform scale of the SBSite node coordinate system and the scale values must be greater than zero.

The scaleOrientation specifies a rotation of the coordinate system of the SBSite node before the scale thus allowing a scale at an arbitrary orientation. The scaleOrientation applies only to the scale operation.

The translation field specifies a translation of the coordinate system of the SBSite node.

The children field is used to store any object that can be attached to the SBSegment node.

The SBSite node can be used for three purposes. The first is to define an "end effector", i.e. a location which can be used by an inverse kinematics system. The second is to define an attachment point for accessories such as clothing. The third is to define a location for a virtual camera in the reference frame of a SBSegment node.

SBSite nodes are stored within the children field of an SBSegment node. The SBSite node is a specialized grouping node that defines a coordinate system for nodes in its children field that is relative to the coordinate systems of its parent node. The reason a SBSite node is considered a specialized grouping node is that it can only be defined as a child of a SBSegment node.

SBSkinnedModel

XSD Description

Functionality and semantics

As specified in 14496-16:2011 section 4.5.2.1.2.

The SBSkinnedModel node is the top of the hierarchy of Skin&Bones related nodes and contains the definition parameters for the entire seamless model or of a seamless part of the model.

The name field specify the name of the skinned model allowing easily identification at the animation run-time.

The center field specifies a translation offset from the origin of the local coordinate system.

The translation field specifies a translation of the coordinate system.

The rotation field specifies a rotation of the coordinate system

The scale field specifies a non-uniform scale of the coordinate system. scale values shall be greater than zero.

The scaleOrientation specifies a rotation of the coordinate system before the scale (to specify scales in arbitrary orientations). The scaleOrientation applies only to the scale operation.

The skinCoord contains the 3d coordinates of all vertices of the seamless model.

The skin consists of a collection of shapes that share the same skinCoord. This mechanism allows considering the model as a continuous mesh and, in the same time, to attach different attributes (like color, texture) to different parts of the model.

The skeleton field specifies the root of the bones hierarchy.

The bones fields consist in the lists of all bones previously defined as SBBone node.

The segments fields consist in the lists of all bones previously defined as SBSegment node.

The sites fields consist in the lists of all bones previously defined as SBSites node. The muscles fields consist in the lists of all bones previously defined as SBMuscle node.

The weighsComputationSkinCoord field describes a specific static position of the skinned model. In many cases the static position of the articulated model defined by skinCoord and skin fields is not appropriate to compute the influence region of a bone. In this case the weighsComputationSkinCoord field allows specifying the skinned model vertices in a more appropriate static posture. This posture will be used just during the initialization stage and ignored during the animation. All the skeleton transformations are related to the posture defined by skinCoord field.

MorphShape

XSD Description

Functionality and semantics

As specified in ISO/IEC 14496-16:2006, section 4.3.6.

morphID - a unique identifier between 0 and 1023 which allows that the morph to be addressed at animation run-time.

baseShape – a Shape node that represent the base mesh. The geometry field of the baseShape can be any geometry supported by ISOIEC 14496 (e.g. IndexedFaceSet, IndexedLineSet, SolidRep).

targetShapes – a vector of Shapes nodes representing the shape of the target meshes. The tool used for definig an appearance and a geometry of a target shape must be the same as the tool used for defining the appearance and the geometry of the base shape (e.g. if the baseShape is defined by using IndexedFaceSet, all the target shapes must be defined by using IndexedFaceSet).

weights – a vector of integers of the same size as the targetShapes. The morphed shape is obtained according to the following formula:

with

M –morphed shape,

B – base shape,

T_i – target shape i,

W_i – weight of the T_i.

The morphing is performed for all the components of the Shape (Appearance and Geometry) that have different values in the base shape and the target shapes (e.g. if the base shape and the target shapes are definined by using IndexedFaceSet and the coord field contains different values in the base shape and in the target geometries, the coord component of the morph shape is obtained by using previous equation applied to the coord field. Note that the size of the coord field must be the same for the base shapes and the target shapes).

If the shapes (base and targets) are defined by using IndexedFaceSet, a tipical decoder should support morphing of the following geometry components: coord, normals, color, texCoord.

Coordinate

XSD Description

Functionality and semantics

As specified in ISO/IEC 14772-1:1997, section 6.12.

This node defines a set of 3D coordinates to be used in the coord field of vertex-based geometry nodes including IndexedFaceSet, IndexedLineSet, and PointSet.

TextureCoordinate

XSD Description

Functionality and semantics

As specified in ISO/IEC 14772-1:1997, section 6.48.

The TextureCoordinate node specifies a set of 2D texture coordinates used by vertex-based geometry nodes (e.g., IndexedFaceSet and ElevationGrid) to map textures to vertices. Textures are two dimensional colour functions that, given an (s, t) coordinate, return a colour value colour(s, t). Texture map values (ImageTexture, MovieTexture, and PixelTexture) range from [0.0, 1.0] along the S-axis and T-axis. However, TextureCoordinate values, specified by the point field, may be in the range (-,). Texture coordinates identify a location (and thus a colour value) in the texture map. The horizontal coordinate s is specified first, followed by the vertical coordinate t.

If the texture map is repeated in a given direction (S-axis or T-axis), a texture coordinate C (s or t) is mapped into a texture map that has N pixels in the given direction as follows:

Texture map location = (C - floor(C)) × N

If the texture map is not repeated, the texture coordinates are clamped to the 0.0 to 1.0 range as follows:

Texture map location = N, if C > 1.0,

= 0.0, if C < 0.0,

= C × N, if 0.0 <= C <= 1.0.

Normal

XSD Description

Functionality and semantics

As specified in ISO/IEC 14772-1:1997, section 6.30.

This node defines a set of 3D surface normal vectors to be used in the vector field of some geometry nodes (e.g., IndexedFaceSet and ElevationGrid). This node contains one multiple-valued field that contains the normal vectors. Normals shall be of unit length.

IndexedFaceSet

XSD Description

Functionality and semantics

As specified in ISO/IEC 14772-1:1997, section 6.23

The IndexedFaceSet node represents a 3D shape formed by constructing faces (polygons) from vertices listed in the coord field. The coord field contains a Coordinate node that defines the 3D vertices referenced by the coordIndex field. IndexedFaceSet uses the indices in its coordIndex field to specify the polygonal faces by indexing into the coordinates in the Coordinate node. An index of "-1" indicates that the current face has ended and the next one begins. The last face may be (but does not have to be) followed by a "-1" index. If the greatest index in the coordIndex field is N, the Coordinate node shall contain N+1 coordinates (indexed as 0 to N). Each face of the IndexedFaceSet shall have:

1. 
   at least three non-coincident vertices;
   
2. 
   vertices that define a planar polygon;
   
3. 
   vertices that define a non-self-intersecting polygon.
   

Otherwise, the results are undefined.

The IndexedFaceSet node is specified in the local coordinate system and is affected by the transformations of its ancestors.

Descriptions of the coord, normal, and texCoord fields are provided in the Coordinate, Normal, and TextureCoordinate nodes, respectively.

Details on lighting equations and the interaction between color field, normal field, textures, materials, and geometries are provided in ISO/IEC 14772-1:1997, section 4.14, Lighting model.

If the color field is not NULL, it shall contain a Color node whose colours are applied to the vertices or faces of the IndexedFaceSet as follows:

1. 
   If colorPerVertex is FALSE, colours are applied to each face, as follows:
   
   • 
     If the colorIndex field is not empty, then one colour is used for each face of the IndexedFaceSet. There shall be at least as many indices in the colorIndex field as there are faces in the IndexedFaceSet. If the greatest index in the colorIndex field is N, then there shall be N+1 colours in the Color node. The colorIndex field shall not contain any negative entries.
     
   • 
     If the colorIndex field is empty, then the colours in the Color node are applied to each face of the IndexedFaceSet in order. There shall be at least as many colours in the Color node as there are faces.
     
2. 
   If colorPerVertex is TRUE, colours are applied to each vertex, as follows:
   
   • 
     If the colorIndex field is not empty, then colours are applied to each vertex of the IndexedFaceSet in exactly the same manner that the coordIndex field is used to choose coordinates for each vertex from the Coordinate node. The colorIndex field shall contain at least as many indices as the coordIndex field, and shall contain end-of-face markers (-1) in exactly the same places as the coordIndex field. If the greatest index in the colorIndex field is N, then there shall be N+1 colours in the Color node.
     
   • 
     If the colorIndex field is empty, then the coordIndex field is used to choose colours from the Color node. If the greatest index in the coordIndex field is N, then there shall be N+1 colours in the Color node.
     

If the color field is NULL, the geometry shall be rendered normally using the Material and texture defined in the Appearance node (see ISO/IEC 14772-1:1997, section 4.14, Lighting model, for details).

If the normal field is not NULL, it shall contain a Normal node whose normals are applied to the vertices or faces of the IndexedFaceSet in a manner exactly equivalent to that described above for applying colours to vertices/faces (where normalPerVertex corresponds to colorPerVertex and normalIndex corresponds to colorIndex). If the normal field is NULL, the browser shall automatically generate normals, using creaseAngle to determine if and how normals are smoothed across shared vertices (see ISO/IEC 14772-1:1997, section 4.6.3.5, Crease angle field).

If the texCoord field is not NULL, it shall contain a TextureCoordinate node. The texture coordinates in that node are applied to the vertices of the IndexedFaceSet as follows:

1. 
   If the texCoordIndex field is not empty, then it is used to choose texture coordinates for each vertex of the IndexedFaceSet in exactly the same manner that the coordIndex field is used to choose coordinates for each vertex from the Coordinate node. The texCoordIndex field shall contain at least as many indices as the coordIndex field, and shall contain end-of-face markers (-1) in exactly the same places as the coordIndex field. If the greatest index in the texCoordIndex field is N, then there shall be N+1 texture coordinates in the TextureCoordinate node.
   
2. 
   If the texCoordIndex field is empty, then the coordIndex array is used to choose texture coordinates from the TextureCoordinate node. If the greatest index in the coordIndex field is N, then there shall be N+1 texture coordinates in the TextureCoordinate node.
   

If the texCoord field is NULL, a default texture coordinate mapping is calculated using the local coordinate system bounding box of the shape. The longest dimension of the bounding box defines the S coordinates, and the next longest defines the T coordinates. If two or all three dimensions of the bounding box are equal, ties shall be broken by choosing the X, Y, or Z dimension in that order of preference. The value of the S coordinate ranges from 0 to 1, from one end of the bounding box to the other. The T coordinate ranges between 0 and the ratio of the second greatest dimension of the bounding box to the greatest dimension.

Some restrictions specified in ISO/IEC 14496-11 (BIFS), section 7.2.2.66.2

The IndexedFaceSet node represents a 3D polygon mesh formed by constructing faces (polygons) from points specified in the coord field. If the coordIndex field is not NULL, IndexedFaceSet uses the indices in its coordIndex field to specify the polygonal faces by connecting together points from the coord field. An index of -1 shall indicate that the current face has ended and the next one begins. The last face may be followed by a -1. IndexedFaceSet shall be specified in the local coordinate system and shall be affected by parent transformations. The coord field specifies the vertices of the face set and is specified by Coordinate node. If the coordIndex field is not NULL, the indices of the coordIndex field shall be used to specify the faces by connecting together points from the coord field. An index of -1 shall indicate that the current face has ended and the next one begins.

The last face may be followed by a -1. If the coordIndex field is NULL, the vertices of the coord field are laid out in their respective order to specify one face. If the color field is NULL and there is a Material node defined for the Appearance affecting this IndexedFaceSet, then the emissiveColor of the Material node shall be used to draw the faces.

In order to use 3D Mesh Coding (3DMC) with the IndexedFaceSet node, the use3DMeshCoding flag in BIFSv2Config should be set to TRUE, as described in ISO/IEC 14496-11, section 8.5.3.2 This will require every IndexedFaceSet node in that elementary stream to be coded with 3DMC. Note that 3DMC does not support the use of DEF and USE within the fields of IndexedFaceSet. Also, an empty IndexedFaceSet should not be included in a stream where use3DmeshCoding flag is set to TRUE. A scene with both 3DMC coded and BIFS coded IndexedFaceSet nodes can be created by sending the compressed and uncompressed nodes in separate streams.This can be done with an Inline node or by sending separate elementary streams in the same object descriptor. The latter approach has the advantage of keeping the nodes in the same name space, see the example in ISO/IEC 14496-11, section 7.8 (3D Mesh Coding in BIFS scenes).

IndexedLineSet

XSD Description

"IndexedLineSetType">



"xmta:IS" minOccurs="0"/>

"color" form="qualified" minOccurs="0">



"xmta:SFColorNodeType" minOccurs="0" />





"coord" form="qualified" minOccurs="0">



"xmta:SFCoordinateNodeType" minOccurs="0" />







"colorIndex" type="xmta:MFInt32" use="optional"/>

"colorPerVertex" type="xmta:SFBool" use="optional" default="true"

/>

"coordIndex" type="xmta:MFInt32" use="optional"/>

"xmta:DefUseGroup"/>



"IndexedLineSet" type="xmta:IndexedLineSetType"/>

Functionality and semantics

As specified in ISO/IEC 14772-1:1997, section 6.24

The IndexedLineSet node represents a 3D geometry formed by constructing polylines from 3D vertices specified in the coord field. IndexedLineSet uses the indices in its coordIndex field to specify the polylines by connecting vertices from the coord field. An index of "-1" indicates that the current polyline has ended and the next one begins. The last polyline may be (but does not have to be) followed by a "-1". IndexedLineSet is specified in the local coordinate system and is affected by the transformations of its ancestors.

The coord field specifies the 3D vertices of the line set and contains a Coordinate node.

Lines are not lit, are not texture-mapped, and do not participate in collision detection. The width of lines is implementation dependent and each line segment is solid (i.e., not dashed).

If the color field is not NULL, it shall contain a Color node. The colours are applied to the line(s) as follows:

1. 
   If colorPerVertex is FALSE:
   
   1. 
      If the colorIndex field is not empty, one colour is used for each polyline of the IndexedLineSet. There shall be at least as many indices in the colorIndex field as there are polylines in the IndexedLineSet. If the greatest index in the colorIndex field is N, there shall be N+1 colours in the Color node. The colorIndex field shall not contain any negative entries.
      
   2. 
      If the colorIndex field is empty, the colours from the Color node are applied to each polyline of the IndexedLineSet in order. There shall be at least as many colours in the Color node as there are polylines.
      
2. 
   If colorPerVertex is TRUE:
   

1. 
   If the colorIndex field is not empty, colours are applied to each vertex of the IndexedLineSet in exactly the same manner that the coordIndex field is used to supply coordinates for each vertex from the Coordinate node. The colorIndex field shall contain at least as many indices as the coordIndex field and shall contain end-of-polyline markers (-1) in exactly the same places as the coordIndex field. If the greatest index in the colorIndex field is N, there shall be N+1 colours in the Color node.
   
2. 
   If the colorIndex field is empty, the coordIndex field is used to choose colours from the Color node. If the greatest index in the coordIndex field is N, there shall be N+1 colours in the Color node.
   

If the color field is NULL and there is a Material defined for the Appearance affecting this IndexedLineSet, the emissiveColor of the Material shall be used to draw the lines. Details on lighting equations as they affect IndexedLineSet nodes are described in ISO/IEC 14772-1:1997 Section 4.14, Lighting model.