The 15 Essentials of Declarative 3D
In this document we tried to extract the key concepts of DOM-based declarative 3D as aimed by the W3C Community Group “Declarative 3D for the Web Architecture”. Of course most of the concepts can be found in XML3D, some are planned for a future version of XML3D. Thus it’s also a description of the lessons learned over the last years. On the other hand, the concepts are independent from the implementation and many concepts can also be found in X3DOM, either through its foundation X3D, but in many cases through the X3DOM-specific extensions that are not (or not yet) part of X3D.
This extraction must not be understood as manifest, but should server as a basis for discussion on a common “Dec3D” proposal. For this proposal, we should focus on the core functionality and concepts to increase the chance to make progress with our efforts. Agreeing on the essential concepts means that we can
•	incrementally refine each of the concepts 
•	show up implementation alternatives
•	document why we’ve chosen this and not another option

(1)	Start element
Declarative 3D needs a start element that marks the transition point from HTML box layout to 3D transformations. This element itself is integrated in the flow layout and behaves similar to e.g. <canvas> element. 
While it would in principal be possible to have "free floating" HTML objects in any part of a Web page, their current semantics would conflict with a true 3D semantics. For example a CSS 3D transform applied to a 2D object does not give it depth but simply distorts its 2D shape (transform in 3D with projection back to 2D). This is not acceptable for a 3D object. Switching to a separate interpretation within those tags allows us to separate these two interpretations.
While there are currently no plans to directly support 2D objects inside of these objects (that would then be interpreted in a true 3D way), this is an option. 2D-Elements should at least be supported as active "textures" on 3D objects.
(2)	CSS
A good CSS integration is an essential part of declarative 3D. Dec3D should use existing CSS properties where applicable. Good candidates are
•	the “transform” property from the CSS 3D Transforms Working Draft
•	the “opacity” property from the CSS Color Module
•	the “display” property from the CSS Visual Formatting Model
There should be a new CSS module that defines a set of new 3D specific CSS properties that are essential for Dec3D. Like in HTML, the supported CSS properties should make sense for the majority of elements.
(3)	Hierarchy
At least one element that supports grouping, structuring and building of hierarchies of 3D objects is essential. HTML defines a set of similar nodes with slightly differing semantics (<div>, <span>, <section>). Supporting these elements below the <dec3d> element would be an option, having a new element that supports this functionality another option.
In a first phase, we favor a tree hierarchy to reduce the overall complexity and to not introduce issues that came with the SVG graph (e.g. complexity in CSS inheritance). Since most classical non-DOM rendering system support instancing of sub-trees, this is a point to discuss. In any case Dec3D needs functionality to re-use data objects, but this can be handled differently (s. below)
(4)	Transformations
Functionality to link transformations to the scene hierarchy is essential for Dec3D. Using CSS 3D transforms is an obvious choice. The CSS3D transforms format is generic and thus expressive enough to support most Dec3D use-cases. With CSSMatrix, an interface exists that allows to manipulate transformations in an imperative way, CSS Animations and CSS Transitions allow to manipulate transformations in a declarative (and powerful) way. 
In some use-cases, long key-frame animations are needed. Other use-cases do heavy manipulations on hundreds of objects each frame. Using CSS Animations or the CSSMatrix interface for these kinds of applications are beyond their original purpose and might have shortcomings in performance or usability. This can be worked out in a later phase, if it turns out to be a common issue. However, a possible solution should be considered in the design phase.
(5)	Generic container types
It’s essential for Dec3D, to use generic container types to
•	take modern hardware architectures into account 
•	provide a future safe and flexible format
•	prevent inconsistencies  that comes special encoding of attributes with specific semantics
All elements, that can have arbitrary attributes, should be a generic container (e.g. meshes, shader). The attributes itself should be based on TypedArray format.
An entry in a generic container consist of
•	a name that is bound to a functionality in the container type
•	a type (float32, uint16)
•	a tuple size (1,2,3,4,16)
•	an array of values
The type should correspond to the types provided by the TypedArray specification, the values should be accessible as TypedArray and modifiable with a TypedArray-based interface.
(6)	External references
In a typical 3D scene, 95% of the amount of data comes from vertex attributes, index data and other entries of the generic container types. In very few use-cases all this data needs to be available in the DOM. Additionally, the DOM in its current shape is not suitable for large typed data sets. Thus an essential feature of Dec3D is the possibility to externalize this data and to reference it from the scene structure. Having generic data containers, any file format is suitable that maps back to a table of entries in the format explained above. This includes XML and JSON, binary formats (e.g EXI) or new Dec3D specific formats. Important is to support arbitrary entries for generic formats o to define a mapping for formats with fixed semantics (e.g. Stanford’s PLY). 

