[x3d-public] Inlining, importing higher profiles

Sun Mar 17 13:06:59 PDT 2019

Holger released x_ite 4.4.4 which now has the extended
browser.importDocument signature. .importDocument(dom) works as
previously and uses the profile of the currently loaded scene, similar
to Inline. .importDocument(dom, success, error) accepts the callbacks
and loads additional components as required before invoking the
callbacks.

I updated x_ite_dom accordingly, along with some other necessary
updates due to other changes in x_ite:

https://andreasplesch.github.io/x_ite_dom/index.xhtml

Sorry for the basic styling of the example page.

I think there was a question on where to find Roy's dom integration
examples. I think they are here:

https://andreasplesch.github.io/x_ite_dom/tests/html5/x3d_integration.html
(x_ite)
https://andreasplesch.github.io/x_ite_dom/tests/html5/x3dom_integration.html

Compare the sources to understand the similarities and differences. I
will do my best to answer any questions,

Thanks, Andreas

On Thu, Mar 14, 2019 at 12:04 PM Andreas Plesch <andreasplesch at gmail.com> wrote:
>
> Just a brief update. It looks like x-ite is settling on a new
> browser.importDocument signature using callbacks:
>
> browser.importDocument (dom, success, error)
>
> where success and error are callback functions. success is invoked
> after completing the import and gets the new scene as a X3DScene for
> its argument value, and error any error messages if importing fails.
>
> Typically, you would use browser.replaceWorld as the success callback function.
>
> x-ite is currently not using a new method name since really with lazy
> loading this becomes the preferred import method.
>
> Andreas
>
>
> On Wed, Mar 13, 2019 at 4:42 PM Andreas Plesch <andreasplesch at gmail.com> wrote:
> >
> > The difficulty with allowing browser.importDocument and replaceWorld
> > to load a higher than current profile seems to be that lazy loading
> > often uses asynchronous fetching and loading of the required
> > additional libraries. x-ite is an example. And SAI importDocument is
> > synchronous, as well as loadURL and CreateX3DFromURL .
> >
> > If we consider a async. version of these SAI methods, the favoured
> > approach in javascript now is to return promises (rather than
> > supplying callbacks).
> >
> > I think x-ite could implement importDocumentAsync, loadURLAsync and
> > CreateX3DFromURLAsync browser methods. In fact, I adjusted x_ite_dom
> > to asynchronously load the additionally required component libraries
> > for new scenes. I suppose all methods which return a X3DScene could
> > use such async versions due to the potential of lazy loading.
> >
> > x-ite needs the additional component libraries already for parsing
> > since they register x3d nodes with the browser. So the async. lazy
> > loading needs to happen at the loading stage even if the loaded x3d
> > scene or subscene is then not actually used in a new world.
> >
> > Should x3d consider asynchronous SAI methods ?
> >
> > -Andreas
> >
> > On Tue, Mar 12, 2019 at 3:10 PM Andreas Plesch <andreasplesch at gmail.com> wrote:
> > >
> > > Thanks, good to see the spec. is clear on how Inline is supposed to be
> > > treated. Although I am not sure what the point is if the browser
> > > actually could support the higher profile in the Inline. I think a
> > > warning would suffice to alert the author that the scene itself may
> > > need optimization and that the Inline required additional resources.
> > > Anyways, it is more important to have a clear definition.
> > >
> > > That leaves the SAI functions. The main argument against allowing
> > > importDocument and replaceWorld to work with a higher profile than the
> > > existing world would be consistency with Inline but that is really a
> > > different scenario.
> > >
> > > -Andreas
> > >
> > > On Tue, Mar 12, 2019 at 2:40 PM Leonard Daly <Leonard.Daly at realism.com> wrote:
> > > >
> > > > Andreas,
> > > >
> > > > It's in http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/networking.html#X3DUrlObject
> > > >
> > > > 4th paragraph (edited):
> > > >
> > > > It shall be an error to specify a file in the URL field that has a set of component definitions that is not a subset of the components of the containing world. In addition, the components shall not be of a higher support level than those used by the containing world.... When the world indicated by the url field requests capabilities greater than its parent, the following actions shall occur:
> > > >
> > > > an error shall be generated,
> > > > the URL shall be treated as not interpretable as specified in 9.3.2 X3DUrlObject, and
> > > > the next URL shall be loaded and checked in accordance with 9.2 Concepts.
> > > >
> > > > For more information on URLs, see 9.2.1 URLs.
> > > >
> > > >
> > > > This was based on design decisions ~20 years ago. The WG explicitly considered lazy loading and decided that the optimizations available at the beginning of the file overrode the feature of increasing support (profile or component) later on. Nothing prevents a browser from lazing loading capabilities, but it's suppose to limit that to what was originally declared.
> > > >
> > > >
> > > > Leonard Daly
> > > >
> > > >
> > > > X-ITE is now loading support for some, less common components on
> > > > demand, eg. depending on profile and component statements in a scene.
> > > > This may lead to consequences on how external SAI and Inline are
> > > > treated which I want to clarify. I came across this since it affects
> > > > my dom bridge.
> > > >
> > > > The question is if inlining or importing a Scene requiring a higher
> > > > profile (say Full) into a scene with a lower profile (say Interactive)
> > > > should be possible, eg. have the browser accept the higher profile
> > > > nodes.
> > > >
> > > > The answer seems like the browser should just work with the higher
> > > > profile nodes, in both cases, Inline and
> > > > browser.replaceWorld(new_scene). But I could not find guidance in the
> > > > spec. and X-ITE currently does not do that since it only seems to load
> > > > needed components on loading of the initial scene.
> > > >
> > > > The more common scenario is a higher profile Inline, which is using
> > > > say geospatial nodes, being inlined into a lower profile scene. I
> > > > think not specifying a profile for a scene just means the browser
> > > > should use its highest level of support since the point of profiles is
> > > > that a browser can warn or reject if it cannot support a scene. Is
> > > > that the main point ?
> > > >
> > > > A question in this case is if SAI properties Scene.components or
> > > > Scene.profile should then report the elevated, higher level or the
> > > > original level.
> > > > Due to on-demand loading of additional libraries, there is some logic
> > > > for a browser to not support higher profiles in Inlines although it
> > > > could. Should there be a directive in the spec, to clarify that this
> > > > kind of elevating should be supported anyways, or should a decision be
> > > > left to the browser ?
> > > >
> > > > For the dom bridge I use the importDocument and replaceWorld browser
> > > > services, for initial loading into a default empty Scene.
> > > > Since here the new scene completely replaces the old scene, there is
> > > > really no reason why a higher profile could not replace a lower
> > > > profile scene. But perhaps I am overlooking something since X-ITE does
> > > > not allow it ? Should this be explicitly allowed in the spec. ?
> > > > Here is a github issue: https://github.com/create3000/x_ite/issues/43
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Leonard Daly
> > > > 3D Systems & Cloud Consultant
> > > > LA ACM SIGGRAPH Past Chair
> > > > President, Daly Realism - Creating the Future
> > >
> > >
> > >
> > > --
> > > Andreas Plesch
> > > Waltham, MA 02453
> >
> >
> >
> > --
> > Andreas Plesch
> > Waltham, MA 02453
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453

-- 
Andreas Plesch
Waltham, MA 02453