Forums Technical Discussion Problems with rotation matrix

Problems with rotation matrix

   2155   2   1
User Avatar
Redcroft
Member
13 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");
float angle = radians((dist/circum)*360);

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)

 Report
User Avatar
friedasparagus
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
 Report
User Avatar
Redcroft
Member
13 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.
 Report
  • Quick Links