### Problems with rotation matrix

1386   2   1
Member
12 posts
Joined: Aug. 2014
Offline
Hi,

I'm having an issue making an automatic rolling ball, not sure if my maths is wrong or my use of the rotate vex command. Anyone mind giving a hand please?

Thanks

```vector cur_pos = detail(0, "cen");
vector prev_pos = detail(1, "cen");

float dist = distance(cur_pos, prev_pos);
float circum = detail(0, "circum");

vector up = {0,1,0};
vector dir = normalize(prev_pos-cur_pos);
vector axis = normalize(cross(dir, up));

matrix3 m = ident();
rotate(m, angle, axis);

@P -= cur_pos;
@P *= m;
@P += cur_pos;
```

Attachments:
ball_rot.hiplc (90.6 KB)

Member
402 posts
Joined: June 2014
Offline
Hi Redcroft,

Nothing wrong with the code there, the problem was to do with the timeshift and getting the prev_pos value. With the timeshift set to \$F-1, the rot wrangle will only compute the dist travelled over the last timestep, which is why you'll notice the ball straighten up when it changes direction - the dist is very small. You can get you're existing setup to work by changing the timeshift to use the first frame (as I've done in the file), but this of course only gives you the right motion when moving in a straight line through the origin, as the dir will always be computed from there. I stuck a curve based animation in there to see that clearly.

All you need to do is take your existing setup and stick it in a Solver SOP, this way we can continuously update the dir and the distance based upon the previous frame (which I'm guessing was you're instinct ).

I swapped around the prev_pos and cur_pos in the ‘rot’ node within the solver, just to make accumulating the rotation a bit simpler.

Hope that's useful
Cheers!

PS Forgot to mention one of the perks of using the solver sop is that we can increase substeps to improve the accuracy of the rotation, super handy for fast motion!
Edited by friedasparagus - June 1, 2018 07:39:56

Attachments:
ball_rot.hiplc (120.4 KB)

Henry Dean
Member
12 posts
Joined: Aug. 2014
Offline
friedasparagus
Hi Redcroft,

Nothing wrong with the code there, the problem was to do with the timeshift and getting the prev_pos value. With the timeshift set to \$F-1, the rot wrangle will only compute the dist travelled over the last timestep, which is why you'll notice the ball straighten up when it changes direction - the dist is very small. You can get you're existing setup to work by changing the timeshift to use the first frame (as I've done in the file), but this of course only gives you the right motion when moving in a straight line through the origin, as the dir will always be computed from there. I stuck a curve based animation in there to see that clearly.

All you need to do is take your existing setup and stick it in a Solver SOP, this way we can continuously update the dir and the distance based upon the previous frame (which I'm guessing was you're instinct ).

I swapped around the prev_pos and cur_pos in the ‘rot’ node within the solver, just to make accumulating the rotation a bit simpler.

Hope that's useful
Cheers!

PS Forgot to mention one of the perks of using the solver sop is that we can increase substeps to improve the accuracy of the rotation, super handy for fast motion!

Thank you so much, that's exactly what i was after! It also makes much more sense with swapping the cur and prev position over.