# sequence bug?

I have a sequence that moves an actor to a point, rotates left 90, moves,
rotates left 90, moves, rotates left 90, moves, rotates left 90.

It works perfectly. I can run it once or loop and works fine. If i stop it via ‘finish’ then restart the sequence then the first turn doesn’t execute properly.
The first move stops short, makes a backward 270 turn then continues along
nicely.

Any ideas why?

``````lapcount = -1
virpWalk.loop('walk')
Walk1 = virpWalk.posInterval(5.0,Point3(-1,-8.25,0),startPos=Point3(-1,8,0))
Walk2a = virpWalk.hprInterval(0.5,Vec3(90,0,0))
Walk2b = virpWalk.posInterval(1,Point3(1.25,-8,0))
Walk2c = virpWalk.hprInterval(0.5,Vec3(180,0,0))
#Walk3 = virpWalk.posInterval(5.0,Point3(1.25,8.25,0),startPos=Point3(1.25,-8,0))
Walk3 = virpWalk.posInterval(5.0,Point3(1.25,8.25,0))
Walk4 = virpWalk.hprInterval(0.5,Vec3(270,0,0))
Walk4a = virpWalk.posInterval(1.0,Point3(-1,8,0))
Walk4b = virpWalk.hprInterval(0.5,Vec3(360,0,0))

walkSeq = Sequence(u,Walk1,Walk2a,Walk2b,Walk2c,Walk3,Walk4,Walk4a,Walk4b)
#walkSeq.loop()
walkSeq.start()``````

You don’t specify a startPos/startHpr for most things, and Panda doesn’t automatically wrap angles around. E.g., if you rotate from 0 via a few operations to 360, and then rotate to 90, the rotation to 90 will do just that- rotate from 360 down to 90. If you want intervals to always apply transformations relative to a node’s current state, you’re going to need to crunch the relative numbers and recreate the interval each time.
(Factoid: when you use method return values, e.g. getPos(), as interval inputs, the methods are evaluated and the results built into the interval when the interval is first created, NOT when the interval is run)

Or, if you don’t want these issues, you can just switch to quaternions.
E.g. use this:

``   Walk4b = virpWalk.quatInterval(0.5,hpr=Vec3(360,0,0)) ``

``   Walk4b = virpWalk.hprInterval(0.5,Vec3(360,0,0)) ``

Hm. Never poked at quaternions in Panda. Will that solve the w/r/t transformation issue, or just the wraparound?

Thanks so much!

The quats did it!

Or seemed to. Back to coding and testing.

Now I need to look up info on quats.

It would fix the wraparound - not sure exactly about the w/r/t issue (you can specify to which the stuff is relative to by the “other” parameter, in both interval constructors.).
Plus, quaternions don’t suffer from gimbal lock.

Eh, one of my earliest mistakes in panda was trying to use, e.g.

``myModel.posInterval(1.0,myModel.getPos()+Vec3(0,1,0)).loop()``

to get constant forward motion, which doesn’t work (a) because the getPos evaluates at creation rather than every loop, and (b) what I’d really need would be motion of myModel relative to itself, which apart from meaning I’d want to forgo the getPos entirely, might give Panda a headache. I’m not sure I ever tried it, I think I just fell back on managing the state myself.

Wouldn’t this work?

``myModel.posInterval(1.0,Vec3(0,1,0),other=myModel).loop()``

Quite possibly, provided I’d known about the ‘other’ parameter at the time, and that Panda logs the start and end point in some absolute space before applying the translation, rather than say,
@t=0: pos=0
@t=.1: pos=.1
@t=.2: pos=.2(model)=.3(absolute from start)
@t=.3: pos=.3(model)=.6(absolute from start)
etc.

You can change that by setting the bakeInStart parameter to False.