Here's an example of a model rotating around its Y axis using a CSS animation: If a element has an active CSS animation or transition - or if JavaScript is used to modify the CSSOM - the model will automatically render in its new state when the next frame is painted. The scene is re-rendered every animation frame. A visualisation of the WebGL canvas layer overlaying the page content The model is then placed in the scene using the resulting transform matrix and is rendered to the canvas in sync with the element. To render a model, its position, dimensions and transform matrix are resolved by querying the CSSOM while walking down the DOM tree. A THREE.Scene is also created to host the objects and a light source is added to it. The canvas is styled to cover the viewport and its pointer-events property is set to none, allowing underlying DOM nodes to receive events. When the first element is added to the DOM, a THREE.WebGLRenderer is created and the resulting is added to the document. glb) and OBJ (.obj) model formats are currently supported. Loading and rendering of models is actually handled by three.js.Īdding a model to a document is as simple as: The element is simply a placeholder that provides access to the DOM and CSSOM. Unlike most custom elements, doesn't generate any content. My solution was to use a custom element to add models to the DOM. Unfortunately, I couldn't find anything that fitted my requirements, so I had to create something myself.
There are a few projects around that provide the means to embed 3D models into a document, but they all seem to rely on elements, which effectively sandbox the rendered model from other content - using elements in this way was a no-go for me. I spent some time thinking about what my ideal implementation would look like and concluded that, if 3D models were supported natively, they would have to behave just like any other HTML element, flowing with content, be styleable with CSS and - because we're dealing with 3D objects - any transform and perspective values would need to propagate up to the model. Since simulating native support for CSSVR was a success, I decided to try the same thing with 3D models. But what if browsers could display models natively? How would that work? Would CSSVR be more viable? Would having access to 3D models in more traditional web design be useful?
#Sweet home 3d viewer how to
Unfortunately, unless you start building your experience in a framework like a-frame or use WebGL, there's no other way of creating 3D content because browsers have no idea how to deal with a 3D model. Aside from the mathmatical complexities and large resulting DOM trees, constructing 3D scenes and objects from rectangular HTML elements just isn't practical, and is all but useless for creating anything other than primitive shapes. There was, however, an issue with creating 3D content suitable for use in a rich VR experience. It answered almost all of my questions and made me ask some new ones. The CSSVR prototype turned out much better than I'd hoped. The idea of the experiment was to demonstrate how easy it could be for developers to create VR experiences using web standards, if browsers implemented stereoscopic DOM rendering and supported VR media queries.
A few months ago I started looking into the feasibility of enhancing HTML documents for VR using CSS.
0 kommentar(er)
