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
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
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
I think Toadstorm posted this somewhere on odforce... but it's a useful little vex snippet
vector fwd = v@N;
vector up = {0,1,0};an equivalent to maya's "unlock normals" in houdini.. usually needed after a polyextrude -
reverse sop node, followed by a normal node
general character rig workflow -
exoside quad remesh
labs 3d straight skeleton, fuse, delete half (for mirroring), resample.
use cgwiki matt estela's edge transport distance attrib propogate trick to reorder vert numbers
(edge transport "(distance)", promote to primitive (don't delete origintal), sort by distance, polypath)
rig doctor
mirror rig
joint capture biharmonic for mesh capture. joint capture paint to tweak any specific weights
stash captured geo and skele, externally(!)
plug all into joint deform.
rig wrangle to use curl noise vector attrib to mess with joint rotation/scale/pos.
he sets poses with multiple rig pose nodes. Then switch-nodes between them using a $F and modulo expression. This is nice for stepped anim style, but if you want to inbetween them,
Use a "smooth motion" node. It's used for fixing jittery mocap - but it also provides a nice tween between the different rig poses.
Another novel blending approach is to put the step anim through a solver. Inside the solver use a skeleton blend with the previous frame, using a blend value of less-than-one, for an interesting ramped blend between poses.
This can also be used with stepped blend shapes(eg for a stepped mountain sop anim). Smooth motion seems to have some nice secondary motion built in.
There is a secondary motion sop node which lets you specify a driver joint & the group to affect. Typically these will be joints down the hierarchy, eg in a tail/whip/arm. Also has some effect features - lag/overshoot, jiggle and gravity.
https://heightmap.skydark.pl/
only has 1K resolution
.usd files are written as binary by default. to write a .usd file as ascii, add
":SDF_FORMAT_ARGS:format=usda" (without quotes) directly after the file name.
eg.
$HIP/usd/$HIPNAME/scenes/extensions/extension_scene_ascii.usd:SDF_FORMAT_ARGS:format=usda