(7)	Operators on generic data sets
For many use-cases it’s essential to perform operations on the input data. This includes typically geometry operations such as skinning and morphing, texture coordinate generation, animations of shader attributes but also operation such as compression. This cannot be a fixed domain-specific setup but needs to flexible to accommodate new developments but also very different use cases (e.g. normals must be compressed very differently than vertices).
Thus Dec3D needs a way to perform calculation on large data sets in an efficient way. In a first phase, this can be done using fixed operators (c.f. SVG Filter Effects). It could be extended to programmable JS operators in a later phase.
(8)	Shaders
Most of the Dec3D don’t require more shading functionality than given by 2-3 powerful predefined shaders (aka ComposableShader, urn:xml3d:shader:phong). Since predefined shaders don't come with the issue of timing attacks, they provide added-value compared to systems that purely rely on programmable shaders. 
Nevertheless, as demands will increase, the design of Dec3D should keep programmable shaders and/or shader trees in mind to provide higher flexibility in a second phase. A shader tree approach is a nice way to provide flexibility while keeping the functionality within a sandbox. 
Since shader descriptions can be complex and we don’t want to obstruct programmable shaders, the shader description should be based on generic containers. Shaders should be assigned via CSS to the hierarchy. This would require an additional CSS property (e.g. shader).  As default behavior, elements should inherit the shader value from their parent.
An alternative would be to describe the attributes of predefined shaders in CSS or as element, more complex and composed shaders as elements. This is the approach of SVG Filter Effects.
A key problem is to define the interface between vertex attributes supplied through geometry elsewhere and the shader parameters. A clear separation of geometry and material shaders seems to be necessary in order to allow advanced techniques to be used across diffreent rendering algorithms (need to know geometry before calling the shader for RT).
(9)	 Textures
Dec3D should use appropriate elements from HTML to define textures (<img>, <video>, <canvas>) and interactive textures (e.g. <iframe>, <svg>). A key question is the use of HTML as active textures, i.e. some that still allow interacting with the HTML content.
(10)	3D Geometry
The 3D geometry description should be based on generic containers (and thus VBOs). It should support standard primitives as e.g. known from OpenGL (triangles, triStrips, points, lines etc). A geometry element with a specific type has required and optional entries (e.g. <geo type=”triangles”> requires position entry and takes an optional index entry.)
Higher semantic geometry (multi-indexing, boxes etc.) and compressed representations should be solved through operators (s. above).
(11)	 Lights
Though lights are global shader parameters, there should be an intuitive way to specify lights in the scene graph. As for material shaders, Dec3D should provide a set of predefined light types. Anyway, the design should not obstruct the possibility to add programmable solutions (light shader, emmisive shader) in a later phase.
(12)	Viewpoints
There should be a way to define view points in the scene that can be activated through links or through JavaScript. This could be a specific element or the <a id=""> / URL fragment mechanism could be used. If all camera parameters can be derived from the scene hierarchy and CSS, any hierarchy node can serve as a view point and thus as target for a link.
(13)	Camera control
There should be a way to modify the current camera through JavaScript. Pre-defined camera controllers (that is the predefined modification of camera parameters through input events) can be useful, but need to be adapted in many use-cases. Because it’s hard to specify the controller behavior in such a way that it leads to consistent behavior in all implementations, we think this functionality can be postponed to a later phase.
We need to differentiate between the observer pose and that of specific cameras attached to the observer (e.g. stereo and multi-view cameras) that must be manipulated relative to the observer pose.
(14)	 DOM Events
For Dec3D it’s essential to extend existing DOM events with 3D-specific context information (e.g. MouseEvent with 3D  picking information) and to add 3D-specific DOM events (collision, proximity, transformation changes). An extended MouseEvent as already described in the CG Wiki would be sufficient for most use-cases, other events can be postponed.
(15)	 Interfaces & Types
All elements should have WebIDL descriptions that define convenience functions/attributes for access and modification via JavaScript. Also, the definition of a set of types that can be used in element interfaces to access/modify 3D context information would be convenient. The design of the interfaces and types should be aligned with other similar efforts within W3C (e.g. CSS/SVG FX task force)