ISO/PAS 17506:2012

PUBLICLY ISO/PAS
AVAILABLE 17506
SPECIFICATION
First edition
2012-07-15
Industrial automation systems and
integration — COLLADA digital asset
schema specification for 3D visualization
of industrial data
Systèmes d'automatisation industrielle et intégration — Spécifications
du schéma des actifs numériques COLLADA pour la visualisation 3D
des données industrielles
Reference number
©
ISO 2012
©  ISO 2012
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56  CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2012 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
In other circumstances, particularly when there is an urgent market requirement for such documents, a
technical committee may decide to publish other types of document:
 an ISO Publicly Available Specification (ISO/PAS) represents an agreement between technical experts in
an ISO working group and is accepted for publication if it is approved by more than 50 % of the members
of the parent committee casting a vote;
 an ISO Technical Specification (ISO/TS) represents an agreement between the members of a technical
committee and is accepted for publication if it is approved by 2/3 of the members of the committee casting
a vote.
An ISO/PAS or ISO/TS is reviewed after three years in order to decide whether it will be confirmed for a
further three years, revised to become an International Standard, or withdrawn. If the ISO/PAS or ISO/TS is
confirmed, it is reviewed again after a further three years, at which time it must either be transformed into an
International Standard or be withdrawn.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO/PAS 17506 was prepared by the Khronos Group (as COLLADA Digital Asset Schema Release 1.5.0
Specification, April 2008) and was adopted by Technical Committee ISO/TC 184, Automation systems and
integration, Subcommittee SC 4, Industrial data.

PUBLICLY AVAILABLE SPECIFICATION ISO/PAS 17506:2012(E)

Industrial automation systems and integration — COLLADA
digital asset schema specification for 3D visualization of
industrial data
1 Scope
This Publicly Available Specification describes the COLLADA schema. COLLADA is a COLLAborative Design
Activity that defines an XML-based schema to enable 3D authoring applications to freely exchange digital
assets without loss of information, enabling multiple software packages to be combined into extremely
powerful tool chains.
The purpose of this Publicly Available Specification is to provide a specification for the COLLADA schema in
sufficient detail to enable software developers to create tools to process COLLADA resources. In particular, it
is relevant to those who import to or export from digital content creation (DCC) applications, 3D interactive
applications and tool chains, prototyping tools, real-time visualization applications such as those used in the
video game and movie industries, and CAD tools.
This Publicly Available Specification covers the initial design and specifications of the COLLADA schema, as
well as a minimal set of requirements for COLLADA exporters.
2 Requirements
Requirements are indicated using “must” in the following publication (reproduced on the following pages),
which is adopted as a Publicly Available Specification:
COLLADA Digital Asset Schema Release 1.5.0 Specification, April 2008.
Pages i to xii of COLLADA Digital Asset Schema Release 1.5.0 Specification, April 2008, are for information
only.
(Blank page)
2 © ISO 2012 – All rights reserved

COLLADA – Digital Asset Schema Release 1.5.0
Specification
April 2008
Editors: Mark Barnes and Ellen Levy Finch, Sony Computer Entertainment Inc.

© 2005-2008 The Khronos Group Inc., Sony Computer Entertainment Inc.
All Rights Reserved.
This specification is protected by copyright laws and contains material proprietary to the Khronos Group, Inc. It or any
components may not be reproduced, republished, distributed, transmitted, displayed, broadcast, or otherwise
exploited in any manner without the express prior written permission of Khronos Group. You may use this specification
for implementing the functionality therein, without altering or removing any trademark, copyright, or other notice from
the specification, but the receipt or possession of this specification does not convey any rights to reproduce, disclose,
or distribute its contents, or to manufacture, use, or sell anything that it may describe, in whole or in part.
Khronos Group grants express permission to any current Promoter, Contributor, or Adopter member of Khronos to
copy and redistribute UNMODIFIED versions of this specification in any fashion, provided that NO CHARGE is made for
the specification and the latest available update of the specification for any version of the API is used whenever
possible. Such distributed specification may be reformatted AS LONG AS the contents of the specification are not
changed in any way. The specification may be incorporated into a product that is sold as long as such product includes
significant independent work developed by the seller. A link to the current version of this specification on the Khronos
Group website should be included whenever possible with specification distributions.
Khronos Group makes no, and expressly disclaims any, representations or warranties, express or implied, regarding
this specification, including, without limitation, any implied warranties of merchantability or fitness for a particular
purpose or noninfringement of any intellectual property. Khronos Group makes no, and expressly disclaims any,
warranties, express or implied, regarding the correctness, accuracy, completeness, timeliness, and reliability of the
specification. Under no circumstances will the Khronos Group, or any of its Promoters, Contributors, or Members or
their respective partners, officers, directors, employees, agents, or representatives be liable for any damages, whether
direct, indirect, special, or consequential damages for lost revenues, lost profits, or otherwise, arising from or in
connection with these materials.
Khronos is a trademark of The Khronos Group Inc.
COLLADA is a trademark of Sony Computer Entertainment Inc. used by permission by Khronos.
All other trademarks are the property of their respective owners and/or their licensors.

