<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-GB link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US'>Hi,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US'>Following Don’s formal specification comment on this issue I have now raised Mantis issue 1080 (Web3D members can access this at <a href="http://www.web3d.org/member-only/mantis/view.php?id=1080">http://www.web3d.org/member-only/mantis/view.php?id=1080</a>).<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US'>I added as an additional note Leonard Daly’s follow on comment. Subsequently, Don transferred both the original specification comment and Leonards response back to this public list, as this is where this discussion started. I have, therefore, added a reference to each one of the postings on the public list to the Mantis issue.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US'>Finally, I have added “[Mantis 1080]” to the subject line, to make it easy to catch subsequent discussion for addition to the issue.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US'>Regards,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US'>Roy<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><b><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span></b><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif'> x3d-public [mailto:x3d-public-bounces@web3d.org] <b>On Behalf Of </b>Andreas Plesch<br><b>Sent:</b> 25 November 2016 23:01<br><b>To:</b> Don Brutzman <brutzman@nps.edu><br><b>Cc:</b> Leonard Daly <Leonard.Daly@realism.com>; X3D Graphics public mailing list <x3d-public@web3d.org><br><b>Subject:</b> Re: [x3d-public] dynamic cycleInterval changes<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><p>The purpose of modifying the cycleInterval is to slow down or speed up a linked interpolater, in most cases. There is another way to achieve the same effect which is to modify the keyValue field of an interpolater. The equivalent of doubling the cycleInterval would be to half all values in the keyValue field array.<o:p></o:p></p><p>Should both modifications have the same effect ?<o:p></o:p></p><p>I think it is possible to change keyValues at any time. When the interpolater is then used for the next time step, the interpolated value is then computed from the new keyValues, eg. to half of the value it was before the change, in the example above. The animation jumps back.<o:p></o:p></p><p>To mimic this effect for changes to cycleInterval, it would be necessary that the fraction is recomputed in the time step following the change. So a doubling of the cycleInterval would lead to jump from 0.4 to 0.2 of the fractional time.<o:p></o:p></p><p>Overall, I do think that the expectation of most would be that changes in cycleInterval do not lead to jumps, eg. that fraction does not change.<o:p></o:p></p><p>Andreas <o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Nov 25, 2016 3:50 PM, "Don Brutzman" <<a href="mailto:brutzman@nps.edu">brutzman@nps.edu</a>> wrote:<o:p></o:p></p><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><p class=MsoNormal>[continuing dialog...]<br><br>On 11/23/2016 10:59 AM, Leonard Daly wrote:<o:p></o:p></p><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><p class=MsoNormal>Don,<br><br>I disagree with your concluding comment "Best place to fix this is in TimeSensor algorithm/code itself." The specification states (as you quote) "An active TimeSensor node ignores set_cycleInterval ... events". The spec needs to change for the TimeSensor to receive, process, and act of an incoming event that changes cycleInterval.<br><br>Perhaps a better solution is to change the spec to allow TimeSensor to accept and process cycleInterval changes.<o:p></o:p></p></blockquote><p class=MsoNormal><br>Yes that was the entire point of the specification comment: to change TimeSensor specification prose (and corresponding algorithm) to allow dynamic cycleInterval changes.<br><br>So perhaps there is some basis for agreement here after all?<br><br>Am looking at the specification comment description, hopefully it is clear. Roy if appropriate please improve when entering in Mantis, as you think best.<o:p></o:p></p><div><p class=MsoNormal style='margin-bottom:12.0pt'><br><br> "Issue: TimeSensor cycleInterval needs to be modifiable when running"<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><p class=MsoNormal>The question that would need to be resolved is what happens to the current cycle.<o:p></o:p></p></blockquote><p class=MsoNormal style='margin-bottom:12.0pt'><br>Yes that is the important next question if cycleInterval is dynamically modified for a running TimeSensor.<o:p></o:p></p><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><p class=MsoNormal> I can see three options<br><br>1) The TimeSensor would reset (stop and start from the beginning). This works for looping sensors, but may cause problems on a single pass sensor, or one that must have a specific number of cycles before stopping.<br><br>2) The TimeSensor would jump to the same fractional time. For example if the TimeSensor is .4 of the way through a cycle with cycleInterval of 10 (i.e. 4 seconds in), and the cycleInterval was changed to 20, the fractional time would still be .4, but it would take 12 seconds to complete the remaining interval. This is probably the most benign option. It does lead to sudden velocity changes in any animating object.<br><br>3) The TimeSensor would jump to the same real time. For example if the TimeSensor is .4 of the way through a cycle with cycleInterval of 10 (i.e. 4 seconds in), and the cycleInterval was changed to 20, the fractional time would become .2 taking the full 20 seconds to complete this cycle. This options leads to sudden position changes in any animating object.<br><br>There can be other variants where the change happens smoothly, but it may not be worth trying to standardize all possibilities.<br><br>Leonard Daly<o:p></o:p></p></blockquote><p class=MsoNormal style='margin-bottom:12.0pt'><br>My thinking was that, other than accepting a set_cycleInterval event, we should try to avoid any other algorithmic changes unless shown to be absolutely necessary. Specification complexity can be confusing to authors (witness the current cycleInterval problem) and inconsistently implemented if not careful.<br><br>Suggested approach is to consider typical animation examples, use those to determine if anything must be changed in spec, implement and evaluate.<br><br>I suspect that your option (2) is most likely closest to a least-interference update in the algorithm.<br><br>This minimalist approach seems workable if cycleInterval is dynamically reduced (or lengthened) significantly. Of interest is that subsequent set_fraction events make sense as well.<br><br>Of course an author retains full control whatever is decided here... They can always stop/modify/restart a TimeSensor clock, but have to be willing to do that across multiple event loops in order to achieve deterministic response (just like the currently existing situation).<br><br>Thanks for scrutiny of this relatively small X3D change which appears to have important potential improvements for HTML5/DOM and VR external interoperability.<br><br><o:p></o:p></p><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><div><p class=MsoNormal style='margin-bottom:12.0pt'>Comment on 19775-1: Abstract X3D Definitions - V3.3<br>8.4.1 TimeSensor<br><a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/time.html#TimeSensor" target="_blank">http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/time.html#TimeSensor</a><br><br>-----------------<br>Issue: TimeSensor cycleInterval needs to be modifiable when running<br><br>It is not feasible to modify TimeSensor cycleInterval without major<br>machinations and likely failure.<br><br>Spec sayeth:<br><br>8.4.1 TimeSensor<br>"An active TimeSensor node ignores set_cycleInterval and set_startTime<br>events. An active TimeSensor node also ignores set_stopTime events for<br>set_stopTime less than or equal to startTime."<br><br>Email discussion illustrates difficulties with modifying cycleInterval<br>without error.<br>Subject: dynamic cycleInterval changes<br><a href="http://web3d.org/pipermail/x3d-public_web3d.org/2016-November/005566.html" target="_blank">http://web3d.org/pipermail/x3d-public_web3d.org/2016-November/005566.html</a><br><br>Issues such as event-arrival nondeterminism, usability and HTML5/DOM<br>interoperability are all interrelated on this topic.<br><br>Best place to fix this is in TimeSensor algorithm/code itself. Necessary<br>change is to make TimeSensor cycleInterval modifiable when running in order<br>to avoid two-phase commits and a host of other difficulties.<o:p></o:p></p></div><p class=MsoNormal>-----------------<br><br>Submitted on Wednesday, 2016, November 23 - 8:42am<br>by brutzman (brutzman )<br>IP: <a href="tel:162.225.68.164" target="_blank">162.225.68.164</a><br><br>See: <a href="http://www.web3d.org/node/1694/submission/1072" target="_blank">http://www.web3d.org/node/1694/submission/1072</a><o:p></o:p></p></blockquote></blockquote><div><p class=MsoNormal><br>all the best, Don<br>-- <br>Don Brutzman Naval Postgraduate School, Code USW/Br <a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a><br>Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA <a href="tel:%2B1.831.656.2149" target="_blank">+1.831.656.2149</a><br>X3D graphics, virtual worlds, navy robotics <a href="http://faculty.nps.edu/brutzman" target="_blank">http://faculty.nps.edu/brutzman</a><o:p></o:p></p></div></blockquote></div><p class=MsoNormal><o:p> </o:p></p></div></div></body></html>