<div dir="auto">This is long winded, with no actual point. TL;DR.</div><div dir="auto"><br></div><div dir="auto">Keep trying, Joe, It would be good to try to reduce my monstrosity, I agree. There is likely stuff that can be trimmed, I’m just reluctant to change what works at this point. Once you get 3 animations chained, try 4, 5 or more. I trust Andreas, Holger and Michalis, I just took out the ScalarInterpolator plus doubling of values in key and keyValue because I didn’t think we had a need for them (oops?). For different, non-linear timing, a ScInterp would be a requirement, as Andreas pointed out.</div><div dir="auto"><br></div><div dir="auto">If something else easier worked for individual characters, I would probably would have stumbled upon it. I hate to see you stumbling in similarly ways.</div><div dir="auto"><br></div><div dir="auto">The thing is, you actually want chained animations to cycle naturally, loop, etc. Independent of start/stop. That is, you don’t want to stop them when they hit cycleTime. No, I don’t know how to tie movements together cohesively. I think Holger said it requires scripting. That’s an issue I will face with sign language.</div><div dir="auto"><br></div><div dir="auto">Best practices for event chaining for a multiple character, multiple file solution should be documented and shared, not hidden away and not revealed. Is the Monterey Fish Tank Animation a good example from the X3D archives? That would be cool to see in the new HTML route debugger.</div><div dir="auto"><br></div><div dir="auto">Sharing my code is up to you and Don, Joe. I’ve mostly done what I can in a single file, but I’m available if you have questions. I can also post my working code for people to comment on and improve upon. That would be great if I had permission to do that. I’m also pursuing other avenues for publishing what I’ve done separately (not WS stuff). We can even probably substitute a different skin if we want to show what we’ve all accomplished, Re: event utilities, separate from WS. But yeah, a monstrosity that works (in view3dscene). I’d like to ship a file to Holger.</div><div dir="auto"><br></div><div dir="auto">So far, I haven’t found something that X3D/view3dscene cannot handle! And I’m not even including Script nodes, although I almost resorted to them.</div><div dir="auto"><br></div><div dir="auto">John</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Sep 9, 2023 at 2:37 PM Joe D Williams <<a href="mailto:joedwil@earthlink.net">joedwil@earthlink.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">inline comments<br>
-----Original Message-----<br>
From: Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>><br>
Sent: Sep 8, 2023 9:27 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>
> A variation would be for the start timer to self-disable by routing<br>
its cycleTime through event utilities to set its enabled field to<br>
false.<br>
<br>
Right, I have done that and it works, If I send a false to loop before fraction 1 best results. Seems like the loop false needs to be sent slightly before sequencer fraction 1 to get the timer to stop at last frame.<br>
<br>
What I need is to catch the second StartTimer cycleTime to send to MainTimer startTime. <br>
<br>
For some reason the StartTimer, when halted like that, does not have a useable stopTime. <br>
In fact, I can't find a usable stop-Time. This should work:<br>
<br>
<TimeSensor DEF='TIME1' cycleInterval='1' loop='true'/><br>
<TimeSensor DEF='TIME2' cycleInterval='5' loop='false'/><br>
<TimeSensor DEF='TIME3' cycleInterval='10' loop='false'/>:<br>
<ROUTE fromField='cycleTime' fromNode='TIME1' toField='set_stopTime' toNode='TIME1'/> <br>
<ROUTE fromField='stopTime' fromNode='TIME1' toField='set_startTime' toNode='TIME2'/> <br>
<ROUTE fromField='stopTime' fromNode='TIME2' toField='set_startTime' toNode='TIME3'/><br>
<br>
Timer1 should start and be stopped a tic or two after its cycleTime is sent. <br>
Timer 2 gets started by Timer1 cycleTime (couldn't get Timer1 startTime or stopTime to be usable).<br>
TImer2 completes at fraction 1 and sends its stopTime to Timer3 startTime. <br>
Timer 3 starts, then stops at fraction 1.<br>
Wait, the timer2 stopTime doesn't work like expected, so Timer 3 never Starts.<br>
<br>
So, attached is what I have. I don't see why timer3 never gets started.<br>
Thanks,<br>
Joe <br>
<br>
> is more verbose but may help a bit with performance since<br>
the browser then does not need to check stopTime against the actual<br>
current time at each tick, for a timer which is never used again.<br>
<br>
> It would be useful if BooleanFilter would have a triggerFalse field in<br>
addition to its triggerTrue, in order to switch off things. It could<br>
be just added without backward compatibility issues. A BooleanFilter<br>
can invert but it seems arbitrary and unsymmetrical to only have<br>
triggerTrue. I have a sense of Dejavu since event utilities had been<br>
discussed before.<br>
<br>
Cheers, 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&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&sdata=v3ah%2F2OY7<br>
><br>
> > NVzEwTUIhRhBjG%2BNHdMZoJTbsC3lEnHR1I%3D&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&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&sdata=m8xOnL%2BHHQy5gXlqLQaec6vBIi<br>
><br>
> > %2BSchjeWtKfYWNDMHw%3D&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>
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></div>