Publication date: April 2008
Khronos Group
P.O. Box 1019
Clearlake Park, CA 95424, U.S.A.

Sony Computer Entertainment Inc.
2-6-21 Minami-Aoyama, Minato-ku,
Tokyo 107-0062 Japan
Sony Computer Entertainment America
919 E. Hillsdale Blvd.
Foster City, CA 94404, U.S.A.
Sony Computer Entertainment Europe
30 Golden Square
London W1F 9LD, U.K.
4 © ISO 2012 – All rights reserved

Table of Contents
About This Manual ix
Audience ix
Content of this Document ix
Typographic Conventions and Notation x
Notation and Organization in the Reference Chapters x
Other Sources of Information xi
Chapter 1: Design Considerations 1-1
Introduction 1-1
Assumptions and Dependencies 1-1
Goals and Guidelines 1-1
Chapter 2: Tool Requirements and Options 2-1
Introduction 2-1
Exporters 2-1
Importers 2-3
Archive Packaging 2-4
Chapter 3: Schema Concepts 3-1
Introduction 3-1
XML Overview 3-1
Address Syntax 3-1
Instantiation and External Referencing 3-5
The Common Profile 3-6
Chapter 4: Programming Guide 4-1
Introduction 4-1
About Parameters in COLLADA 4-1
Curve Interpolation 4-1
Skin Deformation (or Skinning) in COLLADA 4-7
Chapter 5: Core Elements Reference 5-1
Introduction 5-1
Elements by Category 5-1
accessor 5-5
ambient (core) 5-11
animation 5-12
animation_clip 5-15
asset 5-17
bool_array 5-20
camera 5-21
channel 5-23
COLLADA 5-24
color 5-26
contributor 5-27
controller 5-29
control_vertices 5-31
directional 5-33
evaluate_scene 5-34
extra 5-35
float_array 5-37
formula 5-38
geographic_location 5-40
geometry 5-42
IDREF_array 5-44
April 2008
iv   COLLADA – Digital Asset Schema Release 1.5.0
imager 5-45
input (shared) 5-47
input (unshared) 5-50
instance_animation 5-52
instance_camera 5-54
instance_controller 5-56
instance_formula 5-59
instance_geometry 5-61
instance_light 5-63
instance_node 5-65
instance_visual_scene 5-67
int_array 5-69
joints 5-70
library_animation_clips 5-71
library_animations 5-72
library_cameras 5-73
library_controllers 5-74
library_formulas 5-75
library_geometries 5-76
library_lights 5-77
library_nodes 5-78
library_visual_scenes 5-79
light 5-80
lines 5-82
linestrips 5-84
lookat 5-86
matrix 5-88
mesh 5-89
morph 5-92
Name_array 5-94
newparam 5-96
node 5-98
optics 5-100
orthographic 5-102
param (data flow) 5-104
param (reference) 5-105
perspective 5-108
point 5-110
polygons 5-112
polylist 5-115
rotate 5-117
sampler 5-118
scale 5-125
scene 5-126
setparam 5-128
SIDREF_array 5-130
skeleton 5-131
skew 5-133
skin 5-134
source (core) 5-137
spline 5-139
spot 5-141
targets 5-143
technique (core) 5-144
technique_common 5-146
translate 5-147
April 2008
6 © ISO 2012 – All rights reserved

