[x3d-public] [x3dom-developers] layering component on the web, multiple scenes

Andreas Plesch andreasplesch at gmail.com
Wed Jan 20 13:37:27 PST 2016

The x3dom component editor uses this concept:


The orientation indicator in the upper right and the coordinate axes in the
lower left corners are additional x3d scenes composited on top of the main
scene, all within a <div>. Use the FF object inspector to find the <canvas>
elements and play with the styles including positioning.

So this concept is already implemented. The idea is that you can use CSS
positioning directly on the canvas element; there is no need to wrap each
canvas into a <div>. A <div> enclosing all x3d scenes allows for managing
this set of x3d scenes relative to other page content and the page
geometry. Declaring the X3D node as a <canvas> like html5 element (in a web
page context) would just formalize this use within the spec., and imply
that the x3d element has the same CSS style properties as canvas.
"Inheriting" or "Deriving" from canvas may not be quite the correct
language since html5 may not have such concepts.


has more.

I was hoping that one of the Behr et al. publications on the x3dom concept:


talks about this aspect of web integration but could not immediately find a
relevant paragraph. This is why the x3dom-developer list is cc'ed.

CSS object positioning and transformation can be slow but typically you
would not have a lot of scenes (canvases) and would not frequently or at
all change their positions/sizes. CSS for other x3d nodes is another issue
which would require more in depth separation of styling and content within
x3d (so likely not really an option anymore).

Fixed HUD text is probably the main use case. The "+" HUD example was meant
as an example for general text as well. Text on a web page generally would
be best rendered just as html text. The point is one can overlay any kind
of html5 content.

cobweb overlays over x3dom rendering is also in theory already possible but
currently not supported because of how cobweb and x3dom would fight over
the right to parse/interprete/render the same <x3d> element. Changing the
cobweb <x3d> use into <x3durl> or something should help with that and would
be more standard conforming as well. (Be aware then that cobweb uses eval()
to implement the x3d script node which will allow access to anything on the
web page from a x3d script, and likely total browser crashes/freezes).


On Wed, Jan 20, 2016 at 1:59 PM, Leonard Daly <web3d at realism.com> wrote:

> I think this is a wonderful idea. Closer integration with DOM concepts and
> existing support (DOM, CSS, JS) is good.
> Andreas, to fully adopt this idea into V4, what would be necessary? (Note
> that I am only concerned with an HTML5 environment at this point.) I see a
> possible new node <X3DSet> and change to <X3D> to inherit from <canvas>.
> Could this concept be implemented with overlapping <div> containing <X3D>?
> I am a little concerned about using CSS for object positioning. Fraunhofer
> and others have found that the WebGL/DOM system gets real slow when
> manipulating a lot of objects with CSS.
> Perhaps both methods are made available and authors need to make the
> choice based on their requirements. An object could be transformed by CSS
> or by <Transform position='...'>
> Another thought which you didn't mention is text. Using these ideas, text
> could be added to the scene as a overlay. It would not be attached to an
> object, but very useful for a HUD. Object text could either be a texture or
> modeled into the object (3D text).
> Leonard Daly
> Since it may be beneficial to move the x3d standard closer to other web
> technologies, I would like to bring up the layering component.
> x3dom does not support the layering component (LayerSet, Layer, Viewport
> nodes) because you would use web browser controlled CSS positioning of
> multiple x3d scenes for the same effect. You would use an enclosing <div>
> element (the "rendering surface") and put multiple x3d scene (<x3d> tags)
> within it, each with independent content and navigation. Then using CSS
> styles it is possible to define size and position of each x3d scene within
> the <div> on the web page. The web browser then takes care of compositing
> the scene renderings taking into account overlaps, opacity and
> such.
> This all happens without any additional effort on the x3d browser (x3dom)
> side, and has the additional benefit that any other html5 element can be
> used in such a composition as well. For example, it is easy to place a
> fixed "+" sign in the center for HUD purposes.
> For this kind of compatibility with web standards it may be necessary to
> include management and compositing of the rendering of multiple x3d scene
> graphs into the standard, with the goal of eventually making the layering
> component obsolete. For this purpose a superset node <X3DSet> or such may
> be useful.
> Alternatively, CSS positioning could be explicitly embraced by including
> language which defines the <X3D> node (tag?, element?) as being derived
> from the <canvas> html5 element when used in web context, eg. on a html5
> page, and as such inheriting all canvas CSS properties. This option would
> make support for compositing of multiple x3d scenes only applicable in a
> web browser case where it would be automatically provided.
> -Andreas
> --
> Andreas Plesch
> 39 Barbara Rd.
> Waltham, MA 02453
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> x3dom-developers mailing listx3dom-developers at lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/x3dom-developers
> --
> *Leonard Daly*
> X3D Co-Chair
> Cloud Consultant
> President, Daly Realism - *Creating the Future*

Andreas Plesch
39 Barbara Rd.
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20160120/544bc400/attachment.html>

More information about the x3d-public mailing list