solver storing the frame when attribute changes

 

Say you're transferring an attribute to an object. Eg. a sphere going along a curve and making it red.

Now you might want to store the frame that the curve receives the red attribute and use that information later - eg. do an attribute fade, so the attrib only starts fading when we reach the stored frame.

What you want to do is plug things into a solver, as above (just one input) and then....

in a wrangle-

vector newCd=point(1,"Cd",@ptnum);

if(@Cd!=newCd){

    if(@change_frame==0){

    @change_frame=@Frame;

    //i@changed += 1; //debugging

    }

    

}

What does this mean? Well, the Prev Frame is typically on the first input of point wrangles when in a solver... you are generally "adding" onto whatever was in the previous frame. (I always think about it the other way, but there you go). So we check to see what the "new" (or current frame) Cd value is.. And compare it to the existing (previous frame) value. If it is not the same, that means a change has occurred.

Now we check to see if the @change_frame value has been altered from zero or not. If it hasn't and is still zero, then we now make it equal to the current frame value.

solver transfer attribute, eg. colour accumulation

i always have to look this up on cgwiki...

the left stream is some sweat drops falling down a surface.. the right stream is the surface. 

It goes into a solver

The slight 0.0075 blend in the blendshape causes a slight fade of the attribute being transferred. Leaving it at zero will result in an absolute solver-accumulation of the value.

mark fancher mograph video notes

 some mark fancher youtube vex tidbits-

//in a rig attrib wrangle, to rotate joints - take into account parenting!-

vector axis={1,0,0};

prerotate(4@localtransform, chf("angle"),axis);

-----------------------------------------------------------------------------------------

//in a rig attrib wrangle,to scale joints - take into account parenting-

prescale(4@localtransform, chf("scale"));

--------------------------------------------------------------------------------------------------------

//point wrangle, after a distance along geometry - nice rampable normalised mask

float map=f@map;

float p=chf("position");

float t=chf("transition");

t=max(t,0.0001); //clamps down value

p=fit01(p,-t,1); //makes mask zero when t at low values and p at zero

float mask=fit(map,p,p+t,1,0);

mask=chramp("ramp",mask);

f@mask=mask;

--------------------------------------------------------------------------------------------

how to store activation frame based on a threshold of something

in a point wrangle

if(@value>chf("threshold")){

i@group_active=1;

}

inside a solver...connect prev_frame to input 2 and input 1 to 1 of a point wrangle..

int prev_active=inpointgroup(1,"active",@ptnum); //check if previous frame was active

//if group active and NOT previously active then give active_frame value of current frame

if(i@group_active==1 && prev_active==0){

f@active_frame=@Frame;

}

float activationFramePrevious=point(1,"active_frame",@ptnum);

f@active_frame=max(activationFramePrevious, @active_frame);

simple spring solver - prev frame into input 1, input 1 into 2nd input of wrangle

based on F=-kx -bv

where F is force, k is the spring coefficient (stiffness), x is the distance, b is the damping and v is velocity. We also use F=ma to calculate acceleration (and use that for velocity, which ultimately gets added to Position)

float m=chf("mass");

float k=chf("stiffness");//stiffness coefficient

float b=chf("damping");//damping coefficient

vector p2=point(1,"P",@ptnum);//position of point on "current" frame

vector x=@P-p2; //distance between previous and current

vector f=-k*x -b*v@_v;//calculate force using damped harmonic motion equation

vector a =f/m; //get acceleration from f=ma to then find...

v@_v+=a;//velocity

v@P+=v@_v;//new position is calculated by adding velocity vector to current pos

solver sop and moving geometry

So, the Solver SOP doesn't behave as "I" expected with animated (ie. moving) points/geo.

You need to manually update the position if you want your geo to still move!
SOOOOOOOOOO. Inside the solver, copy the P (for position) attribute from Input 1 to Prev Frame...

Weird stuff. But hey.