<div dir="ltr">Leonard, Andreas,<div>In freewrl desktop browser I put a menu button to disable/toggle-off scene sensors. That's in case the user navigates via mouse/finger too close to some geometry that is sensing, and then cannot navigate away because the sensor is swallowing all the mouse/finger events. Turning off all sensors would include any Layout/Layering sensors.<br></div><div>Screen-aligned sensor would only swallow events when the mouse/finger is over the sensitized scene geometry.</div><div>Prototyping: maybe a billboard/plane sensor could do the same thing. Would that be the case with Linesensor too? I didn't think of that and I have a decade of web3d. There are cases in web3d where nodes have been added/changed so as to be more convenient to scene authors than via prototyping.</div><div>-Doug<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Apr 6, 2019 at 11:30 PM Leonard Daly <<a href="mailto:Leonard.Daly@realism.com">Leonard.Daly@realism.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<div class="gmail-m_-5550647162936599440moz-cite-prefix">Andreas,</div>
<div class="gmail-m_-5550647162936599440moz-cite-prefix"><br>
</div>
<div class="gmail-m_-5550647162936599440moz-cite-prefix">Sorry for not responding sooner on this
thread -- it has been a busy week for me.</div>
<div class="gmail-m_-5550647162936599440moz-cite-prefix"><br>
</div>
<div class="gmail-m_-5550647162936599440moz-cite-prefix">I am concerned about the use of a
screen-aligned sensor when display 3D content in a browser. Other
environments may be useful and interesting, but my focus right now
is browser-based displays.</div>
<div class="gmail-m_-5550647162936599440moz-cite-prefix"><br>
</div>
<div class="gmail-m_-5550647162936599440moz-cite-prefix">A screen-aligned sensor (either line or
rectangular) occupies a rectangular region (degenerate rectangular
is a line) on the screen. This is the same as a HTML5 div tag that
is overlayed on the screen. HTML will generate various events when
the pointing device interacts with that region. These are
different for cursor (mouse) and touch (finger or otherwise) [for
example, there is no mouseover when there is only a
touch-sensitive screen without a cursor]. <br>
</div>
<div class="gmail-m_-5550647162936599440moz-cite-prefix"><br>
</div>
<div class="gmail-m_-5550647162936599440moz-cite-prefix">The HTML events generated by the
interaction all use screen coordinates (pixels, some of which are
relative to the div origin). The X3D events are created using
geometry-fractional coordinates. An X3D sensor exists in 3D space
(sort-of, as I understand it) but not subject to rotation or
skewing. If I am wrong, then how does a screen-aligned sensor
differ from an existing TouchSensor node. This allows the X3D
screen-aligned sensor to change in size as the camera changes
position. This feature would need to be programmed into an HTML
div for the same effect.So the X3D screen-aligned sensor exists in
3D space that is displayed on the canvas, when the HTML div exists
in an HTML layer relative (in some manner) to the document and may
be in front of or behind the canvas. <br>
</div>
<div class="gmail-m_-5550647162936599440moz-cite-prefix"><br>
</div>
<div class="gmail-m_-5550647162936599440moz-cite-prefix">In any case, there are two constructs
that take the same sort of user interaction, but produce
significantly different results. That will lead to confusion on
the part of X3D developers and perhaps users. It is not clear what
the official solution will be.The Wiki page at
<a class="gmail-m_-5550647162936599440moz-txt-link-freetext" href="http://www.web3d.org/wiki/index.php/X3D_version_4.0_Development" target="_blank">http://www.web3d.org/wiki/index.php/X3D_version_4.0_Development</a>
discusses X3D/DOM integration and many issues related to that. It
appears that there is no definitive explicit statement as to
capabilities on that page with specific regard to DOM integration.
<br>
</div>
<div class="gmail-m_-5550647162936599440moz-cite-prefix"><br>
</div>
<div class="gmail-m_-5550647162936599440moz-cite-prefix">Consider the experience of a virtual
world (to fit into X3D V4.0, not V4.1) that runs in a browser.
There is content external to the 3D display region that needs to
be updated from the 3D content and vice-versa. The experience has
a head's up display containing important information and features
about the experience. It is generally easier (for the developer)
and produces a cleaner looking interface if the HUD is done in 2D;
however, it could be done in 3D. One of the features is a 2D
picker (aka TouchSensor). There are now (with the screen-aligned
sensor) two different means for interacting with the user. Each do
things a little differently. As a developer I would wonder about
which to use:</div>
<div class="gmail-m_-5550647162936599440moz-cite-prefix">
<ol>
<li>HTML5 div (easy to fix to the display)<br>
</li>
<li>X3D TouchSensor (because its attached to the HUD that is
fixed in the display)</li>
<li>X3D screen-aligned sensor (because its better somehow?)</li>
</ol>
<p>As a user I might wonder why the interaction does not support
multi-touch. As a maintainer, I would need to figure out which
sensor/events were source/primary so I can perform updates, etc.</p>
<p>I am having a very hard time figuring out what this sensor
provides that is not available though other means. For example,
doesn't a TouchSensor on a Billboard (with the right field
values) stay screen aligned?</p>
<p><br>
</p>
<p>Leonard Daly<br>
</p>
</div>
<div class="gmail-m_-5550647162936599440moz-cite-prefix"><br>
</div>
<div class="gmail-m_-5550647162936599440moz-cite-prefix"><br>
</div>
<div class="gmail-m_-5550647162936599440moz-cite-prefix"><br>
</div>
<div class="gmail-m_-5550647162936599440moz-cite-prefix"><br>
</div>
<blockquote type="cite">
<pre class="gmail-m_-5550647162936599440moz-quote-pre">Hi Leonard,
I kept puzzling over your comment. The main function of the
dragsensors is to translate from pixel/screen units to world
units/coordinate systems which requires some kind of 2d to 3d
translation. Why would you not count this difference ? This
translation is quite difficult to do and benefits from a consistency
across scenes and systems. So screen-aligned PlaneSensor is not about
the event system and in fact does not introduce any new events. So I
am not sure how the question about events applies ? Is about the
DragSensors in general ?
-Andreas
On Thu, Apr 4, 2019 at 9:59 AM Leonard Daly <a class="gmail-m_-5550647162936599440moz-txt-link-rfc2396E" href="mailto:Leonard.Daly@realism.com" target="_blank"><Leonard.Daly@realism.com></a> wrote:
</pre>
<blockquote type="cite">
<pre class="gmail-m_-5550647162936599440moz-quote-pre">[Removed all but the most recent post in thread. Previous post at <a class="gmail-m_-5550647162936599440moz-txt-link-freetext" href="http://web3d.org/mailman/private/x3d-public_web3d.org/2019-April/010460.html" target="_blank">http://web3d.org/mailman/private/x3d-public_web3d.org/2019-April/010460.html</a>]
Andreas,
Reading over the explainer (github link), this looks a lot like an HTML mousedown/mousemove or touchstart/touchmove set of events. So (when running in a browser), is there any substantial difference between the two? I am not counting differences in the output coordinate system (pixels vs. scaled units). If no, then why introduce a new node and events for something that already exists. If yes, please explain what problem this solves that HTML's event system does not.
Independent of the above, how would this work in an stereo immersive environment (headset)?
Leonard Daly
I am working on a spec. comment on screen aligned PlaneSensor
functionality (aka PointSensor in freeWrl or SpaceSensor in Instant)
and developed an example, a description and suggested spec. language
here:
<a class="gmail-m_-5550647162936599440moz-txt-link-freetext" href="https://bl.ocks.org/andreasplesch/f196e98c86bc9dc9686a7e5b4acede7d" target="_blank">https://bl.ocks.org/andreasplesch/f196e98c86bc9dc9686a7e5b4acede7d</a>
<a class="gmail-m_-5550647162936599440moz-txt-link-freetext" href="https://gist.github.com/andreasplesch/f196e98c86bc9dc9686a7e5b4acede7d" target="_blank">https://gist.github.com/andreasplesch/f196e98c86bc9dc9686a7e5b4acede7d</a>
This is an important but currently not available feature which cannot
be implemented with a Proto, at least I cannot think of a way to do.
Any feedback will be welcome. Actually, I have a couple comments
myself in a follow-up message.
-Andreas
--
Leonard Daly
3D Systems & Cloud Consultant
LA ACM SIGGRAPH Past Chair
President, Daly Realism - Creating the Future
</pre>
</blockquote>
<pre class="gmail-m_-5550647162936599440moz-quote-pre"></pre>
</blockquote>
<p><br>
</p>
<div class="gmail-m_-5550647162936599440moz-signature">-- <br>
<font class="gmail-m_-5550647162936599440tahoma,arial,helvetica gmail-m_-5550647162936599440san gmail-m_-5550647162936599440serif" 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>
</div>
_______________________________________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
</blockquote></div>