<div dir="ltr">Questions:  Can you change animations without user input or scripts?<div><br></div><div>Thanks, great examples.</div><div><br></div><div>JOhn</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 16, 2023 at 2:15 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">What a great lesson, Thanks Andreas. Is it too early to ask if result is pretty much the same if new set of keys and/or a set of keyValues are sent in live?<br>
Say I want to change the motion from constant rotation to a path where it spins faster for part of the rotation and slower for the rest? <br>
That is fun and nlce demo of proto behavior.<br>
Joe<br>
<br>
-----Original Message-----<br>
From: Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>><br>
Sent: Aug 16, 2023 11:12 AM<br>
To: X3D Graphics public mailing list <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>><br>
Subject: Re: [x3d-public] change to cycleTime perhaps no longer ignored , example ?<br>
<br>
I found that it should be ok to adjust the startTime after<br>
cycleInterval was changed. The only time when startTime_changed is<br>
emitted is directly after a set_startTime was received. So the<br>
adjusted startTime would never be emitted and cannot disturb any<br>
processing. Presumably a script could access the startTime field at<br>
any time but it is not unreasonable to expect that it may have changed<br>
along with a cycleInterval change given the spec. algorithm for<br>
fraction.<br>
<br>
Clicking on the column in the example now also tests if pauseTime and<br>
resumeTime still works since resumeTime also needs to maintain<br>
fraction for resuming:<br>
<br>
<a href="https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/bb3ee65b6748644f640cd5b73f30ed6e/raw/6ceca45348203b6faf8d8563d8fee7aa490e56b9/dynamicCycleInterval.x3d" rel="noreferrer" target="_blank">https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/bb3ee65b6748644f640cd5b73f30ed6e/raw/6ceca45348203b6faf8d8563d8fee7aa490e56b9/dynamicCycleInterval.x3d</a><br>
<br>
<a href="https://create3000.github.io/x_ite/playground/?url=https://gist.githubusercontent.com/andreasplesch/bb3ee65b6748644f640cd5b73f30ed6e/raw/6ceca45348203b6faf8d8563d8fee7aa490e56b9/dynamicCycleInterval.x3d" rel="noreferrer" target="_blank">https://create3000.github.io/x_ite/playground/?url=https://gist.githubusercontent.com/andreasplesch/bb3ee65b6748644f640cd5b73f30ed6e/raw/6ceca45348203b6faf8d8563d8fee7aa490e56b9/dynamicCycleInterval.x3d</a><br>
<br>
This uses event utilities in their typical verbose fashion.<br>
<br>
Seems to work fine.<br>
<br>
A subtlety is that in the example only the animation clock is paused<br>
while the interval clock continues to run in the background. This<br>
means that after resuming the cycleInterval may change at any moment<br>
(unless one keeps track manually of the 7s period change period).<br>
<br>
I think I will also adapt Holger's example to xdom scripting for<br>
testing, and that should suffice for providing the feature in a x3dom<br>
dev. version.<br>
<br>
Any feedback or thoughts always welcome,<br>
<br>
Andreas<br>
<br>
On Wed, Aug 16, 2023 at 9:09 AM Andreas Plesch wrote:<br>
><br>
> <a href="https://gist.github.com/andreasplesch/bb3ee65b6748644f640cd5b73f30ed6e#file-dynamiccycleinterval-x3d" rel="noreferrer" target="_blank">https://gist.github.com/andreasplesch/bb3ee65b6748644f640cd5b73f30ed6e#file-dynamiccycleinterval-x3d</a><br>
><br>
> has the rotating column example in a format which can work both in x3dom and in x_ite:<br>
><br>
> <a href="https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/bb3ee65b6748644f640cd5b73f30ed6e/raw/c04865919178d0b26f49d49982bc31a3da56c2e9/dynamicCycleInterval.x3d" rel="noreferrer" target="_blank">https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/bb3ee65b6748644f640cd5b73f30ed6e/raw/c04865919178d0b26f49d49982bc31a3da56c2e9/dynamicCycleInterval.x3d</a><br>
><br>
> <a href="https://create3000.github.io/x_ite/playground/?url=https://gist.githubusercontent.com/andreasplesch/bb3ee65b6748644f640cd5b73f30ed6e/raw/c04865919178d0b26f49d49982bc31a3da56c2e9/dynamicCycleInterval.x3d" rel="noreferrer" target="_blank">https://create3000.github.io/x_ite/playground/?url=https://gist.githubusercontent.com/andreasplesch/bb3ee65b6748644f640cd5b73f30ed6e/raw/c04865919178d0b26f49d49982bc31a3da56c2e9/dynamicCycleInterval.x3d</a><br>
><br>
> It has simple type converter scripts with directOutput for both. x3dom ignores the x3d script and x_ite ignores the dom script and the onoutputchange attribute. In addition, the x_ite playground strips out all the non-parseable nodes in the editor, so the file appears more tidy. Everything else is the same.<br>
><br>
> The type converter scripts do not actually do anything since the Javascript SAI type for both SFFloat and SFTime is the same (numeric).<br>
><br>
> The example works for both. view3dscene probably would have to have a version with castlescript. Thinking about adding pause and resume when clicking on the column.<br>
><br>
> I will see if I can adjust cycleTime instead of startTime to maintain the fraction after a cycleInterval change.<br>
><br>
> On Tue, Aug 15, 2023 at 11:23 PM Andreas Plesch wrote:<br>
> ><br>
> > Sorry, for some reason I keep typing cycleTIme when I mean cycleInterval.<br>
> ><br>
> > Good idea to adjust cycleTime and use cycleTime to calculate fraction<br>
> > although it deviates slightly from the spec. algorithm (but gives the<br>
> > same result).<br>
> ><br>
> > Since cycleTime is updated anyways during the next cycle, I think it<br>
> > is ok to update it during the same cycle when cycleInterval was<br>
> > changed since it would not be emitted anyways until the start of the<br>
> > next cycle.<br>
> ><br>
> > I ran into another problem, the lack of suitable SFTime event sources<br>
> > to route to cycleTime.<br>
> ><br>
> > In order to come up with the simplest possible test scene for changing<br>
> > cycleInterval, I was hoping to find a way to feed cycleInterval a<br>
> > suitable SFTime value without using a script. I was hoping to use<br>
> > TimeTrigger but TimeTrigger only emits the absolute current time<br>
> > (seconds after 1970). Also all other sources of SFTime events I could<br>
> > find emit absolute time values except for elapsedTIme. But it would be<br>
> > necessary to wait a full cycle (say 7s) every time such an SFTime<br>
> > event is needed so this is not useful.<br>
> > Finally, there is cycleInterval itself which is [in, out] but is only<br>
> > emitted when it is changed and never otherwise. So this is also not<br>
> > useful.<br>
> ><br>
> > This means it is only possible to change cycleInterval in a useful way<br>
> > with a Script node.<br>
> ><br>
> > Most other input fields of any node, probably all fields, can be<br>
> > usefully modified without a Script node, for good reason.<br>
> ><br>
> > Should X3D also have a convenient source for duration type SFTime values ?<br>
> ><br>
> > Low impact proposals for sources of relative (small in size) time<br>
> > SFTime events could be:<br>
> ><br>
> > - add a field to TimeTrigger SFTime [in,out] triggerValue, same as in<br>
> > IntegerTrigger, which can hold a custom value.<br>
> > - emit a cycleInterval event when a TimeSensor becomes active along<br>
> > with isActive. This way a TimeSensor can become something like a<br>
> > TimeTrigger<br>
> ><br>
> > Higher impact would be:<br>
> ><br>
> > - a new TimeSequencer node<br>
> > - a new TimeInterpolator node (too strange probably but could be used<br>
> > for strange time compression or dilation effects)<br>
> > - a new type converter node which can convert SFFloat to SFTime,<br>
> > should be easy to implement but could have unforeseeable impact.<br>
> ><br>
> > For the time being I think this means that I will add a type converter<br>
> > script to my earlier test example, both for x3dom type scripts and x3d<br>
> > type scripts.<br>
> ><br>
> > Cheers, Andreas<br>
> ><br>
> ><br>
> ><br>
> > On Tue, Aug 15, 2023 at 6:42 PM Holger Seelig wrote:<br>
> > ><br>
> > > I recalculate the last cycleTime new (yes really outpuOnly cycleTime):<br>
> > ><br>
> > > cycleTime = currentTime - fraction * cycleInterval<br>
> > ><br>
> > > From this time point you can calculate fraction as well:<br>
> > ><br>
> > > fraction = (currentTime - cycleTime) % 1.0<br>
> > ><br>
> > > Best regards,<br>
> > > Holger<br>
> > ><br>
> > > --<br>
> > > Holger Seelig<br>
> > > Leipzig, Germany<br>
> > ><br>
> > > <a href="mailto:holger.seelig@yahoo.de" target="_blank">holger.seelig@yahoo.de</a><br>
> > > <a href="https://create3000.github.io/x_ite/" rel="noreferrer" target="_blank">https://create3000.github.io/x_ite/</a><br>
> > ><br>
> > > Am 15.08.2023 um 23:37 schrieb Andreas Plesch :<br>
> > ><br>
> > > I forgot the cycleTime is actually of type SFTime, not SFFloat. So<br>
> > > ScalarInterpolator would not work, although x3dom does not enforce the<br>
> > > type.<br>
> > ><br>
> > > Back to the drawing board, using TimeTrigger now, or perhaps<br>
> > > elapsedTime from a TimeSensor to feed into cycleInterval.<br>
> > ><br>
> > > Thanks, Holger, for the test scene. Great to see. Will try to come up<br>
> > > with a simple scene without a Script node. How do you maintain the<br>
> > > fraction after changing cycleInterval ?<br>
> > ><br>
> > > Cheers,<br>
> > > -Andreas<br>
> > ><br>
> > > On Tue, Aug 15, 2023 at 3:41 PM Andreas Plesch wrote:<br>
> > ><br>
> > ><br>
> > > Developing a test scene uncovered that the requirement to continue<br>
> > > smoothly on the same fraction after a cycleInterval change appears to<br>
> > > require a change to the startTime field value. An unintended<br>
> > > consequence, perhaps ?<br>
> > ><br>
> > > Details:<br>
> > ><br>
> > > Here is a simple test scene for dynamic changes to cycleTime based on<br>
> > > a vrml2 source book scene for OrientationInterpolator:<br>
> > ><br>
> > > <a href="https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/bb3ee65b6748644f640cd5b73f30ed6e/raw/22a7b7f13bd597b55f136cee96a3b30747e14931/dynamicCycleInterval.x3d" rel="noreferrer" target="_blank">https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/bb3ee65b6748644f640cd5b73f30ed6e/raw/22a7b7f13bd597b55f136cee96a3b30747e14931/dynamicCycleInterval.x3d</a><br>
> > ><br>
> > > For X3D3.3 the scene is expected to show a rotating column at constant<br>
> > > speed. For X3D4.0 the scene is expected to show a rotating column<br>
> > > which switches speed every 5 seconds without stuttering or resets.<br>
> > ><br>
> > > Above includes a first, rough x3dom implementation (in the Scene,<br>
> > > javascript allows redefining almost anything) which at least shows the<br>
> > > changes in animation speed but is not successful at maintaining the<br>
> > > correct fraction to smoothly continue after a change.<br>
> > ><br>
> > > Let's see. The fraction is elapsedTime/cycleInterval. This means that<br>
> > > either elapsedTime will need to change with a change to cycleInterval<br>
> > > or that startTime will need to change. Since elapsedTime is derived<br>
> > > from the current time and startTime this only leaves startTime.<br>
> > ><br>
> > > new_fraction = old_fraction<br>
> > > new_fraction = elapsedTime/new_cycleInterval<br>
> > > elapsedTime - new_fraction * new_cycleInterval<br>
> > > time - startTime = new_fraction * new_cycleInterval<br>
> > > startTime = time - new_fraction * new_cycleInterval<br>
> > ><br>
> > > I think it is safe to change startTime but it will also change<br>
> > > elapsedTime for the remainder of the cycle. Not sure what to do about<br>
> > > that. Also there may be scenes which somehow rely on startTime not<br>
> > > being changed. But the algorithm for calculating fraction in the spec<br>
> > > really requires startTime to change when cycleInterval changes if the<br>
> > > goal is to maintain the fraction. Is this a matter for the spec. to<br>
> > > address to remain internally consistent ?<br>
> > ><br>
> > > <a href="https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/bb3ee65b6748644f640cd5b73f30ed6e/raw/181894e010f35d242f9f24cf39478e941bccf234/dynamicCycleInterval.x3d" rel="noreferrer" target="_blank">https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/bb3ee65b6748644f640cd5b73f30ed6e/raw/181894e010f35d242f9f24cf39478e941bccf234/dynamicCycleInterval.x3d</a><br>
> > ><br>
> > > does adjust the startTime in that way and it does work to continue<br>
> > > smoothly with the same fraction after the speed change. Not sure if<br>
> > > there are implications for pausing and resuming. Probably worth adding<br>
> > > to the test scene, as well as enabling and disabling.<br>
> > ><br>
> > > I guess the alternative is to keep an internal effective startTime for<br>
> > > fraction calculation which may be a bit messy.<br>
> > ><br>
> > > I also tried briefly what happens when cycleTime changes every frame,<br>
> > > eg. at the same pace as Timesensor fractions are generated which also<br>
> > > seemed to work after the startTime adjustment.<br>
> > ><br>
> > > -Andreas<br>
> > ><br>
> > ><br>
> > > On Tue, Aug 15, 2023 at 12:18 PM Andreas Plesch wrote:<br>
> > ><br>
> > ><br>
> > > It appears that a question on x3d-public back in 2016 was the trigger<br>
> > > for the change:<br>
> > ><br>
> > > <a href="https://web3d.org/pipermail/x3d-public_web3d.org/2016-November/thread.html#start" rel="noreferrer" target="_blank">https://web3d.org/pipermail/x3d-public_web3d.org/2016-November/thread.html#start</a><br>
> > ><br>
> > > It involves the x3d-svg-html "rosetta stone" page but that is not<br>
> > > really suitable as a focused test scene.<br>
> > ><br>
> > > Since this is a new feature there are probably no existing examples. I<br>
> > > may try to generate a pure X3D one showing a bouncing sphere:<br>
> > ><br>
> > > A sketch:<br>
> > ><br>
> > > "SENSOR" TouchSensor<br>
> > > "POSITION" Transform<br>
> > > "BALL" Shape<br>
> > > ..<br>
> > > "CLOCK" TimeSensor<br>
> > > "MOVER" CoordinateInterpolator<br>
> > > ROUTE CLOCK.fraction_changed to MOVER.set_fraction<br>
> > > ROUTE MOVER.value_changed to POSITION.position<br>
> > > #Begin of cycleInterval switching without a script<br>
> > > #Use ScalarInterpolator to emit SFFloat (there is no ScalarSequencer)<br>
> > > "INTERVAL5" ScalarInterpolator keyValue="5.0"<br>
> > > "INTERVAL1" ScalarInterpolator keyValue="1.0"<br>
> > > ROUTE INTERVAL5.value_changed to CLOCK.set_cycleInterval<br>
> > > ROUTE INTERVAL1.value_changed to CLOCK.set_cycleInterval<br>
> > > "Use Timers to trigger<br>
> > > "TIMER5" TimeSensor loop=true enabled=false<br>
> > > "TIMER1" TimeSensor loop=true enabled=false<br>
> > > ROUTE TIMER5.fraction_changed to INTERVAL5.set_fraction<br>
> > > ROUTE TIMER1.fraction_changed to INTERVAL1.set_fraction<br>
> > > #Use BooleanToggle and BooleanFilter to control activity<br>
> > > "NEGATER" BooleanFilter<br>
> > > "TOGGLER" BooleanToggle<br>
> > > ROUTE SENSOR.isActive to TOGGLER.set_boolean<br>
> > > ROUTE TOGGLER.toggle_changed to NEGATER.set_boolean<br>
> > > ROUTE TOGGLER.toggle_changed TIMER5.set_enabled #on/off TIMER5<br>
> > > ROUTE NEGATER.inputeNegate TIMER1.set_enabled #off/on TIMER1<br>
> > ><br>
> > > Is there an easier way to send a SFFloat to cycleInterval without a<br>
> > > script node ?<br>
> > ><br>
> > > Thinking about it may be better to avoid all the event utilities in an<br>
> > > example and just switch continuously between speeds:<br>
> > > ...<br>
> > > #Begin of cycleInterval switching without a script<br>
> > > "INTERVAL1OR5" ScalarInterpolator key='0 0.5 0.5 1' keyValue='1 1 5 5'<br>
> > > ROUTE INTERVAL1OR5.value_changed to CLOCK.set_cycleInterval<br>
> > > "SPEEDCLOCK" TimeSensor cycleInterval=5 # =3 for more challenging test<br>
> > > ROUTE SPEEDCLOCK.fraction_changed to INTERVAL1OR5.set_fraction<br>
> > ><br>
> > > This brings up if it will be necessary in the spec. to define<br>
> > > behaviour for the case when cycleInterval receives a new value which<br>
> > > is the same as the existing value ? Probably not since the proposed<br>
> > > language only covers actual changes implying that nothing should<br>
> > > happen if there is no actual change.<br>
> > ><br>
> > > -Andreas<br>
> > ><br>
> > > On Tue, Aug 15, 2023 at 10:46 AM Brutzman, Donald (Don) (CIV)<br>
> > > wrote:<br>
> > ><br>
> > ><br>
> > > Thanks for pointing out the error with CD1 urls in X3D Tooltips, which eluded prior search/replace.<br>
> > ><br>
> > ><br>
> > ><br>
> > > Now fixed. Correct current url prefix follows, sourceforge commit and <a href="http://web3d.org" rel="noreferrer" target="_blank">web3d.org</a> deploy will happen later today.<br>
> > ><br>
> > ><br>
> > ><br>
> > > <a href="https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.proof/" rel="noreferrer" target="_blank">https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.proof/</a><br>
> > ><br>
> > ><br>
> > ><br>
> > > The older behavior can be considered defunct and rectified by specification. Devising an example that explicitly shows such correct behavior is a good idea. All candidates welcome from any author.<br>
> > ><br>
> > ><br>
> > ><br>
> > > Thanks for pursuing this important interoperability consideration&hellip; we want duck models to consistently walk, talk, and look like a duck.<br>
> > ><br>
> > ><br>
> > ><br>
> > > Not sure what is going on with the following url, will investigate further. Probably an early (and now unintended) redirect.<br>
> > ><br>
> > ><br>
> > ><br>
> > > <a href="https://www.web3d.org/documents/specifications/19775-1/V4.0" rel="noreferrer" target="_blank">https://www.web3d.org/documents/specifications/19775-1/V4.0</a><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: Monday, August 14, 2023 6:56 PM<br>
> > > To: X3D Graphics public mailing list<br>
> > > Subject: [x3d-public] change to cycleTime perhaps no longer ignored , example ?<br>
> > ><br>
> > ><br>
> > ><br>
> > > <a href="https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/components/time.html#TimeSensor" rel="noreferrer" target="_blank">https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/components/time.html#TimeSensor</a><br>
> > ><br>
> > > (as linked from tooltips page)<br>
> > ><br>
> > ><br>
> > ><br>
> > > has the change that resetting the value of cycleTime of an active TimeSensor in v.4-CD1 does what is probably expected rather than being completely ignored which was the old behaviour.<br>
> > ><br>
> > ><br>
> > ><br>
> > > Is there an example scene somewhere which demonstrates that change, for testing purposes ?<br>
> > ><br>
> > ><br>
> > ><br>
> > > A bouncing sphere which changes its frequency over time, perhaps ?<br>
> > ><br>
> > ><br>
> > ><br>
> > > This proposal may have been taken out since<br>
> > ><br>
> > ><br>
> > ><br>
> > > <a href="https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/time.html#TimeSensor" rel="noreferrer" target="_blank">https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/time.html#TimeSensor</a><br>
> > ><br>
> > ><br>
> > ><br>
> > > does not have the change ? In that case, apologies for the confusion.<br>
> > ><br>
> > ><br>
> > ><br>
> > > -Andreas<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>
> > > --<br>
> > > Andreas Plesch<br>
> > > Waltham, MA 02453<br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > --<br>
> > > Andreas Plesch<br>
> > > Waltham, MA 02453<br>
> > ><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>
> > --<br>
> > Andreas Plesch<br>
> > Waltham, MA 02453<br>
><br>
><br>
><br>
> --<br>
> Andreas Plesch<br>
> Waltham, MA 02453<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>