[x3d-public] LoadSensor completion of loading: progress, IMPORT EXPORT
Andreas Plesch
andreasplesch at gmail.com
Wed Jan 4 17:04:33 PST 2023
Hi Don,
Thanks for the input, and confirming behavior. Do you have an opinion on if
completion of loading needs to be specified more narrowly to ensure a
consistent experience across browsers? Ideally, this should not be
necessary.
But it is difficult to model full completion of loading of nested Inlines
with multiple children of a LoadSensor in the parent scene, or with
multiple LoadSensors in the parent scene. Actually, I cannot think of a way
to do that if the isLoaded true event is emitted early, eg. before inner
Inlines are completely loaded.
A test scene would consist of an Inline with a large inner Inline which
exports a Shape which is imported by the outer Inline and again exported by
the outer Inline. The main parent scene then would have a LoadSensor for
the Inline and a route which uses the isLoaded field to trigger display of
the exported Shape from the inner Inline. If isLoaded true is emitted
before the exported Shape is available, there would be an incomplete route
and possibly a browser error. There are probably better tests.
Andreas
---on the phone---
On Sat, Dec 31, 2022, 12:42 PM Brutzman, Donald (Don) (CIV) <
brutzman at nps.edu> wrote:
> Agreed that ‘isLoaded’ field should indicate completion. Additional
> indicators for loading are the LoadSensor ‘loadTime’ and 'progress' fields.
>
>
>
> - X3D4 Architecture, Networking component, 9.4.3 LoadSensor
> -
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-DIS/Part01/components/networking.html#LoadSensor
>
> · SFBool [out] isLoaded
>
> - The *isLoaded* field generates events when loading of the
> LoadSensor's children has completed. An isLoaded TRUE event is generated
> when all of the elements have been loaded. An isLoaded FALSE event is
> generated when one or more of the elements has failed to load, or when the
> timeout period is reached as specified in the timeout field. If all
> elements in the children are already loaded by the time the LoadSensor is
> processed, the LoadSensor shall generate an isLoaded event with value TRUE
> and a progress event with value 1 at the next event cascade.
>
> · SFTime [out] loadTime
>
>
> - The *loadTime* event is generated when loading of the LoadSensor's
> children has successfully completed. If loading fails or the timeout period
> is reached, a *loadTime* event is not generated.
> - SFFloat [out] progress
> - The *progress* field generates events as loading progresses. The
> value of *progress* is a floating-point number between 0 and 1
> inclusive. A value of 1 indicates complete loading of all children
> elements. The exact meaning of all other values ( i.e., whether these
> indicate a percentage of total bytes, a percentage of total number of
> files, or some other measurement) and the frequency with which
> *progress* events are generated are X3D browser-dependent. Regardless,
> the X3D browser shall in all cases guarantee that a progress value of 1 is
> generated upon successful load of all URL objects.
>
>
>
> Worth noting is that LoadSensor can have multiple children (for commonly
> shared logical dependencies), or alternatively, multiple LoadSensor nodes
> can be used (for multiple independent logical dependencies). So X3D
> simulation authors have a lot of flexibility for scalable composition of
> animated models for interactive simulation design.
>
>
>
> Regarding IMPORT and EXPORT, these are defined pair-wise between immediate
> parent and child scenes respectively. Prose for each statement includes
> the caveat “Once imported…”
>
>
>
> - X3D4 Architecture, Networking component, 9.2.5 IMPORT statement
> -
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-DIS/Part01/components/networking.html#IMPORTStatement
> - X3D4 Architecture, Networking component, 9.2.6 EXPORT statement
> -
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-DIS/Part01/components/networking.html#EXPORTStatement
>
>
>
> Thus LoadSensor *isLoaded* or *loadTime* can be used in the parent scene
> to determine whether child scene is loaded and ready to receive events.
> “But wait there’s more:” overachievers using a Script node might also
> monitor the *progress* field for responding at the moment when an event
> value of 1 is received.
>
>
>
> One might speculate that a child scene needs to know when parent scene is
> present… this might get tricky if we tried to specify a field indicating
> presence of a parent, because the parent scene might not yet be ready to
> receive events. Suggested authoring approach: parent scene can send an “I
> am ready now, get started” event to the loaded child scene once ready to
> begin two-way exchange of events.
>
>
>
> Gee, better be careful out there. If we keep going with scalable
> deterministic logic for interconnected X3D models like this, we might end
> up building a metaverse or something…
>
>
>
> Thanks for serious implementation efforts in X_ITE and X3DOM. Happy New
> Year, have fun with X3D4! 8)
>
>
>
> 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 https://
> faculty.nps.edu/brutzman
>
>
>
> -----Original Message-----
> From: x3d-public <x3d-public-bounces at web3d.org> On Behalf Of Holger Seelig
> Sent: Wednesday, December 21, 2022 9:09 AM
> To: Andreas Plesch <andreasplesch at gmail.com>
> Cc: X3D <x3d-public at web3d.org>
> Subject: Re: [x3d-public] LoadSensor completion of loading
>
>
>
> I think, and it is how it is now implemented in X_ITE, Inline nodes are
> loaded, if they are completely loaded with all it sub scenes. This makes it
> easier for an X3D author to to determine if all is loaded, otherwise the
> author must traverse the scene, or do other logic, to determine if sub
> Inline scenes are loaded. I makes sense that, that an Inline is loaded when
> it is completely loaded.
>
>
>
> Best regards,
>
> Holger
>
>
>
> > Am 21.12.2022 um 17:50 schrieb Andreas Plesch <andreasplesch at gmail.com>:
>
> >
>
> > It is useful to be notified after an Inline has completed loading.
>
> > This is especially true for external access to the scene if the Inline
>
> > has exports (or dom style access is used).
>
> > A LoadSensor generates such an event:
>
> >
>
> > https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/com
>
> > ponents/networking.html#LoadSensor
>
> >
>
> > "The isLoaded field generates events when loading of the LoadSensor's
>
> > children has completed."
>
> >
>
> > However, in the case that the Inline contains another Inline itself a
>
> > question came up. Is loading considered complete when the outer Inline
>
> > xml/json/.. is completely downloaded but still has only a url
>
> > reference to the inner Inline ? That typically would happen before
>
> > also the inner Inline is completely downloaded. Or should the event be
>
> > generated only after the inner Inline (and all of its content) is also
>
> > completely downloaded ?
>
> >
>
> > The second option is more useful, especially for web use where loading
>
> > generally occurs asynchronously and such events are often used to
>
> > initiate processing of downloaded content.
>
> >
>
> > For generic X3D use, one could imagine a situation where a LoadSensor
>
> > triggers something which assumes that the scene is fully rendered
>
> > before an Inline is actually rendered.
>
> >
>
> > It is also related to how EXPORT/IMPORT works. One could probably
>
> > construct a situation where a LoadSensor triggers access to an
>
> > EXPORTed node from an inner Inline before it is available.
>
> >
>
> > Is a tightening of the language necessary ? Perhaps there is already a
>
> > more precise definition of 'loading' in the spec. somewhere else ?
>
> >
>
> > -Andreas
>
> > --
>
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230104/fee642e6/attachment.html>
More information about the x3d-public
mailing list