[x3d-public] dynamic cycleInterval changes
Don Brutzman
brutzman at nps.edu
Mon Nov 21 07:17:38 PST 2016
I think that sending a default value of 0 or -1 might be a good case. Those are valid time values, and they clearly indicate stopping.
Another case worth thinking about is if a stop event was sent from the external HTML browser, and perhaps slightly delayed each time, making the TimeSensor unstoppable from that device.
An additional way to think about this is considering what use cases might be where an author or user wants stopTime ignored? If we're not clear on what problem we're addressing, the stopTime might be a needless/counterproductive complication.
On 11/21/2016 4:10 AM, Andreas Plesch wrote:
> Yes, I meant to say cycleInterval as used in the script. Sorry for the confusion.
>
> I think the idea is to stop the sensor by sending a stop time of the current moment, or a future moment. Is there a situation when it would make sense to send a stop time which lies in the past ?
>
> Andreas
>
>
> On Nov 21, 2016 1:04 AM, "Don Brutzman" <brutzman at nps.edu <mailto:brutzman at nps.edu>> wrote:
>
> Note correct field name please:
>
> - cycleTime fields are outputOnly event producers, occurring at the end of a TimeSensor cycle.
>
> - cycleInterval is the inputOutput duration of a TimeSensor loop.
>
> X3D spec indeed sayeth:
>
> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/time.html#TimeSensor <http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/time.html#TimeSensor>
> ===================
> An active TimeSensor node ignores set_cycleInterval and set_startTime events.
> An active TimeSensor node also ignores set_stopTime events for set_stopTime less than or equal to startTime.
> ===================
>
> So any reset would have to modify enable false before adjusting cycleInterval, then restart it using enable true.
>
> Not sure what benefit the second sentence has. If someone was trying to stop a TimeSensor by sending it a 0 or -1, it would be ignored... unstoppable. Seems like a bad idea. Should we change that?
>
> Added tooltips for these warnings. Checked in but not deployed online yet, pending web server upgrade/transition.
>
> Further clarifications welcome:
>
> http://www.web3d.org/x3d/tooltips/X3dTooltips.html#TimeSensor <http://www.web3d.org/x3d/tooltips/X3dTooltips.html#TimeSensor>
>
> On 11/20/2016 3:16 PM, Andreas Plesch wrote:
>
> https://raw.githubusercontent.com/andreasplesch/cobweb_dom/master/tests/dynamicCycleTime.x3d <https://raw.githubusercontent.com/andreasplesch/cobweb_dom/master/tests/dynamicCycleTime.x3d>
>
> is now updated to fix a missing semicolon and works as expected in BS Contact as well as in freeWRL.
>
> But both cobweb and Instant Player still do not slow down the ball.
>
> So there is some kind of event processing problem in these browsers, it seems.
>
> -Andreas
>
> On Sun, Nov 20, 2016 at 3:36 PM, Andreas Plesch <andreasplesch at gmail.com <mailto:andreasplesch at gmail.com> <mailto:andreasplesch at gmail.com <mailto:andreasplesch at gmail.com>>> wrote:
>
> I want to change the cycleTime of a TimeSensor in a x3d script:
>
> https://raw.githubusercontent.com/andreasplesch/cobweb_dom/master/tests/dynamicCycleTime.x3d <https://raw.githubusercontent.com/andreasplesch/cobweb_dom/master/tests/dynamicCycleTime.x3d> <https://raw.githubusercontent.com/andreasplesch/cobweb_dom/master/tests/dynamicCycleTime.x3d <https://raw.githubusercontent.com/andreasplesch/cobweb_dom/master/tests/dynamicCycleTime.x3d>>
>
> cycleTime input events are ignored when the TimeSensor is enabled. So it is necessary to disable it first, then change the cycleTime and then reenable it.
>
> However, in all tested browser the above does not work as expected. These are cobweb, instant player and bs contact. bs contact also has this console message:
> Script node speeder: parse error: line 16 "time.cycleInterval = 2;" ()
> and therefore does not get to change the color to grey.
> The javascript sai does not have a SFTime constructor and allows numbers.
>
> cobweb and instant player change the color but do not slow down the ball.
> I first thought that cobweb does not correctly work through the sequence of events but since no browser works sofar I start to think that I am missing something.
>
> Any help or feedback appreciated,
>
> -Andreas
>
> On Sat, Nov 19, 2016 at 8:39 PM, Andreas Plesch <andreasplesch at gmail.com <mailto:andreasplesch at gmail.com> <mailto:andreasplesch at gmail.com <mailto:andreasplesch at gmail.com>>> wrote:
>
> Hi Roy,
>
> Here is a cobweb version of the updated example:
>
> https://rawgit.com/andreasplesch/cobweb_dom/master/tests/html5/cobweb_integration2.html <https://rawgit.com/andreasplesch/cobweb_dom/master/tests/html5/cobweb_integration2.html> <https://rawgit.com/andreasplesch/cobweb_dom/master/tests/html5/cobweb_integration2.html <https://rawgit.com/andreasplesch/cobweb_dom/master/tests/html5/cobweb_integration2.html>>
>
> I removed all features which are only supported by or necessary for the x3dom version.
>
> The main necessary changes were:
>
> - use setAttribute on DOM elements rather than DOM element properties because cobweb does not create these properties. x3dom allows for using setAttribute() in addition to setting properties.
>
> - use a TouchSensor node to enable clicking on the ball instead of the onclick attribute. Cobweb ignores the onclick attribute and x3dom ignores the touch sensor. In Cobweb the TouchSensor generates and is the target of a dom event ('x3d_touchTime') which can be received by an installed listener. The .addEventListener() call does this.
>
> - modify the scale attribute of the enclosing transform instead of the radius attribute of the sphere since radius is not recognized as an input field in Cobweb as it interprets the spec. this way.
>
> I also looked more closely into why I had to introduce a timeout delay to make the TimeSensor cycleInterval change have an effect. It turns that there were multiple reasons. Interestingly, the first reason had to do with how the DOM spec. defines Mutation Observers and I filed a spec. issue:
> https://github.com/whatwg/dom/issues/376 <https://github.com/whatwg/dom/issues/376> <https://github.com/whatwg/dom/issues/376 <https://github.com/whatwg/dom/issues/376>>
> In effect, the enabled='false' mutation was not reported fully. I could fix this in cobweb_dom, so it was a worthy investigation.
> Also interestingly, the second reason had to with how cobweb processes input events. From what I understand first fields get tainted and are then processed in the cascade. I think the second set_enabled event occurred before the first had a chance to be processed and reset the target value back. This was also possible to fix in cobweb_dom by forcing processing after each mutation (input event).
>
> As a result, the delay is not necessary anymore and the sequence works as expected.
>
> -Andreas
>
> On Sat, Nov 12, 2016 at 5:48 AM, Roy Walmsley <roy.walmsley at ntlworld.com <mailto:roy.walmsley at ntlworld.com> <mailto:roy.walmsley at ntlworld.com <mailto:roy.walmsley at ntlworld.com>>> wrote:
>
> Hi Andreas,____
>
> __ __
>
> Having a Cobweb version is great. Thank you very much.____
>
> __ __
>
> You’re comments are also interesting. Lots of food for thought. I will modify both examples to illustrate using X3D output events as well, as I have completely missed that feature. I’ll also modify the titles to include the implementation, and put both on the web site.____
>
> __ __
>
> Regards,____
>
> __ __
>
> Roy____
>
> __ __
>
> *From:*Andreas Plesch [mailto:andreasplesch at gmail.com <mailto:andreasplesch at gmail.com> <mailto:andreasplesch at gmail.com <mailto:andreasplesch at gmail.com>>]
> *Sent:* 12 November 2016 01:19
> *To:* Roy Walmsley <roy.walmsley at ntlworld.com <mailto:roy.walmsley at ntlworld.com> <mailto:roy.walmsley at ntlworld.com <mailto:roy.walmsley at ntlworld.com>>>
> *Cc:* X3D Graphics Working Group <x3d at web3d.org <mailto:x3d at web3d.org> <mailto:x3d at web3d.org <mailto:x3d at web3d.org>>>
> *Subject:* Re: X3D / DOM integration example using X3DOM____
>
> __ __
>
> Hi Roy,____
>
> this is a nice example, demonstrating main integration features.____
>
> I modified it to work with cobweb_dom:____
>
> https://rawgit.com/andreasplesch/cobweb_dom/master/tests/html5/cobweb_integration.html <https://rawgit.com/andreasplesch/cobweb_dom/master/tests/html5/cobweb_integration.html> <https://rawgit.com/andreasplesch/cobweb_dom/master/tests/html5/cobweb_integration.html <https://rawgit.com/andreasplesch/cobweb_dom/master/tests/html5/cobweb_integration.html>>____
>
> This should also still work mostly unchanged with x3dom although it looks perhaps quite different.____
>
> The main necessary changes were:____
>
> - use setAttribute on DOM elements rather than DOM element properties because cobweb does not create these properties. x3dom allows for using setAttribute.____
>
> - use a TouchSensor node to enable clicking on the ball instead of the onclick attribute. Cobweb ignores the onclick attribute and x3dom ignores the touch sensor.____
>
> - introduce a small delay after disabling the time sensor to make sure it is actually disabled when the cycle interval is set in an input event. This looks like it should not be necessary to do, so will require some investigation.____
>
> - modify the scale attribute instead of the radius attribute since radius is not an input field. Cobweb follows the spec. strictly, x3dom is more liberal. Radius should become an input field.____
>
> So two questions emerge:____
>
> Should DOM element properties be required? No, in my opinion, since attributes are the more fundamental component and definitely required in the XML encoding. It is probably possible to have another layer which translates attributes into properties and back.____
>
> Which x3d output events should be exposed and how ? Following x3d conventions (TouchSensor) or following DOM event conventions (click) ? Undecided, leaning towards x3d, perhaps both. x3dom and Cobweb expose all output events, x3dom with outputchange and Cobweb with x3d_eventname.
> (It would be probably possible to implement click and other dom event dispatchers by adding sensor nodes to the scene graph but not to the dom tree).____
>
> Andreas ____
>
> __ __
>
> On Fri, Nov 11, 2016 at 10:13 AM, Roy Walmsley <roy.walmsley at ntlworld.com <mailto:roy.walmsley at ntlworld.com> <mailto:roy.walmsley at ntlworld.com <mailto:roy.walmsley at ntlworld.com>>> wrote:____
>
> Hi all,____
>
> ____
>
> Following Wednesday’s open meeting I have put together an example that illustrates the integration of an X3D scene into an HTML web page, that also incorporates SVG. It includes events, both X3D and HTML. There is also interaction between X3D, SVG, and HTML in multiple directions.____
>
> ____
>
> The intention was to provide a simple (but not high quality!) example to facilitate thinking about specification requirements.____
>
> ____
>
> Sorry that I couldn’t put the example directly onto one of our web pages. But it should be easy for you to copy and paste to create your own file and open it up in a browser. The only browser that’s failed me so far is Safari.____
>
> ____
>
> Here’s the link: http://www.web3d.org/member/wiki/x3d-svg-html-dom-integration-example-using-x3dom <http://www.web3d.org/member/wiki/x3d-svg-html-dom-integration-example-using-x3dom> <http://www.web3d.org/member/wiki/x3d-svg-html-dom-integration-example-using-x3dom <http://www.web3d.org/member/wiki/x3d-svg-html-dom-integration-example-using-x3dom>>____
>
> ____
>
> Have fun,____
>
> ____
>
> Roy____
>
> ____
>
> PS As it came up on Wednesday I have also added an HTML slider, demonstrating instant updating.____
>
>
>
> ____
>
> __ __
>
> -- ____
>
> Andreas Plesch
> 39 Barbara Rd.
> Waltham, MA 02453____
>
>
>
>
> --
> Andreas Plesch
> 39 Barbara Rd.
> Waltham, MA 02453
>
>
>
>
> --
> Andreas Plesch
> 39 Barbara Rd.
> Waltham, MA 02453
>
>
>
>
> --
> Andreas Plesch
> 39 Barbara Rd.
> Waltham, MA 02453
>
>
> _______________________________________________
> 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>
>
>
>
> all the best, Don
> --
> Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu <mailto:brutzman at nps.edu>
> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149 <tel:%2B1.831.656.2149>
> X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman <http://faculty.nps.edu/brutzman>
>
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