Hi Jeff,
that code works ok as it is. Also, when I adopt it to my script, it does the trick and moves the node by 1 meter. So thank you for the workaround.
But
- .move is not as convenient because it is working with speed instead of distance. So I have to calculate the speed myself instead of using the conveniently designed interface of .moveTo.
- .move does not allow for gradually picking up the speed
- would there be rounding issues with .move when moving back and forth a part several timesusing different timings (when fractions occur)?
Therefore I'd like to repeat: what am I missing to understand how .moveTo works?
When I use your script as a basis and try out .moveTo again
Code:
import viz
import vizact
viz.go()
viz.add('dojo.osgb')
ball = viz.addChild('beachball.osgb',pos=[0,1,4])
_ceilDist = 1
_ceilMode = viz.REL_LOCAL
_actYplus = vizact.moveTo( [0,_ceilDist,0], time=1, mode=_ceilMode, interpolate=vizact.easeInOut)
_actYmin = vizact.moveTo( [0,-_ceilDist,0], time=1, mode=_ceilMode, interpolate=vizact.easeInOut)
vizact.onkeydown('3', ball.addAction, _actYplus)
vizact.onkeydown('4', ball.addAction, _actYmin)
def debugPos():
print 'posi:', ball.getPosition()
vizact.ontimer(3.3, debugPos)
then the position of the ball after moving seems to depend on the interpolation used. it is (truncated to 2 decimals)
- 11.54 .easeInStrong
- 14.44 .easeInCircular
- 21.53 .easeIn
- 31.52 .easeInOut .easeInOutStrong .easeInOutCircular .cubic .linear
- 41.51 .easeOut
- 48.59 .easeOutCircular
- 51.50 .easeOutStrong
Giving time=2 does not lower the speed but extends the distance, e.g. 61.55 for .easeInOut
Using parameter speed=1 instead of time=1 in the code above yields same result, BUT using speed=.1 results in y=301.75 while speed=10 yields y=4.50
even more confused the more I try,
Walter