Specification – Table of Contents   v
triangles 5-148
trifans 5-150
tristrips 5-152
vertex_weights 5-154
vertices 5-156
visual_scene 5-157
Chapter 6: Physics Reference 6-1
Introduction 6-1
Elements by Category 6-1
attachment 6-4
box 6-5
capsule 6-6
convex_mesh 6-7
cylinder 6-9
force_field 6-10
instance_force_field 6-11
instance_physics_material 6-12
instance_physics_model 6-13
instance_physics_scene 6-15
instance_rigid_body 6-16
instance_rigid_constraint 6-19
library_force_fields 6-21
library_physics_materials 6-22
library_physics_models 6-23
library_physics_scenes 6-24
physics_material 6-25
physics_model 6-27
physics_scene 6-30
plane 6-33
ref_attachment 6-34
rigid_body 6-35
rigid_constraint 6-39
shape 6-43
sphere 6-45
Chapter 7: Getting Started with FX 7-1
Introduction 7-1
Using Profiles for Platform-Specific Effects 7-1
About Parameters in FX 7-4
Shaders 7-5
Rendering 7-5
Texturing 7-6
Chapter 8: FX Reference 8-1
Introduction 8-1
Elements by Category 8-1
About COLLADA FX 8-4
alpha 8-5
annotate 8-6
argument 8-7
array 8-9
binary 8-11
bind (FX) 8-13
bind_attribute 8-15
bind_material 8-16
bind_uniform 8-19
April 2008
vi   COLLADA – Digital Asset Schema Release 1.5.0
bind_vertex_input 8-21
blinn 8-23
code 8-26
color_clear 8-27
color_target 8-28
compiler 8-30
constant (FX) 8-31
create_2d 8-34
create_3d 8-36
create_cube 8-38
depth_clear 8-40
depth_target 8-41
draw 8-43
effect 8-45
evaluate 8-47
format 8-49
fx_common_color_or_texture_type 8-52
fx_common_float_or_param_type 8-54
fx_sampler_common 8-55
image 8-58
include 8-61
init_from 8-62
instance_effect 8-64
instance_image 8-66
instance_material (geometry) 8-68
instance_material (rendering) 8-70
lambert 8-72
library_effects 8-74
library_images 8-75
library_materials 8-76
linker 8-78
material 8-79
modifier 8-81
pass 8-82
phong 8-84
profile_BRIDGE 8-87
profile_CG 8-89
profile_COMMON 8-92
profile_GLES 8-94
profile_GLES2 8-97
profile_GLSL 8-101
program 8-103
render 8-105
RGB 8-106
sampler1D 8-107
sampler2D 8-108
sampler3D 8-109
samplerCUBE 8-110
samplerDEPTH 8-111
samplerRECT 8-112
sampler_image 8-113
sampler_states 8-114
semantic 8-115
shader 8-116
sources 8-118
states 8-120
April 2008
8 © ISO 2012 – All rights reserved

Specification – Table of Contents   vii
stencil_clear 8-126
stencil_target 8-127
technique (FX) 8-129
technique_hint 8-131
texcombiner 8-132
texenv 8-135
texture_pipeline 8-137
usertype 8-140
Chapter 9: B-Rep Reference 9-1
Introduction 9-1
Elements by Category 9-1
About B-Rep in COLLADA 9-2
brep 9-7
circle 9-9
cone 9-11
curve 9-13
curves 9-15
cylinder (B-Rep) 9-16
edges 9-17
ellipse 9-19
faces 9-21
hyperbola 9-23
line 9-24
nurbs 9-25
nurbs_surface 9-28
orient 9-31
origin 9-32
parabola 9-33
pcurves 9-34
shells 9-36
solids 9-38
surface 9-40
surfaces 9-42
surface_curves 9-43
swept_surface 9-44
torus 9-46
wires 9-47
Complete B-Rep Example 9-49
Chapter 10: Kinematics Reference 10-1
Introduction 10-1
Elements by Category 10-1
articulated_system 10-3
attachment_end 10-5
attachment_full 10-6
attachment_start 10-8
axis_info 10-10
bind (kinematics) 10-13
bind_joint_axis 10-14
bind_kinematics_model 10-16
connect_param (kinematics) 10-18
effector_info 10-19
frame_object, frame_origin, frame_tcp, frame_tip 10-21
instance_articulated_system 10-22
instance_joint 10-24
instance_kinematics_model 10-26
April 2008
viii   COLLADA – Digital Asset Schema Release 1.5.0
instance_kinematics_scene 10-28
joint 10-30
kinematics 10-32
kinematics_model 10-35
kinematics_scene 10-37
library_articulated_systems 10-38
library_joints 10-39
library_kinematics_models 10-40
library_kinematics_scenes 10-41
link 10-42
motion 10-43
prismatic 10-45
revolute 10-47
Chapter 11: Types 11-1
Introduction 11-1
Simple Value Types 11-1
Parameter-Type Elements 11-2
Other Simple Types 11-3
Value-or-Param Types 11-3
Appendix A: COLLADA Example A-1
Example: Cube A-1
Appendix B: Profile GLSL and GLES2 Examples B-1
Example: B-1
Example: B-6
Glossary G-1
General Index I-1
Index of COLLADA Elements I-4
April 2008
10 © ISO 2012 – All rights reserved

