[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] A Declarative node set for WebGL?



Here is my response to the post from Johannes:

On Feb 24, 2010, at 9:17 AM, Johannes Behr wrote:

> Hi Cris,
>> ...
>> Designing 3D as elements in the DOM would have tons of resources available that VRML and X3D did not have. Not only a scripting language and DOM, but CSS (including CSS Animation) an event model, XHR, Image loading and caching, video/audio, application cache and web workers, just to name a few. 
> 
> Again. I agree with most points. All this UA-feature, event model and even CSS Animation, should be available for (X)3D authors. 
> 
> However, I would at least provide a node or mechanics to include external 3D subtrees. The X3D-Inline node does this automatically. 
> 3D models tend to be huge compared to usually HTML-pages and we need a mechanism to partition and progressive load subparts.  You can, also with X3DOM today, use multiple XHR and extent your DOM but this has two major drawbacks.
> First It makes the handling of large data-files complicated since subparts can not automatically and progressive load further parts and second, forces the UA to push every polygon through the DOM structure. The Inline node gives the UA the freedom to download and optimize the subtree as needed. 

One way or another we have to solve the problem of getting large datasets into the tree. Hopefully the ArrayBuffer proposal that is gaining some traction can help there. If a large data set can be dropped into a node all at once I don't think going through the DOM will be an issue.

> 
> How someone would address and manipulate those scene-parts is another topic (and experimentally solved in X3DOM)
> 
>> Just look at CSS Animation alone. It adds a 4x4 homogeneous matrix and the ability to animate it (as well as animating colors, opacity, and other CSS properties). This eliminates the need for transforms and the entire set of X3D interpolators.
> 
> I agree that we need some declarative method for animation and transition. The UA should be able to calculate the relevant results and not the app-devloper should be forced to do everything in javascript. 
> However, at least I can not see that every functionality (e.g. CoordinateInterpolator) can be done bey CSS Animation right now.
> But maybe It could be extended to handle all aspects. ROUTEs ( and "Data Flow" programming in general) are a powerful concept but far away from everything you have in HTML

Yes, CoordinateInterpolation is an issue. I don't think VRML style routing belongs in a browser node set. The browser has other ways to do that.

> 
>> 
>> So what nodes would you need? You'd of course need a structural node (groups), transformable via CSS. You'd need a representation of mesh data and a set of material nodes to apply colors, textures and lighting. This could be a very simple set of nodes if you do what we did in WebGL, support only shader based materials. So you'd maybe just need a few nodes to define a set of shaders and the parameters sent to them (probably CSS based).
> 
> I totally disagree. Using concrete GLSL (or HLSL/CG) shaders in a environment which should evolve and stay for years is not a good idea at all. It works nice e.g. in games which have a fix target hardware (class) and very short lifecycle but for HTML we need a better abstraction. 

For better or worse WebGL has gone down the road of direct GLSL support. I think it's important to stay on that road.

> 
> 1) Graphics-API dependent: GLSL only works on OpenGL (ES) systems. The material system should API agnostic and should be open for other hardware APIs (e.g DirectX) and even software (e.g Raytracer) or server-side implementation. 

One of the requirements of WebGL is to work on a D3D based system. We're constraining the spec to make this possible. Translating GLSL into HLSL will be possible. So I don't think this is an issue. I think it's reasonable (and this is very arguable) to restrict the functionality to shader based graphics systems.

> 
> 2) Render system dependent: A concreate shader works only in one rendering pipeline. If you change the rendering pipeline, even staying on the same API e.g. OpenGL, makes the shader invalid. If we would e.g decide to implement a classic forward render using OpenGL/WebGL in HTML we must stay with this method forever. We could not even add shadows because the shader do not handle shadow-passes. We could never switch to a more modern pipeline (e.g. Deffered Lighting) without breaking all old shaders. HTML 3D rendering could never evolve or switch to more modern pipeline.

