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

[Andreas Plesch]

Good point. I did not know but the number of webGL contexts is
(arbitrarily) limited to 8 or 16.

https://bugzilla.mozilla.org/show_bug.cgi?id=790138

The existing LayerSet node could be seen to address this by being expected
to use a single context for multiple layers. Cobweb does have LayerSet, so
you could try that. For x3dom it would need to be implemented by somebody
who really needs this because it seems rare to need more than 8
layers/contexts. Or perhaps there is a browser configuration setting ?

X3DSet would only be necessary outside of a web page on standalone browsers
where it would define the window in which multiple x3d scenes could be
composed into.

On a page X3DSet would be equivalent to an enclosing div.



On Jan 20, 2016 10:54 PM, "David Sankel" <camior at gmail.com> wrote:
>
> We're using CSS composition for layered X3D as well.
>
> It seems like there's a hard limit on the number of WebGL contexts
allowed by a browser. Is this something that could limit the number of
layers one could have with X3D? It seems like a 'X3DSet' tag would avoid
such a limitation.
>
> On Wed, Jan 20, 2016 at 11:27 AM, Andreas Plesch <andreasplesch at gmail.com>
wrote:
>>
>> 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 list
>> x3dom-developers at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/x3dom-developers
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20160121/7111f0b3/attachment.html>