About This Manual
This document describes the COLLADA schema. COLLADA is a COLLAborative Design Activity that
defines an XML-based schema to enable 3D authoring applications to freely exchange digital assets
without loss of information, enabling multiple software packages to be combined into extremely powerful
tool chains.
The purpose of this document is to provide a specification for the COLLADA schema in sufficient detail to
enable software developers to create tools to process COLLADA resources. In particular, it is relevant to
those who import to or export from digital content creation (DCC) applications, 3D interactive applications
and tool chains, prototyping tools, real-time visualization applications such as those used in the video game
and movie industries, and CAD tools.
This document covers the initial design and specifications of the COLLADA schema, as well as a minimal
set of requirements for COLLADA exporters. A short example of a COLLADA instance document is
presented in “Appendix A”.
Audience
This document is public. The intended audience is programmers who want to create applications, or plug-
ins for applications, that can utilize the COLLADA schema.
Readers of this document should:
Have knowledge of XML and XML Schema.
® ®
Be familiar with shading languages such as NVIDIA Cg or Pixar RenderMan .
Have a general knowledge and understanding of computer graphics and graphics APIs such as ®
OpenGL .
Content of this Document
This document consists of the following chapters:
Chapter/Section Description
Chapter 1: Design Considerations Issues concerning the COLLADA design.
Chapter 2: Tool Requirements and Options COLLADA tool requirements for implementors.
Chapter 3: Design Considerations A general description of the schema and its design, and introduction
of key concepts necessary for understanding and using COLLADA.
Chapter 4: Programming Guide Detailed instructions for some aspects of programming using
COLLADA.
Chapter 5: Core Elements Reference Detailed reference descriptions of the core elements in the COLLADA
schema.
Chapter 6: Physics Reference Detailed reference descriptions of COLLADA Physics elements.
Chapter 7: Getting Started with FX Concepts and usage notes for COLLADA FX elements.
Chapter 8: FX Reference Detailed reference descriptions of COLLADA FX elements.
Chapter 9: B-Rep Reference Detailed reference descriptions of COLLADA B-Rep elements.
Chapter 10: Kinematics Reference Detailed reference descriptions of COLLADA Kinematics elements.
Chapter 11: Types Definitions of some simple COLLADA types.
Appendix A: COLLADA Example An example COLLADA instance document.
Appendix B: Profile GLSL and GLES2 Example A detailed example of the COLLADA FX element.
Glossary Definitions of terms used in this document, including XML terminology.
April 2008
x   COLLADA – Digital Asset Schema Release 1.5.0
Chapter/Section Description
General Index Index of concepts and key terms.
Index of COLLADA Elements Index to all COLLADA elements, including minor elements that do not
have their own reference pages.
Typographic Conventions and Notation
Certain typographic conventions are used throughout this manual to clarify the meaning of the text:
Conventions Description
Regular text Descriptive text

XML elements
Courier-type font
Attribute names
Courier bold
File names
blue Hyperlinks
Italic text New terms or emphasis
Italic Courier
Placeholders for values in commands or code
element1 / element2 element1 is the parent, element2 is the child; for further information, refer to “Xpath
Syntax” at http://www.w3schools.com/xpath/xpath_syntax.asp
Notation and Organization in the Reference Chapters
The schema reference chapters describe each feature of the COLLADA schema syntax. Each XML element
in the schema has the following sections:
Section Description
Introduction Name and purpose of the element
Concepts Background and rationale for the element
Attributes Attributes applicable to the element
Related Elements Lists of parent elements and of other related elements
Child Elements Lists of valid child elements and descriptions of each
Details Information concerning the usage of the element
Example Example usage of the element
Child Element Conventions
The Child Elements table lists all child elements for the specified element. For each child:
“See main entry” means that one of the Reference chapters has a main entry for the child element,
so refer to it for details about the child’s usage, attributes, and children.
If there is not a main entry in the Reference chapters, or if the local child element’s properties vary
from the main entry, information about the child element is given either in the Child Elements table
or in an additional element-specific subsection.
For example:
Name/example Description Default Occurrences