Yes, my model and all my arguments assume the premise that WebGL is a solid foundation. In my current incarnation as WebKit developer and WebGL spec editor, I have to stay focused on that premise. If you disagree with that (and there are many good reasons to do so) then my arguments lose their validity. But as I said, WebGL has some good traction right now, so taking that as a given makes many things much simpler.

> 
> 3) Low level API: GLSL is a low level HW-shader programming language. It's far away form everything HTML-developer are used to.  GLSL and HTML developer have a very different profile. I don't think every HTML-developer should deal with any 4×4 transformation matrix and flexible lighting equations.

Yes, but as you've shown, making a higher-level and more author-friendly node set is possible. I believe that would be as true with a lightweight declarative node set as the foundation layer as it is with WebGL.

> 
> So we need a declarative material system which allows us to define shadings graphcis-API and rendering-system independent. 
> X3D goes in the right direction. It's API agnostic but defines a specific rendering result (= rendering system) which can be achieved with different rendering pipelines.
> (There are also nodes for concrete GLSL (and HLSL,CG) shader but this is something we should not include in HTML)

So then this is where the biggest difference lies. The browsers already support GLSL, so I feel that moving ahead with that support is the right thing to do.

> 
> The declarative materialsystem is however outdated in some parts and there where various proposals to include
> a new modern declarative material system in X3D. It shouldn't be as fat as MetaSL but should be flexible and powerful
> enough to support modern graphics pipelines.

If you believe that OpenGL will advance with advances in graphics pipelines, then I think it is fair to say that WebGL will follow that same curve. So why not base a material system solely on the OpenGL (WebGL) model?

> 
>> Then you'd want some Sensor nodes, which would allow user interaction and would feed resultant events into the DOM Event Model.
> 
> Agree. Some form of feedback from the rendering tree. I would even leave the PointingSensors (e.g. TouchSensor) out and would try to use HTML events on the 3D graph.

Right, but as I mentioned in my initial post, I think some native (API-based) hit testing would form a valuable foundation.

> 
>> GeoNodes, metadata, and even all the primitives (Box, Sphere, etc.) could be easily done in a JavaScript library and kept out of the core node set.
> 
> The Primitives are not really needed but nice for quick and easy shaping. But you are right. They are not essential. 
> 
>> There would also be no need for TimeSensors or other timing or animation related nodes.
> 
> There must be some form to describe the animation declarative so the UA can run the transition. 
> I personal think that the generic "data flow" design works good for complex scenes but it's open.

With CSS Animation and JavaScript timers, I think there is sufficient support for animation. It may be helpful to have some API that allows timing information to be returned at scene rendering time though.

> 
>> You could also eliminate the complexity of Prototypes, which can be done in a JavaScript library.
> 
> Agree. That's what we also proposed in our Profile (http://www.x3dom.org/?page_id=158)

Excellent.

> 
>> 
>> On top of this core layer you might want physics, higher order surfaces (NURBS, etc.), and maybe particle system nodes. But those could be a later profile.
> 
> Agree. 
> 
>> 
>> What I'm getting at here is that, if designed today, I think 3D for the web would be a much different and much simpler set of nodes than we see in X3D. That's why I say that WebGL is a good first step. It allows us to take the most appropriate steps toward the best 3D solution.
> 
> I believe there will be support for a graphics API (e.g. WebGL) and 
> declarative 3D in future HTML versions. I personally (as OpenGL coder)
> would love to see WebGL in every browser
> 
> Both have there strength and weakness and will coexist like canvas and SVG (as 2D layer) coexist today
> 
> The declarative 3D layer looks to me still like a well defined Profile (= subpart) of X3D + some extensions. 
> I don't think that X3D is perfect but as ISO and well specified Standard an excellent candidate. 
> 
> The world has already to many 3D-Formats and standards. Lets use one in HTML and not define yet another one.

The problem is that there is not one best format. That's why I think a very low level nodeset upon which you can build functionality for a specific purpose would work best.

-----
~Chris
cmarrin@apple.com





-----------------------------------------------------------
You are currently subscribe to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: