[X3D-Public] Fwd: Re: [X3D] X3D HTML5 meeting discussions: Declarative 3D interest group at W3C

[Chris Marrin]

On Jan 5, 2011, at 3:43 PM, Johannes Behr wrote:

>>> ...
>>> No question about this. The nodes will be in the DOM. This is one of the core ideas of this interest group.
>>> The question is only, if this nodes represent a Tree or a DAG.
>>> HTML uses the DOM as Tree, SVG as DAG. Both work today in almost every browser.
>> 
>> That is what I was going to say. SVG has <defs> and <use>. I have not looked at the WebKit SVG code to see how invasive supporting this is. I assume there is some logic for detecting loops, but there should also be some "per rendered instance" data storage issues that had to be solved.  Therefore I think supporting a DAG construct must already be there, although some rework might be required to make it more general than just SVG.
> 
> There is this essential requirement for reusing data in 3D. This is really unique in some form. Reusing data inside of your scene is one solution but
> maybe we have to step back and see this in a much broader scope to work with more external references to even include binary and stream-able 3D-items. 

I don't think reuse is unique to 3D, nor is transformation hierarchy. SVG does both of these things today. And with CSS Transforms, HTML now has a legitimate transformation hierarchy. We had to solve all the problems a normal 3D scene graph would: picking, matrix caching, view-volume culling, etc. Adding 3D nodes to the browser leverages the transformation hierarchy bits and we can generalize the reuse (if not already done).

Binary representation and streaming are separate technology, not specific to 3D. So they should be separate.

> ...
>> All of the examples on the front page of the X3DOM site seem like a good starting point. 
> 
> This is really a mix of show-cases from people using the system today. 
> We really try to evolve the idea by providing a runtime to users. This is the best way to get new and interesting use-cases and requirements.   
> Thanks to WebGL and fast JS runtimes we can prototype the feature really quickly. 

And it's clear that they can be done with existing technology, given that they are all built on top of WebGL. The next question is where are the bottlenecks in those examples? What needs to be added to make them faster, easier to produce and less hacky? I think some have been identified: access to CSS style changes, faster hierarchy traversal, and more efficient picking. Understanding the development process for these examples would expose more...

-----
~Chris
chris at marrin.com