[x3d-public] first Viewpoint in Inline and binding delays

[Andreas Plesch]

Hi Michalis,

I had somewhat suspected that it has to do with delays in loading
remote resources. But this is unconvincing since the choice could be
just left to the author who has always the option to put a Viewpoint
before the Inline in the main scene if she wishes to avoid potential
delays. Another way to avoid potential delays would be to just copy a
remote URL to local storage next to the main scene. The point is that
this is a choice.

Also why treat the first node on the stack differently then the
ordering of subsequent nodes ? It does seem to come from a desire to
show something as quickly as possible on the screen, from loading a
scene in a streaming fashion.

Displaying a loading animation until the scene is ready to be
displayed would help with managing user expectations.

Regards,
-Andreas

On Mon, Oct 14, 2019 at 3:05 AM Michalis Kamburelis
<michalis.kambi at gmail.com> wrote:
>
> I think the reason behind the specification rule is that an Inline is loaded from network, so any delay is in theory possible while browser waits for the servers to answer (and tries out each server in succession if previous URLs on the list failed).
>
> Allowing bindable nodes from Inline would mean that browser has to wait (without displaying the scene or allowing to interact with it) until Inline loads (or all possible URLs fail to load) as only then it will know the proper initial camera position, proper background, fog etc.
>
> If the browser would not wait, user would see the scene with invalid camera (which can look bad, as default camera may be in the wall, underground etc.), empty background, no fog etc. for a short time.
>
> I see the problems of this approach, I was biten by it too:) But I'm not sure can we change it without adverse consequences described above.
>
> Note that this affects browsers that load resources asynchronously. Which I suspect applies to all browsers except view3dscene, that *for now* loads Inline synchronously (because that's easier, and in majority of our use-cases we load local content from game data).
>
> Regards,
> Michalis
>
>
>
>
> pon., 14.10.2019, 05:21 użytkownik Brutzman, Donald (Don) (CIV) <brutzman at nps.edu> napisał:
>>
>> On 10/13/2019 7:17 PM, Andreas Plesch wrote:
>> > Section 7.2.2 point d)
>> > (https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/core.html#BindableChildrenNodes)
>> > spells out that a Viewpoint in an Inline cannot become the first bound
>> > Viewpoint, in any situation, even if the main scene does not contain a
>> > Viewpoint node itself.
>>
>> specifically the spec says:
>>
>> "The following rules describe the behaviour of the binding stack for a node of type <bindable node>, (Background, TextureBackground, Fog, NavigationInfo, or Viewpoint):
>>
>> [d.] During read, the first encountered <bindable node> in each layer is bound by pushing it to the top of the <bindable node> stack for that layer. Nodes contained within files referenced by Inline nodes, within the strings passed to the Browser.createX3DFromString() method, or within X3D files passed to the Browser.createX3DFromURL() method (see Part 2 of ISO/IEC 19775) are not candidates for the first encountered <bindable node>. The first node within a locally defined prototype instance is a valid candidate for the first encountered <bindable node>. The first encountered <bindable node> sends an isBound TRUE event."
>>
>> > This rule makes it impractical to use the construct of a simple
>> > container scene which only has a single Inline node which then has the
>> > actual content including an appropriate first Viewpoint. Such a
>> > construct can be really useful.
>> >
>> > What is the rationale behind that rule ? Probably I am overlooking
>> > something but I cannot immediately recognize the underlying reasoning.
>> >
>> > Thanks, -Andreas
>>
>> You make a good case here Andreas.  Not seeing a strong reason why not... I think the original rationale might have been that the order of loading from multiple Inline nodes was nondeterministic due to potential variations in network loading delays for Inline url content.
>>
>> Am thinking/agreeing we need to allow Inline or Browser.createFrom* binding if no other nodes are on the relevant binding stack.  Suggested change:
>>
>>         "[...] are not candidates for the first encountered <bindable node>."
>> to
>>         "[...] are not candidates for the first encountered <bindable node>, unless the respective stack is empty."
>>
>> What do you and others think, is that sufficient?
>>
>> We might also allow browsers to defer binding until all loading is complete within a current network-timeout interval, as way to prevent unpredictable Viewpoint popping/rebinding when multiple Inline nodes are getting retrieved.  Similarly account for time delays might be appropriate a Script or a ProtoInstance generating new content.
>>
>> Next, going further: although network delays might be variable, the order of occurrence can certainly be deterministic once loading is complete.  Seems like we will need prose that states the order of nodes added by prototypes or Inline nodes in the run-time scene graph (whether native X3D or in DOM) needs to match the order of definition.  This would allow authors to deterministically define the order of nodes in the render graph and in the binding stacks.  That is preferable to allowing browsers to append nodes in a somewhat random order according to time of arrival.
>>
>> Example use case: models that contain higher-detailed geometry and Viewpoints for rooms in a house should present those viewpoints in the order that they are defined.  In that way, viewpoints for higher Inline detail for a given room appear together in the viewpoint list, rather than the viewpoint list becoming a mixed-up hodgepodge that thwarts sensible user navigation.
>>
>> First draft suggested prose in that direction, which can no doubt be improved:
>>
>>         "New nodes can be added to a scene as a result of Inline, prototype instance or Script activity.
>>          The resultant ordering of run-time nodes is deterministic based on addition to current scene-graph order, regardless of time delays during loading or generation.
>>          This means that the resulting order of nodes matches the precise order defined by the original and the added content.
>>          If appropriate, browsers are allowed to defer activation changes on the current binding stacks until current content loading is complete or a network timeout occurs."
>>
>> Improvements welcome.
>>
>> 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
>> _______________________________________________
>> x3d-public mailing list
>> x3d-public at web3d.org
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org



-- 
Andreas Plesch
Waltham, MA 02453