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

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



I didn't imply it was a simpler WebGL.  I said it is an alternative
declarative format for WebGL which as I understand it is not a declarative
model.  Else, why this discussion?  I look forward to reading the schema.  

Spinning boxes don't interest me.  People who say scene graphs are only good
for spinning boxes never used one.   But scene graphs are just one model.

Is WebGL a good thing?  It's another thing.  For many projects the current
plug-ins are more than adequate.  Since there is X3D work in progress to
work with WebGL, alternatives to that should be understood for their
advantages.

A declarative format does have the advantage of being easily manipulated by
other standard toolkits.  That's good.  On the other hand, if as with HTML5,
it is yet another parse model as well, that's bad.

len

-----Original Message-----
From: owner-public_webgl@khronos.org [mailto:owner-public_webgl@khronos.org]
On Behalf Of Chris Marrin
Sent: Thursday, February 25, 2010 8:11 PM
To: public webgl
Subject: Re: [Public WebGL] A Declarative node set for WebGL?


On Feb 25, 2010, at 3:31 PM, Len Bullard wrote:

> Don't we already have multiple declarative formats that can be built over
WebGL?   What is the advantage of baking yet another one into WebGL itself?
Because it maps more directly to the native WebGL data structures?  Or
because it has the WebGL object model baked into the declarative nodes?

I don't really see it as a "simplified WebGL". But it would perhaps be a bit
simpler to get up a simple spinning box with the declarative form than with
WebGL and JavaScript. The big advantage is that you tie into the DOM and all
its features much more tightly. The browser knows when the DOM tree has been
mutated, either structurally or by changing attributes or CSS properties.
That information can be used to rerender the 3D scene, but you can't get at
it from WebGL today. A declarative form would also compute transforms from
the root to the leaf nodes natively and can do so efficiently by caching
intermediate results and knowing where transforms are animating.

I don't see this as "yet another 3D scene graph format" I see it as a
declarative form of WebGL. If you accept the premise that WebGL is "a good
thing" then I think its easier to see this as the logical companion.

>  
> In VRML 2.0, the debate over object/markup impedance mismatching was long.
However, it made the point that interoperability via data transfer (bits on
the wire, as Bray says) is very limited particularly where rendering and
behavioral fidelity have to be very strong across platforms.
>  
> If I understand you, the main advantage of your proposal is the DOM
scripting is simplified for those authors who want to instance and navigate
directly in the WebGL objects.  Is that right?

Again, I don't think it's as much simplification as it is more tightly tying
into the native DOM and rendering facilities of the browser.

I see this node set as taking the "Make everything as simple as possible,
but not simpler" approach to a 3D declarative form.

-----
~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:



-----------------------------------------------------------
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: