[x3d-public] isOver not reacting to screen display

Don Brutzman brutzman at nps.edu
Mon Nov 7 16:47:23 PST 2016


as written earlier today: "I wondered if we should add a boolean field for this, but it seems clear that user interaction is an intended prerequisite for TouchSensor activity (i.e. "touching").   If an author wants something to occur when geometry becomes visible, they can use VisibilitySensor instead."

This way player response doesn't automatically take over mysteriously when the user might not even be looking.  Ensuring a deliberate user interaction keeps them in charge, rather than scenes behaving mysteriously or buggily.

so yes, no further spec digging needed, it looks OK.

if someone has a scene that is helpful for other browsers to test such behavior, that would be good to add to the Examples Archives for QA consistency.


On 11/7/2016 1:30 PM, Andreas Plesch wrote:
>     Message: 3
>     Date: Sun, 6 Nov 2016 22:16:29 +0000
>     From: doug sanden <highaspirations at hotmail.com <mailto:highaspirations at hotmail.com>>
>     To: X3D Graphics public mailing list <x3d-public at web3d.org <mailto:x3d-public at web3d.org>>
>     Subject: Re: [x3d-public] passive vs. active mouse isOver event
>     Message-ID:
>             <BN6PR14MB17781D9FA89371F85BCC7D7DB6A40 at BN6PR14MB1778.namprd14.prod.outlook.com <mailto:BN6PR14MB17781D9FA89371F85BCC7D7DB6A40 at BN6PR14MB1778.namprd14.prod.outlook.com>>
>
>     Content-Type: text/plain; charset="iso-8859-1"
>
>     > So if most (all?) older x3d browsers generate the isOver event even
>     >  when the mouse does not move, at some point there was a reason to have
>     >  the spec. say otherwise ?
>     >
>     H0: because it eats cpu cycles/FLOPS/ops - it ray castes on every frame looking if something slipped in under the cursor. Whereas the lazy method waits till the user moves the mouse.
>     H1: like H0 but more specifically allows the ray casting to be done from mouse event stack / mouse thread
>
>
> Ok. In this case the spec. would need to be more permissive and optionally allow this behaviour if browsers wish to sacrifice performance. It explicitly excludes this behaviour, instead, presumably for some other reason. Perhaps a strict interpretation of 'touch'.
>
> There may be some other way to achieve this kind of passive mouse over action ? I believe VisibilitySensor would not actually help here ?
>
> Probably not too productive to dig much deeper.
>
> -Andreas
>
>     ________________________________________
>     From: x3d-public <x3d-public-bounces at web3d.org <mailto:x3d-public-bounces at web3d.org>> on behalf of Andreas Plesch <andreasplesch at gmail.com <mailto:andreasplesch at gmail.com>>
>     Sent: November 6, 2016 2:54 PM
>     To: Joe D Williams
>     Cc: X3D Graphics public mailing list
>     Subject: Re: [x3d-public] passive vs. active mouse isOver event
>
>     On Sun, Nov 6, 2016 at 3:59 PM, Joe D Williams <joedwil at earthlink.net <mailto:joedwil at earthlink.net><mailto:joedwil at earthlink.net <mailto:joedwil at earthlink.net>>> wrote:
>
>     In Tony's old Flux and before, in cosmo and now in BSContct and other latest, when the geomtry moves then the isOver becomes active.
>
>     http://www.hypermultimedia.com/ajax3d/AJAX3Dlogo2.x3d <http://www.hypermultimedia.com/ajax3d/AJAX3Dlogo2.x3d>
>
>     When the X grows to be under the pointer, then the event happens.
>
>     Thanks, this is an excellent example. I tested also in BSContact and confirm that the isOver event is generated even when the mouse pointer is not moved actively.
>
>     http://titania.create3000.de/cobweb/ <http://titania.create3000.de/cobweb/> lets you paste the URL into the URL line at the bottom. It will load and cobweb does not generate the isOver event when the mouse stays fixed (but of course does when the mouse is moved a little bit).
>
>     I tested InstantPlayer as well with this example and it behaves like cobweb.
>
>     Doug says FreeWrl behaves like BSContact.
>
>     So if most (all?) older x3d browsers generate the isOver event even when the mouse does not move, at some point there was a reason to have the spec. say otherwise ?
>
>     http://www.web3d.org/documents/specifications/14772/V2.0/part1/nodesRef.html#TouchSensor <http://www.web3d.org/documents/specifications/14772/V2.0/part1/nodesRef.html#TouchSensor>
>
>     ' Events are not generated if the geometry itself is animating and moving underneath the pointing device.'
>
>     This is sign that sensors are active. Does the event need to be expresed in the same frame as the geometry was moved?
>
>     In case the mouse was moved, the browser can determine for the current cascade if the mouse position changed with respect to the last frame and can then generate the event for the current cascade. This is probably what I would expect. Similarly, the browser can determine if the geometry moved since the last frame with respect to the mouse pointer and if appropriate generate an isOver event for the current cascade.
>
>     I hope it depends upon the the author's choice. Maybe it actually matters to the esimulation. Again an important step or steps in the sequence of discovering what has happened since the last frame.
>
>     Not sure how an author could influence when such events are generated ? It would be more a spec./browser implementation decision, to me.
>
>     -Andreas
>
>     ----- Original Message ----- From: "Andreas Plesch" <andreasplesch at gmail.com <mailto:andreasplesch at gmail.com><mailto:andreasplesch at gmail.com <mailto:andreasplesch at gmail.com>>>
>     To: "X3D Graphics public mailing list" <x3d-public at web3d.org <mailto:x3d-public at web3d.org><mailto:x3d-public at web3d.org <mailto:x3d-public at web3d.org>>>
>     Sent: Saturday, November 05, 2016 1:46 PM
>     Subject: [x3d-public] passive vs. active mouse isOver event
>
>
>     I noticed that cobweb does not generate an isOver TouchSensor event when
>     the pointing device is not moved actively but the sensed geometry itself
>     moves under the mouse pointer. At first this was surprising to me but after
>     reading
>
>     http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/pointingsensor.html#TouchSensor <http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/pointingsensor.html#TouchSensor>
>
>     this seems to be the expected behaviour since active mouse movement is
>     required to generate events.
>
>     Do other browser behave the same way ?
>
>     -Andreas
>
>     --
>     Andreas Plesch
>     39 Barbara Rd.
>     Waltham, MA 02453
>
>
>
>     --------------------------------------------------------------------------------
>
>
>     _______________________________________________
>     x3d-public mailing list
>     x3d-public at web3d.org <mailto:x3d-public at web3d.org><mailto:x3d-public at web3d.org <mailto:x3d-public at web3d.org>>
>     http://web3d.org/mailman/listinfo/x3d-public_web3d.org <http://web3d.org/mailman/listinfo/x3d-public_web3d.org>
>
>
>
>
>
>     --
>     Andreas Plesch
>     39 Barbara Rd.
>     Waltham, MA 02453
>
>
>
>     ------------------------------
>
>     Subject: Digest Footer
>
>     _______________________________________________
>     x3d-public mailing list
>     x3d-public at web3d.org <mailto:x3d-public at web3d.org>
>     http://web3d.org/mailman/listinfo/x3d-public_web3d.org <http://web3d.org/mailman/listinfo/x3d-public_web3d.org>
>
>
>     ------------------------------
>
>     End of x3d-public Digest, Vol 92, Issue 13
>     ******************************************
>
>
>
>
> --
> Andreas Plesch
> 39 Barbara Rd.
> Waltham, MA 02453
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>


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



More information about the x3d-public mailing list