<div dir="ltr"><div dir="ltr">I'm pretty sure I took out the KickStart/JumpStart/Prelude timer, and I rely on ProximitySensors. What startTime are you going to start the PreludeTimer with? Inquiring minds want to know!  Sure seems like it should start on its own, heh? If you can deduce a constant startTime, in the beginning, without a proximity sensor, that would be awesome, otherwise...we're probably animating from the 1970's, or halfway between here and there.  No, I do not have experience with Audio yet.  Just put the needle in the groove. Or search for the needle in the haystack. Oh dear, metaphors.</div><div dir="ltr"><br></div><div>More generally,  speaking of other Timers:</div><div><br></div><div dir="ltr">No, do not send the cycleTime to the stopTime. Wrong path.  In general, animation should loop on its own, and then be stopped by the BooleanSequencer.  The BooleanSequencers (timing which works with the main TimeSensor and filters to individual animations) should decide when an animation starts or stops.  CycleInterval loops are more intended to make sure the animation runs independently at the right speed. If you get cycleInterval involved in overall timing, your animations will be sped up or slowed down in ways you don't like.<div><br></div><div>Or as everyone was recommending to me, Just read Don's examples! :)   Sounds back at Andreas's emails when we were talking about alternating animations.  I got rid of the ScalarInterpolator (ScInterp?), but consider adding it back to control BooleanSequencers.  There's a lot to consider.</div><div><br></div><div>WS may be bailing wire wrapped!  I agree that the BooleanSequencers are a bit overdone, but there could be even smaller ones and more of them, if you desire!</div><div><br></div><div><br></div><div><br></div><div><br></div><div>John</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 8, 2023 at 8:34 PM Joe D Williams <<a href="mailto:joedwil@earthlink.net">joedwil@earthlink.net</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">Hi Andreas,<br>
I really looking at this now. Basically I want a short timer to run for one cycle without controlling much of anything, then start the main scene timer for one cycle. <br>
Heavy study, the TimeSensor.<br>
And how they work with other time things, like audio and video.<br>
So, I misunderstood and thought loop must be true to start.<br>
But yes, when timer not running, enabled true and loop false, a good startTime will have it run for one cycle.<br>
That is my problem. getting that startTime. <br>
<br>
Now for the trick of sending  cycleTime of starter direct to its stopTime. This certainly stops the start timer. <br>
First, the cycleTime is sent same as startTime, at the beginning of each cycle.<br>
So, sending cycleTime to its stopTime stops it (almost) immediately.<br>
For sure the timer should not run past the next tic after receiving the stopTime. The cycleTime, is sent at fraction 0, when the first valueChanged is is ready, So at most, the timer should run for 1 or 2 tics then stop.<br>
<br>
That is not quite what I want. I need the starter time to run through one cycle, then start the main clock, which I only want to run for one cycle, then stop at last frame. <br>
<br>
Thanks for the examples, I am using it and more to be shown a bit later.<br>
Thanks Again,<br>
Joe<br>
<br>
<br>
<br>
-----Original Message-----<br>
From: Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>><br>
Sent: Sep 8, 2023 2:03 PM<br>
To: Brutzman, Donald (Don) (CIV) <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>><br>
Cc: X3D Graphics public mailing list <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>><br>
Subject: Re: [x3d-public] start timer at fraction 0 after scene loading<br>
<br>
Another option may be an official COMMENT statement which cannot be<br>
stripped out and would standardize arbitrary comments across<br>
encodings. It would be very similar to a top level [ MetadataString<br>
name='comment' value='general comment' ] node with a small semantic<br>
difference (should only refer to the code itself, not its content) but<br>
clearer and a bit more concise. The statement could appear anywhere<br>
and is completely ignored by the browser. It sounds like something<br>
which may have been discussed in the deeper past.<br>
<br>
Oftentimes it suffices to choose good DEF names to help with<br>
readability. In this case the DEF names were provided in the original<br>
NIST example and were not too helpful. Better names may be 'STARTER'<br>
for TIME1 and 'TIMER' for TIME2.<br>
<br>
Best,<br>
<br>
-Andreas<br>
<br>
On Fri, Sep 8, 2023 at 3:18 PM Brutzman, Donald (Don) (CIV)<br>
wrote:<br>
><br>
> Very interesting, thanks for sharing Andreas. We should all be thinking of regularizing some example design patterns like animation.<br>
><br>
><br>
><br>
> Meanwhile, your example is the kind that makes me think we should have a description field for ROUTE.<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> Potential alternative approaches for ROUTE comments:<br>
><br>
><br>
><br>
> Comments? Sure, but sometimes get stripped, and not unambiguously readable by tools.<br>
> Prototype extension? Too complex and error prone, fuggedaboutit.<br>
> Metadata nodes? Hmm, we can't make those part of ROUTE statements themselves, not allowed.<br>
><br>
><br>
><br>
> Maybe some clumsy-but-unambiguous convention like the following already-legal X3D fragment:<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> Of course simplest future approach would be to give ROUTE a description field. Hmmm, maybe someday.<br>
><br>
><br>
><br>
> Might deserve a Mantis issue for X3D4.1 if others agree some potential value exists for future consideation.<br>
><br>
><br>
><br>
> all the best, Don<br>
><br>
> --<br>
><br>
> Don Brutzman Naval Postgraduate School, Code USW/Br <a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a><br>
><br>
> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149<br>
><br>
> X3D graphics, virtual worlds, navy robotics <a href="https://faculty.nps.edu/brutzman" rel="noreferrer" target="_blank">https://faculty.nps.edu/brutzman</a><br>
><br>
><br>
><br>
> -----Original Message-----<br>
> From: x3d-public On Behalf Of Andreas Plesch<br>
> Sent: Thursday, September 7, 2023 1:43 PM<br>
> To: X3D Graphics public mailing list<br>
> Subject: Re: [x3d-public] start timer at fraction 0 after scene loading<br>
><br>
><br>
><br>
> Here is an initial count down after loading the scene using the same autostart method, and a sequencer:<br>
><br>
><br>
><br>
> <a href="https://andreasplesch.github.io/Library/Viewer/dev.html?url=https://gist.githubusercontent.com/andreasplesch/3f7ea30b9860b6399c797c51e3235459/raw/d17f9d2a0a258569ac5a474c36a68208674d535e/countdown.x3d" rel="noreferrer" target="_blank">https://andreasplesch.github.io/Library/Viewer/dev.html?url=https://gist.githubusercontent.com/andreasplesch/3f7ea30b9860b6399c797c51e3235459/raw/d17f9d2a0a258569ac5a474c36a68208674d535e/countdown.x3d</a><br>
><br>
><br>
><br>
> <a href="https://create3000.github.io/x_ite/playground/?url=https://gist.githubusercontent.com/andreasplesch/3f7ea30b9860b6399c797c51e3235459/raw/d17f9d2a0a258569ac5a474c36a68208674d535e/countdown.x3d" rel="noreferrer" target="_blank">https://create3000.github.io/x_ite/playground/?url=https://gist.githubusercontent.com/andreasplesch/3f7ea30b9860b6399c797c51e3235459/raw/d17f9d2a0a258569ac5a474c36a68208674d535e/countdown.x3d</a><br>
><br>
><br>
><br>
> -Andreas<br>
><br>
><br>
><br>
> On Thu, Sep 7, 2023 at 1:01 AM Andreas Plesch wrote:<br>
><br>
> ><br>
><br>
> > Another method apart from a ProximitySensor to start a timer without<br>
><br>
> > user interaction after scene loading is to use two TimeSensors. The<br>
><br>
> > first has loop=true and its only purpose is to trigger the second by<br>
><br>
> > routing its cycleTime to the startTime of the second TimeSensor. The<br>
><br>
> > first also stops itself by routing its cycleTime to its own stopTime.<br>
><br>
> ><br>
><br>
> > Here is an example modified from the cycleTime NIST example:<br>
><br>
> ><br>
><br>
> > <a href="https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Frent" rel="noreferrer" target="_blank">https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Frent</a><br>
><br>
> > <a href="http://ry.co" rel="noreferrer" target="_blank">ry.co</a>%2Fx3d-startTimer&amp;data=05%7C01%7Cbrutzman%<a href="http://40nps.edu" rel="noreferrer" target="_blank">40nps.edu</a>%7C4b415083034<br>
><br>
> > 641d371e608dbafe335ef%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638<br>
><br>
> > 297162641403741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2<br>
><br>
> > luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=v3ah%2F2OY7<br>
><br>
> > NVzEwTUIhRhBjG%2BNHdMZoJTbsC3lEnHR1I%3D&amp;reserved=0<br>
><br>
> ><br>
><br>
> > <a href="https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fandr" rel="noreferrer" target="_blank">https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fandr</a><br>
><br>
> > <a href="http://easplesch.github.io" rel="noreferrer" target="_blank">easplesch.github.io</a>%2FLibrary%2FViewer%2Fdev.html%3Furl%3Dhttps%3A%2F%<br>
><br>
> > <a href="http://2Fgist.githubusercontent.com" rel="noreferrer" target="_blank">2Fgist.githubusercontent.com</a>%2Fandreasplesch%2F3f7ea30b9860b6399c797c5<br>
><br>
> > 1e3235459%2Fraw%2F118d65438f9cfdc152c01fc5a24a8eccec705511%2FstartTime<br>
><br>
> > r.x3d&amp;data=05%7C01%7Cbrutzman%<a href="http://40nps.edu" rel="noreferrer" target="_blank">40nps.edu</a>%7C4b415083034641d371e608dbafe3<br>
><br>
> > 35ef%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638297162641403741%7<br>
><br>
> > CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1<br>
><br>
> > haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=m8xOnL%2BHHQy5gXlqLQaec6vBIi<br>
><br>
> > %2BSchjeWtKfYWNDMHw%3D&amp;reserved=0<br>
><br>
> ><br>
><br>
> > --<br>
><br>
> > Andreas Plesch<br>
><br>
> > Waltham, MA 02453<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> --<br>
><br>
> Andreas Plesch<br>
><br>
> Waltham, MA 02453<br>
><br>
><br>
><br>
> _______________________________________________<br>
><br>
> x3d-public mailing list<br>
><br>
> <a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
><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>
<br>
<br>
<br>
--<br>
Andreas Plesch<br>
Waltham, MA 02453<br>
<br>
_______________________________________________<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>
<br>
<br>
<br>
_______________________________________________<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>