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

Mon Oct 14 11:49:10 PDT 2019

Perhaps the desire is to do this in a declarative style?

John

On Mon, Oct 14, 2019 at 1:42 PM Holger Seelig <holger.seelig at googlemail.com>
wrote:

> I want to mention, that it is already possible to bind an Inline
> viewpoint, if you place a Script in the Inline and send a set_bind TRUE
> to the viewpoint node in the initialize function of the Script, if this
> behavior is really needed, that a certain Inline viewpoint should be bound.
>
> Regards,
> Holger
>
>
> On 14.10.19 20:08, Michalis Kamburelis wrote:
> > 1. The change proposed here would apply to other bindable stacks as
> > well. We have 4 stacks currently:
> >
> > - Viewpoint stack (allows Viewpoint, OrthoViewpoint nodes)
> > - NavigationInfo stack
> > - Background stack (allows Background, TextureBackground, and Instant
> > Reality / CGE extensions like ImageBackground)
> > - Fog stack
> >
> > In case of NavigationInfo, it means that after the proposed change (if
> > the potential "initial" NavigationInfo can be inside an "Inline"), the
> > browser would have to wait before allowing the user to navigate in the
> > scene (otherwise, you're not sure whether to allow EXAMINE, WALK,
> > whether gravity should work, what is avatar height and allowed climb
> > step etc.)
> >
> > So the author would have to specify *both* Viewpoint and
> > NavigationInfo in the main file, to enable camera navigation in the
> > scene without any delay. Otherwise the browser must wait until it
> > finds at least one Viewpoint, and one NavigationInfo, or until all
> > Inline resources are loaded.
> >
> > ( Background and Fog are not really problematic here, I mentioned them
> > only for completeness. )
> >
> > 2. The need to be deterministic actually means that it's not enough to
> > just "wait for the 1st Viewpoint". You need to wait for the 1st
> > Viewpoint, *and be sure that all preceding content is loaded*.
> >
> > E.g. consider this:
> >
> > ```
> > Inline { url "1.x3d" }
> > Shape { ... }
> > Inline { url "2.x3d" }
> > ```
> >
> > When loading this file, the browser can asynchronously download 1.x3d
> > and 2.x3d. If the 2.x3d is loaded first, and it contains a Viewpoint
> > node -- we still cannot display anything to user. We have to load also
> > 1.x3d, and only if 1.x3d *doesn't* contain Viewpoint node, then we can
> > use Viewpoint from 2.x3d.
> >
> > 3. I admit, I feel uncertain about this.
> >
> > For browsers that currently load Inlines asynchronously (and in the
> > meantime, allow the user to see and navigate in the scene) this could
> > be undesired.
> >
> > That's because we are adding an extra "waiting period" before we allow
> > user to see the scene, and navigate in the scene. In the above
> > example, 1.x3d and 2.x3d may not contain any bindable nodes, but we
> > still have to wait until they are loaded. Otherwise we only show to
> > user "please wait". This feels bad for user experience (imagine a
> > similar rule for HTML -- if browser would have to download all linked
> > CSS, JS, etc. before you could see and navigate in the page).
> >
> > The advantage of existing spec (that says that Inline contents are not
> > taken into account when determining the first
> > Viewpoint/NavigationInfo/Background/Fog/...) is that a browser can
> > immediately display and allow to navigate in the world, while Inline
> > content loads asynchronously.
> >
> > I understand that the X3D author could specify
> > Viewpoint/NavigationInfo in the main file (before any Inline) to avoid
> > delays. But if we encourage to specify Viewpoint/NavigationInfo in the
> > main file, then we actually encourage something that the current
> > specification already mandates. So the gain from the change seems
> > smaller.
> >
> > This possible "waiting period" seems like a small trap for X3D
> > authors: "Why do I get a screen 'please wait' when loading this
> > model?" -- because I forgot to place Viewpoint node, and
> > NavigationInfo node, before any Inline. And it happens that the
> > Internet connection to one of the serves hosting my Inline content is
> > slow.
> >
> > Regards,
> > Micahlis
> >
> > pon., 14 paź 2019 o 16:10 Andreas Plesch <andreasplesch at gmail.com>
> napisał(a):
> >> Hi Don,
> >>
> >> your suggestions would address the issue concisely. More detail below.
> >>
> >> On Sun, Oct 13, 2019 at 11:20 PM Brutzman, Donald (Don) (CIV)
> >> <brutzman at nps.edu> wrote:
> >>> 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.
> >>> 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.
> >> Yes, but the order of the Inlines themselves in the X3D is well
> >> defined. Delays are something which could be left to the author's
> >> responsibility.
> >>
> >>> 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?
> >> That would probably suffice. A consequence is that we would have to
> >> think through the SAI created bindable node cases, all the other
> >> bindable nodes, and consider if that the exception should apply at
> >> all, not only if the stack is empty.
> >>
> >>> 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.
> >> Are browser not already allowed to defer binding until all loading is
> complete ?
> >> The browser would only need to defer rendering until it can determine
> >> which is the first Viewpoint. If there is one before the first Inline,
> >> it is the first of those. If not, keep looking through Inlines.
> >> Some browser may opt to have some initial popping or transitioning
> >> between the first main Scene Viewpoint and the first Inline Viewpoint
> >> if the Inline occurs first.
> >> I think availability of network resources is not something X3D has to
> >> be concerned with.
> >>
> >>> 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.
> >> Not considering the first bound node, what is the order currently of
> >> Viewpoints in Inlines ? As they are loaded, eg. non-deterministic ?
> >>
> >>> 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."
> >> Not sure if the last sentence is needed.
> >> Perhaps guidance to authors on how to avoid delays in showing an
> >> initial view by defining default bindable nodes first in the scene may
> >> be also appropriate to add.
> >>
> >> Thanks, -Andreas
> >>
> >>> 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
> >>
> >>
> >> --
> >> Andreas Plesch
> >> Waltham, MA 02453
> >>
> >> _______________________________________________
> >> x3d-public mailing list
> >> x3d-public at web3d.org
> >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> > _______________________________________________
> > x3d-public mailing list
> > x3d-public at web3d.org
> > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
> --
> Holger Seelig
> Digital Media Designer
>
> Scheffelstraße 31a
> 04277 Leipzig
> Germany
>
> Cellular: +49 176 420 479 37
> E-Mail:   holger.seelig at create3000.de
> Web:      http://create3000.de
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20191014/697c5d60/attachment-0001.html>