CSS Integration for Declarative 3D

Jan Sutter, Kristian Sons, Philipp Slusallek

Motivation

A "Typical" XML3D Scene

* camera * light source * default scene material * 2 meshes * 1 visible * 1 hidden * 2 materials * standard material * highlighting material * shared material data * onhover listener to exchange material

Why CSS for Declarative 3D

• Integrate the final web technology into Dec3D
• Decouple style from scene markup (selectors)
• Enable new debugging facilities (CSS Editor and Inspector)
• Reduce the required application logic (:hover)

What we considere "Style" in Dec3D

* Visibility * Material parameters * Light configuration * Camera instrinsic

Visibility

* CSS defines two properties to handle visibility * visibility: _hidden_ hides the element contributes to flow * display: _none_ hides the element completely and reduces size to zero * This makes three states regarding visibility * visiblility: visible; * visiblility: hidden; * display: none; * In 3D graphics we typically have two states: hidden, visible

3D Graphics Visibility using CSS

* Why not tri-state visibility for 3D graphics * visible: rendered and interactive * transparent: not rendered but interactive * hidden: not rendered and non-interactive * Use CSS * visibility: _hidden_ hides the element, still interactive (e.g. onclick) * display: _none_ hides the element completely, no interaction possible (jQuery default for $.hide) * any value except _hidden_ and _none_ makes the object visible

Materials

* Two types of material handling: * Ubershader/Snippet Compositor * Fixed set of predefined material parameters * CSS integration possible with a fixed set of properties with fixed types * Custom shaders * User defined * No fixed set of shader parameters * No fixed types

CSS Custom Properties

CSS Custom Properties for Cascading Variables Module Level 1

* Allows for the definition of custom/arbitrary CSS properties * Have to start with a double hyphen, e.g _--myProperty_ * Properties are variables, e.g _var(--customProperty)_ * No types everything is a string * Types are application's responsibility * Browser will only substitute _var_ statements

Material Definitions using CSS

* We propose one new fixed CSS property: _material-model_ * URL type, e.g. material-model: url("urn:xml3d:shader:phong") * Can be used to specify built-in and custom shaders * Material parameters are specified using custom properties * --vector: vec3(1.0, 2.0, 3.0); * --columMajorMatrix: mat3(1, 2, 3, 4, 5, 6, 7, 8, 9); * --float: 1.2; * --array: [1, 2, 3.0] * --diffuseTexture: url("./tex.png") clamp repeat linear nearest; * No built-in CSS parameters like _color_ or _transparency_ * for consistency reasons * to avoid additional override rules

Example Material Definitions using CSS

```CSS .example { material-model: url("carbon.js"); --scale: 10.0; --rotation: mat2(0, -1, 1, 0); --blackFibers: url("black_fibers.png") repeat repeat; --whiteFibers: url("white_fibers.png") repeat repeat; --mask: url("mask.png") repeat repeat; --normalMap: url("normalMap.png") repeat repeat; } ```

Light Configuration

* Usually we have fixed light types: _point_, _spot_, _directional_ * But we believe that custom light shaders are coming * Like materials one new fixed CSS property: _light-model_ * URL type e.g.: light-model: url("urn:xml3d:light:point") * Can be used to specify built-in and custom light types * Parameters specified using custom properties * --direction: vec3(0.0, 1.0, 1.0); * --intensity: [1, 1, 1]; * --castShadow: true;

Camera Instrinsic

* Typically we have perspective and orthographic cameras * What about fish-eye, stereoscopic, or environment cameras * To not enforce a model we follow the material approach * Again only one fixed property: _camera-model_ * URL type e.g.: camera-model: url("urn:xml3d:camera:perspective") * Can be used to specify built-in and custom camera models * Parameters specified using custom properties * --fov: 75deg; * --clippingPlanes: auto 1000;

Back to our XML3D Scene

Now without Style related Elements

And the related CSS

CSS and Dec3D in Action

Limitations/Obstacles

* No Style Observer for CSS related changes to a dom node * StyleObserver proposal started at http://xml3d.org/xml3d/specification/styleobserver/ * Observing the style is possible using polling and MutationObserver * Currently a plug-in is used for efficiency * No API to **only** query custom CSS Properties * _getComputedStyle_ returns **all** (> 200 properties) * Custom properties have to be filtered using startsWith("--") * Proposal for a new new API will start soon * No API to enable/disable pseudo classes (:hover) * No custom picking/mouse-over on the canvas element * :hover is currently only possible with a plug-in

Conclusion

* First CSS integration for Dec3D * Enables a clear separation of style and scene structure * Unified and generic approach for material, light, and camera * Three fixed properties * material-model * light-model * camera-model * Custom CSS properties for _all_ parameters * no conflicts with existing and future standard properties * gain access to all new features for custom properties in the future (e.g. animations) * Can be implemented already, at least in Firefox

Outlook

• Empirical evaluation of Dec3D accessibility for Web-Devs
• CSS based post-processing (CSS Filter approach?)
• Declarative LOD with CSS and custom media queries
• CSS integration + Web Components

  ≟

  Dec3D as pure JS

Thank you very much for you attention

Any Questions?

EU Future Internet PPP: FI-CONTENT2, FI-WARE, FITMAN