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.

bringing object to origin

Not entirely sure how this deals with objects that move around A LOT, but for something mostly static that isn't near the origin it's good. Useful for simming stuff at zero then shoving back to where it came from.

In a point wrangle, move object to 0.0.0..

 // Get center of the oject bounding box (centroid)

vector min = {0, 0, 0};

vector max = {0, 0, 0};

getpointbbox(0, min, max);

vector centroid = (max + min)/2.0;

// Build and apply transformation matrix

vector translate = centroid + {0,-0.2,0};

vector rotate = {0,0,0};

vector scale = {1,1,1};

matrix xform = invert(maketransform(0, 0, translate, rotate, scale));

@P *= xform;

// Store transformation matrix in attribute

4@xform_matrix = xform;

Then in a later point wrangle, to revert back to original position

@P *= invert(4@xform_matrix);

queuing rops (for local renders)

 it seems like chaining rops breaks a bit - the frame ranges don't seem to get respected.

It's better to use a merge rop & specify strict frame range