collada extensions process - khronos group

© Copyright Khronos Group, 2010 -

Extensions ProcessRémi ArnaudChief Software Architect, Screampoint Intl.

Mark BarnesSr Software Architect, Biodroid Productions Lda.COLLADA Work Group Chairman, The Khronos Group


Agenda

COLLADA usage model

COLLADA extension mechanism

Extensions by example

NEW - Khronos WG COLLADA extension process

Questions?


COLLADA extensions usage model

COLLADA users required extensions

o project/user specific meta data carried from DCC to Application

“Export user defined properties of Max nodes into an extra element of the corresponding COLLADA node” – openCOLLADA

Max/Maya plug-ins.

COLLADA tool vendors required extensions

o tool can refine COLLADA definition with additional parameters

“Camera XSI extension extends the COLLADA common representation”

https://collada.org/mediawiki/index.php/Camera_XSI_extension

o tool want to provide an alternative representation – Alternative shader languages (Cg, GLSL, HLSL…)

Renderman shader code as alternative <effect> http://www.cs.utexas.edu/ftp/pub/techreports/honor_theses/cs-06-24-

whiteford.pdf

o using COLLADA as a tool native format – extensions replacing proprietary format

“COLLADA is the basis format of LightWave CORE™ , with extensions added by the NewTek engineering team.”

http://www.newtek.com/lightwave/core/


COLLADA extensibility model

COLLADA is a declarative data model

Schema includes extensions mechanisms

Adding

Declarations represent new features

Replacing

Declarations represent alternative techniques (descriptions)

Combining

Adding and Replacing recursively


Extension Mechanisms

<technique> profiles

Replace one description with another

Choose the best profile

<extra> types

Add declarations to most everything

A bag of techniques

Adding choices can be recursive

<input> semantics

Add new streams to data flows


COLLADA <extra> extension mechanism

<extra>

<technique profile=“VENDOR-TAG">

< …

</technique>

</extra>

Rules:

<extra> authorized only at strategic places

Rule: Ignoring ALL extra must be safe


COLLADA <input> extension mechanism

<mesh>

<source id=“position” ….. />

<source id=“texcoord” … />

<source id=“temperature_data” … />

<vertices id=“vx”>

<input semantic=“POSITION” source=“#position”/>

</vertices>

<lines> or <polygons> or <triangles> primitive choice

<input semantic=“VERTEX” source=“#vx” offset=“0” />

<input semantic=“TEXCOORD” source=“#texcoord” offset=“1” />

<input semantic=“TEMPERATURE” source=“# temperature_data” offset=“2 />

<p>0 0 0 1 1 0 … …. </p>

Standard semantics defined in COLLADA spec. 5-40


Extension rules – COLLADA spec. 3-6


Example Extension - bump

…

<coverageU>1</coverageU>

<coverageV>1</coverageV>

<translateFrameU>0</translateFrameU>

<translateFrameV>0</translateFrameV>

<rotateFrame>0</rotateFrame>

<stagger>0</stagger>

<fast>0</fast>

<repeatU>1</repeatU>

<repeatV>1</repeatV>

…..

</technique>

<technique profile="MAX3D">

<amount>0.1</amount>

<bumpInterp>1</bumpInterp>

</technique>

</extra>

</texture>

</bump>

</technique>

</extra>

</technique>

</profile_COMMON>

</effect>

<effect id="Asset-fx-02">

<profile_COMMON>

...

<technique>

<phong>

<emission><color>0 0 0 1</color></emission>

<ambient><color>0 0 0 1</color></ambient>

<diffuse><texture texture="diffuse-sampl" texcoord="TEX0"/></diffuse>

<specular><texture texture="specular-sampl" texcoord="TEX0"/></specular>

<shininess><float>8.0</float></shininess>

<reflective><color>0 0 0 1</color></reflective>

<reflectivity><float>0</float></reflectivity>

<transparent><color>0 0 0 1</color></transparent>

<transparency><float>1</float></transparency>

<index_of_refraction><float>0</float></index_of_refraction>

</phong>

<extra>

<technique profile="FCOLLADA">

<bump>

<texture texture="normal-sampler-02" texcoord="TEX0">

<extra>

<technique profile="MAYA">

<wrapU>1</wrapU>

<wrapV>1</wrapV>

<mirrorU>0</mirrorU>

<mirrorV>0</mirrorV>

…


Example Extension - bump

<effect id="Asset-fx-02">

<profile_COMMON>

...

<technique>

<phong>

<emission><color>0 0 0 1</color></emission>

<ambient><color>0 0 0 1</color></ambient>

<diffuse><texture texture="diffuse-sampl" texcoord="TEX0"/></diffuse>

<specular><texture texture="specular-sampl" texcoord="TEX0"/></specular>

<shininess><float>8.0</float></shininess>

<reflective><color>0 0 0 1</color></reflective>

<reflectivity><float>0</float></reflectivity>

<transparent><color>0 0 0 1</color></transparent>

<transparency><float>1</float></transparency>

<index_of_refraction><float>0</float></index_of_refraction>

</phong>

<extra>

<technique profile="FCOLLADA">

<bump>

<texture texture="normal-sampler-02" texcoord="TEX0">

<extra>

<technique profile="MAYA">

<wrapU>1</wrapU>

<wrapV>1</wrapV>

<mirrorU>0</mirrorU>

<mirrorV>0</mirrorV>

…

…

<coverageU>1</coverageU>

<coverageV>1</coverageV>

<translateFrameU>0</translateFrameU>

<translateFrameV>0</translateFrameV>

<rotateFrame>0</rotateFrame>

<stagger>0</stagger>

<fast>0</fast>

<repeatU>1</repeatU>

<repeatV>1</repeatV>

…..

</technique>


<amount>0.1</amount>

<bumpInterp>1</bumpInterp>

</technique>

</extra>

</texture>

</bump>

</technique>

</extra>

</technique>

</profile_COMMON>

</effect>


<node id="LOD78" name="LOD">

<node id="Model183" name="Model">

<instance_geometry url="#MESH_Model183">

…

</instance_geometry>

</node>



….


</node>

….

<extra>

<technique profile="Maya">

<dynamic_attributes>

<lodNode short_name="lodNode" type="bool">true</lodNode>

<lodCenter short_name="lodCenter" type="float3">0 0 0</lodCenter>

<lodDistance short_name="lodDistance" type="float">10.000000</lodDistance>

…

</dynamic_attributes>

</technique>

</extra>

</node>

Example Extension - LOD

Ignoring <extra> resultin flickering (z-fighting)


Example improved LOD extension

<node id="LOD78" name="LOD">



…


</node>

<extra>

<technique profile="Maya">

<dynamic_attributes>

<lodNode short_name="lodNode" type="bool">true</lodNode>

<lodCenter short_name="lodCenter" type="float3">0 0 0</lodCenter>



….


</node>

<lodDistance short_name="lodDistance" type="float">10.000000</lodDistance>

…

</dynamic_attributes>

</technique>

</extra>

</node>

Ignoring <extra> results in a single LOD loading


Need for multi-vendor extensions

http://www.okino.com/conv/exp_collada_extensions.htm

<extra>

<technique profile="GOOGLEEARTH">

<double_sided>1</double_sided>

</technique>

<technique profile="OKINO">


</technique>



</technique>

</extra>

!!!


COLLADA Extension Process Summary

Visit https://collada.org/mediawiki/index.php/Portal:Extensions_directory

Determine if you need to create an extension

Create your extension by following the guidelines

Submit draft to COLLADA work group for review

Get feedback from the COLLADA specification working group

Receive “Published” stamp of approval

https://collada.org/mediawiki/index.php/Portal:Extensions_directory


Vis

it


Cre

ate


Is there already an extension that does what I want?

• Can it be used instead of writing a new one?

• reuse of an existing specification

• or promoting single-vendor COLLADA extensions to multi-vendor or Khronos-approved status.

• ask the COLLADA Working Group chair whether anyone has already defined related functionality.

[email protected]


Should the extension be Khronos-approved, multi-vendor, or single vendor?

• If the functionality being designed is going to be used by multiple applications - as most will - it's a good

idea to agree on a single extension with other developers - this makes it easier for vendors to justify

development of the extensions, and better interoperability for end-users.

• If the functionality is well-understood, it may be appropriate to define a Khronos-approved extension. This

is the most "blessed" category of extension; it goes through the entire standards process, and is approved by

the working group, but remains optional functionality.

• Khronos-approved extensions are IP-safe, royalty-free licence. Khronos contributing members can obtain

Khronos-approved extensions. Vendor or multi-vendor extensions may not be. Khronos-approved

extensions are as good as features added to the specification, it is a fast path for adding features to future

specifications.

• Some extensions may have to remain proprietary and would therefore not be published. This process is still

useful to designers of proprietary extensions however.


De

term

ine


Ex

am

ple

https://collada.org/mediawiki/index.php/Morph_weights_EXT_extension


Questions?

collada extensions process - khronos group

Documents