<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">It's actually a little worse than
Michalis describes below in his examples with 1.x3d & 2.x3d.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">1.x3d could Inline one (or more) *.x3d
files, any of which may contain the "first" Viewpoint node.
Consider the case where you have 20 Inline nodes in the main file.
Most web browsers are configured to have a maximum of 4 external
connections at any one time. If the load request goes into a FIFO
queue, then 18 more references (after 1.x3d and 2.x3d) need to be
loaded before the first sub-Inline of 1.x3d could be addressed.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">So when Michalis says below "*and be
sure that all preceding content is loaded*" you need to take "all
preceding content" to be maximally inclusive.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Leonard Daly</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<blockquote type="cite"
cite="mid:CAKzBGZN1uZtoWyehjPA0dd6Fd7K9meBOW5kQ=s1x=s+LyL8uMQ@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">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 <a class="moz-txt-link-rfc2396E" href="mailto:andreasplesch@gmail.com"><andreasplesch@gmail.com></a> napisał(a):
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
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)
<a class="moz-txt-link-rfc2396E" href="mailto:brutzman@nps.edu"><brutzman@nps.edu></a> wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
On 10/13/2019 7:17 PM, Andreas Plesch wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Section 7.2.2 point d)
(<a class="moz-txt-link-freetext" href="https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/core.html#BindableChildrenNodes">https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/core.html#BindableChildrenNodes</a>)
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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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."
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
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?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Not considering the first bound node, what is the order currently of
Viewpoints in Inlines ? As they are loaded, eg. non-deterministic ?
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
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."
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
Improvements welcome.
all the best, Don
--
Don Brutzman Naval Postgraduate School, Code USW/Br <a class="moz-txt-link-abbreviated" href="mailto:brutzman@nps.edu">brutzman@nps.edu</a>
Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149
X3D graphics, virtual worlds, navy robotics <a class="moz-txt-link-freetext" href="http://faculty.nps.edu/brutzman">http://faculty.nps.edu/brutzman</a>
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
--
Andreas Plesch
Waltham, MA 02453
_______________________________________________
x3d-public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a>
<a class="moz-txt-link-freetext" href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a>
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
_______________________________________________
x3d-public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a>
<a class="moz-txt-link-freetext" href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a>
</pre>
</blockquote>
<p><br>
</p>
<div class="moz-signature">-- <br>
<font class="tahoma,arial,helvetica san serif" color="#333366">
<font size="+1"><b>Leonard Daly</b></font><br>
3D Systems & Cloud Consultant<br>
LA ACM SIGGRAPH Past Chair<br>
President, Daly Realism - <i>Creating the Future</i>
</font></div>
</body>
</html>