Brief_description.  1 or more
(This means that there is a main Reference entry for
camera, so look there for details.)
Brief_description.
(means not
(This means that details are given here but in a
applicable)
separate table.)
April 2008
12 © ISO 2012 – All rights reserved

Specification – About This Manual   xi
Name/example Description Default Occurrences

Description, including discussion of attributes, None (italic
content, and relevant child elements. lowercase
means none
(This means that there is no main Reference entry
assigned)
for yfov. Details are given here.)
NONE (means
the value NONE)
Child Element Order
XML allows a schema definition to include notation that requires elements to occur in a certain order within
their parent element. When this reference states that child elements must appear in the following order, it
refers to a declaration similar to the following, in which the XML element states that
must follow :




XML also provides notation indicating that two or more child elements can occur in any order. When this
reference states that two child elements can appear in any order, it refers to the XML element
with an unbounded maximum. For example, in the following, and must appear
before and after , but in that position, they can occur in any order, and the unbounded
attribute specifies that you can include as many of them as needed in any combination:








Other Sources of Information
Resources that serve as reference background material for this document include:
® ®
Be familiar with shading languages such as NVIDIA Cg or Pixar RenderMan .
Have a general knowledge and understanding of computer graphics and graphics APIs such as ®
OpenGL .
Collada: Sailing the Gulf of 3d Digital Content Creation by Remi Arnaud and Mark C. Barnes; AK
Peters, Ltd., August 30, 2006; ISBN-13: 978-1568812878
Extensible Markup Language (XML) 1.0, 2nd Edition
XML Schema
XML Base
XML Path Language
XML Pointer Language Framework
Extensible 3D (X3D™) encodings ISO/IEC FCD 19776-1:200x ®
Softimage dotXSI™ FTK ®
NVIDIA Cg Toolkit ®
Pixar’s RenderMan
April 2008
xii   COLLADA – Digital Asset Schema Release 1.5.0
For more information on COLLADA, visit:
www.khronos.org/collada
http://collada.org
April 2008
14 © ISO 2012 – All rights reserved

Chapter 1:
Design Considerations
Introduction
Development of the COLLADA Digital Asset Exchange schema involves designers and software engineers
from many companies in a collaborative design activity. This chapter reviews the more important design
goals, thoughts, and assumptions made by the designers during the inception of the project.
Assumptions and Dependencies
During the first design phase of COLLADA, the contributors discussed and agreed on the following
assumptions:
• This is not a game engine or run-time delivery format. We assume that COLLADA will be beneficial
to users of authoring tools and to content-creation pipelines for interactive applications. We assume
that most interactive applications will use COLLADA in the production pipeline, but not as a final
delivery mechanism. For example, most games will use proprietary, size-optimized, streaming-
friendly binary files.
• Artists and end users will want to quickly develop and test relatively simple content and test models
that still include advanced rendering techniques such as vertex and pixel programs (shaders). We
assume that rapid prototyping of content is important to artists and developers and that a human-
readable, text-based format, along with the ability to create valid “empty” or partial content, is
essential.
Goals and Guidelines
Design goals for the COLLADA Digital Asset Exchange schema include the following:
• To liberate digital assets from proprietary binary formats into a well-specified, XML-based, royalty-
free, open-standard format.
• To provide a standard common language format so that COLLADA assets can be used directly in
existing content tool-chains, and to facilitate this integration.
• To be adopted by as many digital-content users as possible.
• To provide an easy integration mechanism that enables all the data to be available through
COLLADA.
• To be a basis for common data exchange among 3D applications.
• To be a catalyst for digital-asset schema design among developers and DCC, hardware, and
middleware vendors.
The following subsections explain the goals and discuss their consequences and rationales.
Liberate Digital Assets from Proprietary Binary Formats
Goal: To liberate digital assets from proprietary binary formats into a well-specified, XML-based, royalty
free, open-standard format.
Digital assets are the most valuable artifact for most 3D application users.
April 2008
1-2   COLLADA – Digital Asset Schema Release 1.5.0
Developers have enormous investment in assets that are stored in opaque proprietary formats. Exporting
the data from the tools requires considerable investment to develop software for proprietary, complex
software development kits. Even after this investment has been made, it is still impossible to modify the
data outside of the tool and import it again later. It is necessary to permanently update the exporters with
the ever-evolving tools, with the risk of seeing the data become obsolete.
Hardware vendors need increasingly more-complex assets to take advantage of new hardware. The data
needed may exist inside a tool, but there is often no way to export this data from the tool. Or exporting this
data is a complex process that is a barrier to developers using advanced features, and a problem for
hardware vendors in promoting new products.
Middleware and tool vendors have to integrate with every tool chain to be able to be used by developers,
which is an impossible mission. Successful middleware vendors have to provide their own extensible tool
chain and framework, and have to convince developers to adopt it. That makes it impossible for developers
to use several middleware tools in the same project, just as it is difficult to use several DCC tools in the
same project.
This goal led to several decisions, including:
• COLLADA will use XML.
XML provides a well-defined framework for structured content. Issues such as character sets
(ASCII, Unicode, shift-jis) are already covered by the XML standard, making any schema that uses
XML instantly internationally useful. XML is also fairly easy to understand given only a sample
instance document and no documentation, something that is rarely true for other formats. There are
XML parsers and text editors for nearly every language on every platform, making the documents
easily accessible to almost any application.
• COLLADA will not use binary data inside XML.
Some discussion often occurs about storing vertices and animation data in some kind of binary
representation for ease of loading, speed, and reduced asset size. Unfortunately, that goes counter
to the desire of being useful to the most number of users on development teams. Furthermore,
storing binary data within XML documents is problematic and well supported only using a base-64
encoding that contrarily increases the size of the data. Keeping COLLADA completely text based
supports the most options. COLLADA does provide mechanisms to store external binary data and
to reference it from a COLLADA asset.
• The COLLADA common profile will expand over time to include as much common data as possible.
Provide a Standard Common Language Format
Goal: To provide a standard common language format so that COLLADA assets can be used directly in
existing content tool-chains, and to facilitate this integration.
This goal led to the COMMON profile. The intent is that, if a user’s tools can read a COLLADA asset and
use the data presented by the common profile, the user should be able to use any DCC tool for content
creation.
To facilitate the integration of COLLADA assets into tool chains, it appears that COLLADA must provide not
only a schema and a specification, but also a well-designed API (a COLLADA API) that helps integrate
COLLADA assets in existing tool chains. This new axis of development can open numerous new
possibilities, as well as provide a substantial saving for developers. Its design has to be such as to facilitate
its integration with specific data structures used by existing content tool chains.
COLLADA can enable the development of numerous tools that can be organized in a tool-chain to create a
professional content pipeline. COLLADA will facilitate the design of a large number of specialized tools,
rather than a monolithic, hard-to-maintain tool chain. Better reuse of tools developed internally or externally
will provide economic and technical advantages to developers and tools/middleware providers, and
therefore strengthen COLLADA as a standard language for digital-asset exchange.
April 2008
16 © ISO 2012 – All rights reserved

Specification – Design Considerations   1-3
Be Adopted by Many Digital-Content Users
Goal: To be adopted by as many digital-content users as possible.
To be adopted, COLLADA needs to be useful to artists and developers. For a developer to measure the
utility of COLLADA to their problem, we need to provide the developer with the right information and enable
the measurement of the quality of COLLADA tools. This includes:
• Provide a conformance test suite to measure the level of conformance and quality of tools.
• Provide a list of requirements in the specification for the tool providers to follow in order to be useful
to most developers. (These goals are specified in the Chapter 2: 3Tool Requirements and Options.)
• Collect feedback from users and add it to the requirements and conformance test suite.
• Manage bug-reporting problems and implementation questions to the public. This involves
prioritizing bugs and scheduling fixes among the COLLADA partners.
• Facilitate asset-exchange and asset-management solutions.
• Engage DCC tool and middleware vendors to directly support COLLADA exporters, importers, and
other tools.
Developers win because they can now use every package in their pipeline. Tool vendors win
because they have the opportunity to reach more users.
• Provide a command-line interface to DCC tool exporters and importers so that those tasks can be
incorporated into an automated build process.
Provide an Easy Integration Mechanism
Goal: To provide an easy integration mechanism that enables all the data to be available through
COLLADA.
COLLADA is fully extensible, so it is possible for developers to adapt COLLADA to their specific needs. This
leads to the following goals:
• Design the COLLADA API and future enhancements to COLLADA to ease the extension process by
making full use of XML schema capabilities and rapid code generation.
• Encourage DCC vendors to make exporters and importers that can be easily extended.
• If developers need functionality that is not yet ready to be in the COMMON profile, encourage
vendors to add this functionality as a vendor-specific extension to their exporters and importers.
This applies to tools-specific information, such as undo stack, or to concepts that are still in the
consideration for inclusion in COLLADA, but that are urgently needed, such as complex shaders.
• Collect this information and lead the working group to solve the problem in the COMMON profile for
the next version of COLLADA.
Make COLLADA asset-management friendly:
• For example, select a part of the data in a DCC tool and export it as a specific asset.
• Enable asset identification and have the correct metadata.
• Enforce the asset metadata usage in exporters and importers.
Serve as Basis for Common Data Exchange
Goal: To be a basis for common data exchange among 3D applications.
The biggest consequence of this goal is that the COLLADA common profile will be an ongoing exercise.
Originally, it covered polygon-based models, materials and shaders, and some animations and DAG-based
scene graphs. In the future it will cover other more complex data types in a common way that makes
exchanging that information among tools a possibility.
April 2008
1-4   COLLADA – Digital Asset Schema Release 1.5.0
Catalyze Digital Asset Schema Design
Goal: To be a catalyst for digital-asset schema design among developers and DCC, hardware, and
middleware vendors.
There is fierce competition among and within market segments: the DCC vendors, the hardware vendors,
and the middleware vendors. But all of them need to communicate to solve the digital-content problems for
developers. Not being able to collaborate on a common digital-asset language format has a direct impact
on the overall optimization of the market solutions:
• Hardware vendors are suffering from the lack of features exposed by DCC tools.
• Middleware vendors suffer because they lack compatibility among the tool chains.
• DCC vendors suffer from the amount of support and specific development required to make
developers happy.
• Developers suffer by the huge amount of investment necessary to create a working tool-chain.
None of these actors can lead the design of a common language format, without being seen by the others
as factoring a commercial or technical advantage into the design. No one can provide the goals that will
make everybody happy, but it is necessary that everybody accept the format. It is necessary for all major
actors to be happy with the design of this format for it to have wide adoption and be accepted.
Sony Computer Entertainment (SCE), because of its leadership in the videogame industry, was the right
catalyst to make this collaboration happen. SCE has a history of neutrality toward tool vendors and game
developers in its middleware and developer programs, and can bring this to the table, as well as its desire
to raise the bar of quality and quantity of content for the next-generation platforms.
The goal is not for SCE to always drive this effort, but to delegate completely this leadership role to the rest
of the actors and partners when the time becomes appropriate. Note that:
• Doing this too early will have the negative effect of partners who will feel that SCE is abandoning
COLLADA.
• Doing this too late will prevent more external involvement and long-term investment from
companies concerned that SCE has too much control over COLLADA.

April 2008
18 © ISO 2012 – All rights reserved

