webGL scene graphs as custom components?

[Gavin Doughtie]

Thought experiment -- would custom components be usable to do something like an X3D implementation? I'm thinking of a situation where there's a "root" webGL canvas that composes a large number of subcomponents that render into that root component's viewport via a scene graph (constructed of other components).

ShadowDOM doesn't seem particularly useful in this case, but expressing things as markup does.

[Dominic Cooney]

Given the hierarchical nature of scene graphs I think Polymer elements would be very useful and usable for this. It would be cool to do hit testing and route click events back to the scene graph DOM!

You're right that you won't use Shadow DOM for the nodes in the scene graph. If you want to encapsulate your canvas, you might want to have one element with Shadow DOM at the top level to contain the canvas.

Dominic

On Sun, Jun 2, 2013 at 7:49 AM, Gavin Doughtie <gavin.d...@gmail.com> wrote:

Thought experiment -- would custom components be usable to do something like an X3D implementation? I'm thinking of a situation where there's a "root" webGL canvas that composes a large number of subcomponents that render into that root component's viewport via a scene graph (constructed of other components).

ShadowDOM doesn't seem particularly useful in this case, but expressing things as markup does.

--
You received this message because you are subscribed to the Google Groups "Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

[Ben Ellis]

I was thinking of something much like this the other day.

It's curious how appropriate custom elements are for even things that have no representation as a part of the actual visible DOM.

[Gavin Doughtie]

I think (dare I say it... yes, I dare...) COM in VB showed us that non-visual components with declarative binding can be valuable for rapid development.

[Dominic Cooney]

+1. .NET maintained this tradition. Cocoa and Interface Builder do it too (File's Owner, etc.). HTML does it too (head, meta, etc.) This is a well-worn, happy trail.

Dominic

--

You received this message because you are subscribed to the Google Groups "Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

[Scott Miles]

Yes yes yes. This topic will get me on my soapbox whenever talking about Custom Elements. 

You need a system for encapsulating, composing, and controlling non-visual tasks just as much as visual ones. System, thy name is DOM.

We need to educate about this however. People have a knee-jerk reaction to a custom element that doesn't render directly as being wrong or bloated.

I think this is happening here, but to be fair, I'm not 100% sure I understand his complaint ("writing non visual elements is dirty").

Scott

[Eric Bidelman]

Working link: https://plus.google.com/u/0/+JonathanBeri/posts/Xw1SnxhBxbc

Creating DOM elements that don't render UI is a foreign concept for most people.

Dare I say "tectonic shift"? :)  It'll feel dirty for most because we've been taught

to reduce DOM bloat as much as possible. 

Totally 99% an educational thing and 1% dirty thing. 

[Ben Ellis]

On Thursday, June 6, 2013 12:57:09 PM UTC-4, Eric Bidelman wrote:

Working link: https://plus.google.com/u/0/+JonathanBeri/posts/Xw1SnxhBxbc

Bullets 1 and 2 of "what I didn't like" are "no dependency management" and "non-visual elements are dirty"; that amuses me because I think we'll be doing dependency management using non-visual elements.

 

[JZ JennyZhang]

hi, can you share a link to Cocoa, Interface Builder or recommend any other web component builders? thanks!