[x3d-public] Validation suggestion on animation events

[Roy Walmsley]

Tony,

Just for your info XMLSpy is a commercial product sold by Altova. It's a great product, but it's not free ...

Roy

-----Original Message-----
From: Anthony Judge [mailto:anthony.judge at gmail.com] 
Sent: 31 August 2015 15:20
To: Roy Walmsley
Cc: x3d-public at web3d.org
Subject: Re: [x3d-public] Validation suggestion on animation events

Roy

Again many thanks. Clearly I should be using your XMLSpy

On the X3D00.x3d file, that is indeed what I expected from the larger set of translations for the drilled truncated cube. It was sent only to indicate some of the moves, but not all. Basically only those through 0, 0, 0 which do not pose the problem of those of the inner cube

With respect to X3D01_ok.x3d. You are correct with respect to my failure to switch CLOCKy back to CLOCK, to give a version with a sense of the movements which were OK and those which were not. I made the corrections you indicated and now have a variant in which (as before) some lines are still absent from the paired movement across each surface of the cube.

With respect to the X3D01_not_ok.x3d I corrected the errors you helpfully indicated to the extent that I understand the manner in which the timing control is passed from one CLOCK to another.

This moves all the the lines in one direction (backwards and forwards) correctly -- presumably as a result of the first timesensor. It does not move the lines in the other directions -- despite changes to set_fraction, and other experiments. Clearly it is here that I lack insight

Tony

On 31/08/2015, Roy Walmsley <roy.walmsley at ntlworld.com> wrote:
> Tony,
>
> I have loaded and run your X3D00.x3d file in my development X3D viewer 
> (which is based on Coin3D with X3D extensions).
> I have attached a short video illustrating the output.  Is that what 
> you expected?
>
> I then looked at your X3D01_ok.x3d file. First, my XMLSpy noted an 
> error repeated three times. In each case it  is a route fromNode 
> 'CLOCKy'. There is no node 'CLOCKy', I assume it should simply be 
> 'CLOCK'. This occurs at lines 1031, 1043 and 1047. Making those 
> changes I ran this file in my viewer again. I get a warning that about 
> trying to connect a route multiple times (from CYL16.value_changed to 
> CY2630.set_translation). Second short video attached. Again, is that as expected?
>
> Finally I looked at your X3D_not_ok.x3d file. No errors reported by XMLSpy.
> On loading into my viewer I got the message 'Unable to create ROUTE 
> from CLOCKx.fraction_changed to CLOCKy.set_fraction. Delaying'. Then 
> another load message 'Unable to create ROUTE from CLOCKy.time to CLOCKz.startTime.
> Delaying'. Then load message 'Tried to connect a ROUTE multiple times 
> (from CYL16.value_changed to CY2630.set_translation)'. Then a final 
> message 'Unable to create route: CLOCKx.fraction_changed TO CLOCKy.set_fraction.'.
>
>
> So I looked back at your file and saw you create these ROUTEs before 
> you have defined both nodes involved. So I modified the file so that 
> the three TimeSensor nodes are defined first, followed by the three ROUTE statements.
> That eliminated the first two messages and inverted the order of the 
> remaining two. Then I looked at the specification V3.2 TimeSensor 
> node. I saw immediately that there is no 'set_fraction' input field. 
> So that explains why the ROUTE cannot be created. Hence there is only 
> limited animation.
> http://www.web3d.org/documents/specifications/19775-1/V3.2/Part01/comp
> onents/time.html#TimeSensor
>
> Roy
>
>
> -----Original Message-----
> From: Anthony Judge [mailto:anthony.judge at gmail.com]
> Sent: 31 August 2015 13:21
> To: x3d-public at web3d.org
> Cc: Leonard Daly; Roy Walmsley
> Subject: Re: [x3d-public] Validation suggestion on animation events
>
> Many thanks Leonard for your specific suggestions which I have 
> rewritten into a revision of the file already sent X3D_not_ok.x3d. I 
> have not sent you the revised file because errors may well be obvious
> from the following excerpt. I have added a   Mover in the Z direction
>
> <TimeSensor DEF='Timer' cycleInterval='5' loop='true' /> 
> <PositionInterpolator DEF='MoverX' key='0.00 0.25 0.50 0.75 1.00'
> keyValue='2 0 0, -2 0 0, -2 0 0, 2 0 0, 2 0 0' /> 
> <PositionInterpolator DEF='MoverY' key='0.00 0.25 0.50 0.75 1.00'
> keyValue='0 -2 0, 0 -2 0, 0 2 0,  0 2 0, 0 -2 0' /> 
> <PositionInterpolator DEF='MoverZ' key='0.00 0.25 0.50 0.75 1.00'
> keyValue='0 0 -2, 0 0 -2, 0 0 2,  0 0 2, 0 0 -2' /> <ROUTE fromNode='Timer'
> fromField='fraction_changed' toNode='MoverX'
> toField='set_fraction' />
> <ROUTE fromNode='Timer' fromField='fraction_changed' toNode='MoverY'
> toField='set_fraction' />
> <ROUTE fromNode='Timer' fromField='fraction_changed' toNode='MoverZ'
> toField='set_fraction' />
>
> The above precedes my mods to the specific transforms, of which the 
> following are the first few.
>
> <!-- 2832 > 2731 #1 -->
> <PositionInterpolator DEF='CYL2' key='0 1' keyValue='0.012911673
> -0.0029703318 0.01656701 -0.016828164 -0.0026736213 0.012635848 '/> 
> <ROUTE fromNode='MoverX' fromField='fraction_changed' toNode='CYL2'
> toField='set_fraction'/>
> <ROUTE fromNode='CYL2' fromField='value_changed' toNode='CY2832'
> toField='set_translation'/>
> <!-- 2832 > 2529 #2 -->
> <PositionInterpolator DEF='CYL4' key='0 1' keyValue='0.012911673
> -0.0029703318 0.01656701 0.016828164 0.0026736213 -0.012635848 '/> 
> <ROUTE fromNode='MoverZ' fromField='fraction_changed' toNode='CYL4'
> toField='set_fraction'/>
> <ROUTE fromNode='CYL4' fromField='value_changed' toNode='CY2832'
> toField='set_translation'/>
> <!-- 2731 > 2832 #1 -->
> <PositionInterpolator DEF='CYL6' key='0 1' keyValue='-0.016828164
> -0.0026736213 0.012635848 0.012911673 -0.0029703318 0.01656701 '/> 
> <ROUTE fromNode='MoverX' fromField='fraction_changed' toNode='CYL6'
> The outputs of the PositionInterpolators would need to be ROUTEd to 
> the appropriate Transform node.toField='set_fraction'/> <ROUTE fromNode='CYL6'
> fromField='value_changed' toNode='CY2731'
> toField='set_translation'/>
> <!-- 2731 > 2630 #2 -->
> <PositionInterpolator DEF='CYL8' key='0 1' keyValue='-0.016828164
> -0.0026736213 0.012635848 -0.012911673 0.0029703318 -0.01656701 '/> 
> <ROUTE fromNode='MoverZ' fromField='fraction_changed' toNode='CYL8'
> toField='set_fraction'/>
> <ROUTE fromNode='CYL8' fromField='value_changed' toNode='CY2731'
> toField='set_translation'/>
>
>
> The result is all blocked. This is probably due to my failure to 
> interpret correctly your sentence:
>
> "The outputs of the PositionInterpolators would need to be ROUTEd to 
> the appropriate Transform node"
>
> The good thing.about the approach you are suggesting is that it 
> implies simultaneous movement in the X, ,Y, and Z directions. Rather 
> than the sequential fudge I was exploring -- which is an alternative 
> dynamic I may implement as an option.
>
> Less clear from my understanding of your comment is whether 
> simultaneous orthogonal movement is anyway possible, despite my 
> experiments. As I said, I had also considered making "shadow" copies 
> of each cylinder with the same coords  but different DEFs and treating 
> them as quite independent for the movements in the 3 directions.
>
> Thanks anyway
>
> Tony
> --
> Anthony Judge
> <anthony.judge at gmail.com>
> www.laetusinpraesens.org
>


--
Anthony Judge
<anthony.judge at gmail.com>
www.laetusinpraesens.org