Chapter 2:
Tool Requirements and Options
Introduction
Any fully compliant COLLADA tool must support the entire specification of data represented in the schema.
What may not be so obvious is the need to require more than just adherence to the schema specification.
Some such additional needs are the uniform interpretation of values, the necessity of offering crucial user-
configurable options, and details on how to incorporate additional discretionary features into tools. The goal
of this chapter is to prioritize those issues.
Each “Requirements” section details options that must be implemented completely by every compliant tool.
One exception to this rule is when the specified information is not available within a particular application.
An example is a tool that does not support layers, so it would not be required to export layer information
(assuming that the export of such layer information is normally required); however, every tool that did
support layers would be required to export them properly.
The “Optional” section describes options and mechanisms for things that are not necessary to implement
but that probably would be valuable for some subset of anticipated users as advanced or esoteric options.
The requirements explored in this chapter are placed on tools to ensure quality and conformance to the
purpose of COLLADA. These critical data interpretations and options aim to satisfy interoperability and
configurability needs of cross-platform application-development pipelines. Ambiguity in interpretation or
omission of essential options could greatly limit the benefit and utility to be gained by using COLLADA. This
section has been written to minimize such shortcomings.
Each feature required in this section is tested by one or more test cases in the COLLADA Conformance
Test Suite. The COLLADA Conformance Test Suite, under development by The Khronos Group, is a set of
® ®
tools that automate the testing of exporters and importers for applications such as Maya , XSI , and 3ds ®
Max . Each test case compares the native content against that content after it has gone through the tool’s
COLLADA import/export plug-in.
Exporters
Scope
The responsibility of a COLLADA exporter is to write all the specified data according to certain essential
options.
Requirements
Hierarchy and Transforms
Data Must be possible to export
Translation Translations
Scaling Scales
Rotation Rotations
Parenting Parent relationships
Static object instantiation Instances of static objects. Such an object can have multiple transforms
Animated object instantiation Instances of animated objects. Such an object can have multiple transforms
Skewing Skews
April 2008
2-2   COLLADA – Digital Asset Schema Release 1.5.0
Data Must be possible to export
Transparency / reflectivity Additional material parameters for transparency and reflectivity
Texture-mapping method A texture-mapping method (cylindrical, spherical, etc.)
Transform with no geometry It must be possible to transform something with no geometry (for example,
locator, NULL)
Materials and Textures
Data Must be possible to export
RGB textures An arbitrary number of RGB textures
RGBA textures An arbitrary number of RGBA textures
Baked procedural texture coordinates Baked procedural texture coordinates
Common profile material A common profile material (PHONG, LAMBERT, etc.)
Per-face material Per-primitive materials
Vertex Attributes
Data Must be possible to export
Vertex texture coordinates An arbitrary number of Texture Coordinates per vertex
Vertex normals Vertex normals
Vertex binormals Vertex binormals
Vertex tangents Vertex tangents
Vertex UV coordinates Vertex UV coordinates (distinct from texture coordinates)
Vertex colors Vertex colors
Custom vertex attributes Custom vertex attributes
Animation
All of the following kinds of animations (that don’t specifically state otherwise) must be able to be exported
using samples or key frames (according to a user-specified option).
Animations are usually represented in an application by the use of sparse key frames and complex controls
and constraints. These are combined by the application when the animation is played, providing final
output. When parsing animation data, it is possible that an application will not be able to implement the full
set of constraints or controllers used by the tool that exported the data, and thus the resulting animation
will not be preserved. Therefore, it is necessary to provide an option to export fully resolved transformation
data at regularly defined intervals. The sample rate must be specifiable by the user when samples are
preferred to key frames.
Exporting all available animated parameters is necessary. This includes:
Material parameters
Texture parameters
UV placement parameters
Light parameters
Camera parameters
Shader parameters
Global environm ent parameters
Mesh-construction parameters
Node parameters
User parameters
April 2008
20 © ISO 2012 – All rights reserved

Specification – Tool Requirements and Options   2-3
Scene Data
Data Must be possible to export
Empty nodes Empty nodes
Cameras Cameras
Spotlights Spotlights
Directional lights Directional lights
Point lights Point lights
Ambient lights Ambient lights
Exporter User Interface Options
Data Must be possible to export
Export triangle list Triangle lists
Export polygon list Polygon lists
Bake matrices Baked matrices
Single element An instance document that contains only a single element for
each node. (See the following “Single Element Option” discussion.)
COLLADA allows transforms to be represented by a stack of different transformation element types, which
must be composed in the specified order. This representation is useful for accurate storage and/or
interchange of transformations in the case where an application internally uses separate transformation
stages. However, if this is implemented by an application, it should be provided as a user option, retaining
the ability to store only a single baked .
A side effect of this requirement is that any other data that target specific elements inside a transformation
stack (such as animation) must target the matrix instead.
It must be possible to run the full-featured exporter entirely from a command-line interface. This
requirement’s purpose is to preclude exporters that demand user interaction. Of course, a helpful
interactive user interface is still desirable, but interactivity must be optional (as opposed to necessary).
Optional
An exporter may add any new data.
An exporter may export shaders (for example: Cg, GLSL, HLSL).
Importers
Scope
The responsibility of a COLLADA importer is to read all the specified data according to certain essential
options.
In general, importers should provide perfect inverse functions of everything that a corresponding exporter
does. Importers must provide the inverse function operation of every export option described in the
“Exporters” section where it is possible to do so. This section describes only issues where the requirements
placed on importers diverge or need clarification from the obvious inverse method of exporters.
April 2008
2-4   COLLADA – Digital Asset Schema Release 1.5.0
Requirements
It must be possible to import all conforming COLLADA data, even if some data is not understood by the
tool, and retained for later export. The element will be used by external tools to r
...