[x3d-public] Inlining, importing higher profiles

Thu Mar 14 18:16:25 PDT 2019

Really interesting issue, thanks for bringing it up.

In general we avoid getting specific about synchronous/asynchronous and focus on functional capabilities.  HTML is similar in that respect.

Raising the profile certainly seems like an achievable/reasonable requirement/goal for X3Dv4.  Such behavior is definable.

We will likely see similar issues if a browser that has loaded an X3Dv3.3 scene graph is next loading new content supported by X3Dv4, perhaps glTF or STL.

Wondering if we might also want some kind of setVersion on the X3D root element?  From a scene-graph construction perspective, such methods exist in DOM and X3DJSAIL already.  Providing such a method in SAI might be part of defining a programmatic way to allow authors to upgrade version.  As with so many things, actual browser response remains the province of its conformance support.

Sounds like a goal requirement and suggested specification change is in order here.

On 3/14/2019 9:04 AM, Andreas Plesch 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
> 
> 
> 

all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman