bullet + flock = trembling HELP!!

[dyei nightmare]

whassap  dudes,  i come here with this new issue,   i have this bullet setup where i have some noise, and a flock system,  the thing is, i have here a system where im changing all the time the rotation with this vex expression: 

matrix3 mtx = dihedral({0,0,1}, normalize(@v));

setprimintrinsic(0, "transform", @ptnum, mtx);

 

this transforms each packed particle so it always keeps the z axis in front,   and this is cool, but the problem is that some particles are trembling while they are rotating,   is like a small flickering in some particles,  and i want it to interpolate rotations in a smoother way, 

 

maybe flock force is interfering with the rotations?   how can this be fixxed?  i want a smooth rotation interpolation. 

 

 the trembling is subtle, but it is there, when particles are rotating.  

 

HEEEEELLLLLLPPPPPP!!

 

 

flock_odforce.hip

Edited April 23, 2020 by dyei nightmare

[Farmfield]

Instead of simply applying the transform, apply it as a force, that will give you way smoother behavior and it's how I would solve it.

[toadstorm]

You want to be finding the matrix that will transform your local Z to point to the direction of movement, not world Z. Then multiply your local matrix against that new matrix to apply the rotation.

matrix3 current_xform = primintrinsic(0, "transform", @ptnum);
vector local_Z = current_xform * {0,0,1};
matrix3 delta = dihedral(local_Z, normalize(v@v));
matrix3 out = current_xform * delta; // might need to reverse these terms
setprimintrinsic(0, "transform", @ptnum, out);

This will work more reliably when you have more gradual velocity changes, since dihedral is inherently a bit of a guess. 

Just saw Farmfield's post... he's right that this can potentially be smoother when you're applying as a force. In that case, what you'd want to do is take that "delta" computed above and convert it to an axis/angle quaternion (a vector3), then add the result to v@torque:
 

matrix3 delta = dihedral(local_Z, normalize(v@v));
vector torque = qconvert(delta); // converts to an "axis/angle" quaternion
v@torque += (torque * f@mass); // remove mass term if you want mass to matter here

 

Edited April 23, 2020 by toadstorm
typo

[dyei nightmare]

33 minutes ago, Farmfield said:

Instead of simply applying the transform, apply it as a force, that will give you way smoother behavior and it's how I would solve it.

thanks you a lot for help, ill try it 

[dyei nightmare]

28 minutes ago, toadstorm said:

You want to be finding the matrix that will transform your local Z to point to the direction of movement, not world Z. Then multiply your local matrix against that new matrix to apply the rotation.

matrix3 current_xform = primintrinsic(0, "transform", @ptnum);
vector local_Z = current_xform * {0,0,1};
matrix3 delta = dihedral(local_Z, normalize(v@v));
matrix3 out = current_xform * delta; // might need to reverse these terms
setprimintrinsic(0, "transform", @ptnum, out);

This will work more reliably when you have more gradual velocity changes, since dihedral is inherently a bit of a guess. 

Just saw Farmfield's post... he's right that this can potentially be smoother when you're applying as a force. In that case, what you'd want to do is take that "delta" computed above and convert it to an axis/angle quaternion (a vector3), then add the result to v@torque:
 

matrix3 delta = dihedral(local_Z, normalize(v@v));
vector torque = qconvert(delta); // converts to an "axis/angle" quaternion
v@torque += (torque * f@mass); // remove mass term if you want mass to matter here

 

thanks for the help, ill try it and coment my result haha

[dyei nightmare]

54 minutes ago, toadstorm said:

 

matrix3 delta = dihedral(local_Z, normalize(v@v));
vector torque = qconvert(delta); // converts to an "axis/angle" quaternion
v@torque += (torque * f@mass); // remove mass term if you want mass to matter here

 

seems like qconvert only acepts matrix 4 to convert to a matrix 3,  do you think it is necesary?

https://www.sidefx.com/docs/houdini/vex/functions/qconvert.html

on the other hand,  looks like applying local z  to a force just spins each particle faster each frame   

Edited April 23, 2020 by dyei nightmare

[toadstorm]

My bad, try this:

vector4 delta = dihedral(local_Z, normalize(v@v));
vector torque = qconvert(delta);
v@torque += (torque * f@mass);

 

[dyei nightmare]

45 minutes ago, toadstorm said:

My bad, try this:

vector4 delta = dihedral(local_Z, normalize(v@v));
vector torque = qconvert(delta);
v@torque += (torque * f@mass);

 

thanks a lot,  it just keeps spining around,  think the local z axis request causes this,   letme see

[toadstorm]

Okay, try something like this file.

Here I'm setting v@targetw and f@spinresist, which is how POP Drag Spin works. It's setting a goal angular velocity rather than applying a direct force, which is a bit easier to control. However, this doesn't solve all of the jittering... part of the problem here is that your objects are colliding with each other while they try to maintain a specific orientation, and this can cause jittering. It's not quite as severe as in the file you posted, though.

 

flock_odforce_toadstorm.hiplc

[dyei nightmare]

5 minutes ago, toadstorm said:

Okay, try something like this file.

Here I'm setting v@targetw and f@spinresist, which is how POP Drag Spin works. It's setting a goal angular velocity rather than applying a direct force, which is a bit easier to control. However, this doesn't solve all of the jittering... part of the problem here is that your objects are colliding with each other while they try to maintain a specific orientation, and this can cause jittering. It's not quite as severe as in the file you posted, though.

 

flock_odforce_toadstorm.hiplc

thanks a lot!!  basically you fixed it! 

[dyei nightmare]

On 24/4/2020 at 3:49 AM, toadstorm said:

Okay, try something like this file.

Here I'm setting v@targetw and f@spinresist, which is how POP Drag Spin works. It's setting a goal angular velocity rather than applying a direct force, which is a bit easier to control. However, this doesn't solve all of the jittering... part of the problem here is that your objects are colliding with each other while they try to maintain a specific orientation, and this can cause jittering. It's not quite as severe as in the file you posted, though.

 

flock_odforce_toadstorm.hiplc

another little thing,  how could you keep the up vector point to global 0,1, 0 ?   much like  a fish crowd?

[toadstorm]

4 hours ago, dyei nightmare said:

another little thing,  how could you keep the up vector point to global 0,1, 0 ?   much like  a fish crowd?

In that case, instead of using dihedral to compute the matrix that would rotate your instances to face the velocity vector, you need to construct a new "goal" matrix comprised of your velocity vector and your global up, and then compute the difference between your current transform and your "goal" transform before applying it as torque like in the earlier file.

matrix3 goal_xform = maketransform(normalize(v@v), chv("up"));
matrix3 delta_xform = invert(current_xform) * goal_xform;
vector4 qdelta = quaternion(delta_xform);

You can then just set your "up" parameter to whatever you want.

[dyei nightmare]

3 hours ago, toadstorm said:

In that case, instead of using dihedral to compute the matrix that would rotate your instances to face the velocity vector, you need to construct a new "goal" matrix comprised of your velocity vector and your global up, and then compute the difference between your current transform and your "goal" transform before applying it as torque like in the earlier file.

matrix3 goal_xform = maketransform(normalize(v@v), chv("up"));
matrix3 delta_xform = invert(current_xform) * goal_xform;
vector4 qdelta = quaternion(delta_xform);

You can then just set your "up" parameter to whatever you want.

YEAH!  IT WORKED!    

thanks!!!   

YOU ARE THE MAN

Edited April 25, 2020 by dyei nightmare