Renderer ideas and brainstorming

As far as rendering DOM, the DOM renderer really doesn’t have to do much – it doesn’t have to do matrix calculations down each branch of the graph at all because that is taken care of by the browser when using the nested DOM approach. All the renderer has to do is pass modified transforms from Motor scene graph to the DOM.

For the WebGL renderer, we do have to multiply transforms down the graph ourselves, after the modified transforms in the Motor scene graph have been transferred to the renderer (or, maybe the renderer just uses the Motor scene graph).

Due to the fact that DOM transforms have an intermediary string format (:frowning:), we have to pass transforms from the Motor scene graph to the DOM scene graph by converting to strings. But since WebGL has no scene graph, the Motor scene graph can be shared directly with the WebGL renderer instead of that renderer having it’s own tree structure. The WebGL renderer simply reads our scene graph.

It would make sense for transforms to be shared across renderers if at all possible.

Thing is, if GL is being provided by a third party library, it’s just going to compute its own transforms for everything (at least without heavy modification or some crazy tricks). Not optimal from a performance standpoint, but at least it’s simple.

It won’t be long before we can pass numerical matrices to DOM (hopefully)! See DOMMatrix and