kleer001

Off the top of my head I think you're going to have an easier time of it if you animate explicitly with an expression in the translate channel or even better in a wrangle. Unless there's a particular reason you're constrained to keyframes?

An important part of the journey to Mastery is going to be contributing to a larger project. So you want a large personal project or a team you can join. Also come back here to OdForce and the SideFX forums and try to help beginners. Throw out efficiency. Learning is hard and messy. I'm sure you've seen this before while learning other things. An hour spent pursuing learning is never wasted. We are only as smart as we are, we can only learn as fast as we can learn.

Keep all your stones as separate objects. Prefracture them with the RBD Material Fracture SOP, which gives you glue constraints. Realistic destruction also includes small particulates and dust. And that dust is disturbed by the wind of the debris around it.

You'll want to simplify your scene to get help. There's tons of broken links to caches I won't run. Reproduce your problem with a sphere/cube/torus super simple DOP setup, then upload that. Though, hopefully you'll figure out what the problem is by reducing the variables.

The point wrangle runs once for every point, in order. So, your foreach is redundant. The current point number is i@ptnum (an integer), the current points position is v@P (a vector), the current points floating point attribute named blahblah is f@blahblah. If you want to set the y value in the P you can float var = rand(i@ptnum); v@P = set(v@P.x, var, v@P.z);

Thanks! Sorry I didn't update the thread. I eventually figured it out, but can't share the code as it's for work. I'm using hou.Node.inputDependencies() Which gives me all the nodes that that node depends on, the full tree, not just the next step. That was a little unintuitive, graphically, but it makes more sense for sending to the farm and programming wise. I just run that once for the final node, then once again for every node but the last in the list (that's the node in question). From there building up the list of dependencies is pretty easy.

have you submitted this as an RFE ?

Use groups? Just set the group name in the Group field in that force. POP Group DOP, or straight up in a wrangle with i@group_groupname = 1;

Other than the ones on the SideFX website I have no idea. Or you could look at the built in rigs too. In the object context theres 3, Simple Biped, Simple Fe/male, Toon Character. They'll all be slightly different, as will the rig you create from the Rigging Series (6).

Animation of what and for what? All workflows can be pretty subjective, but your mileage may vary. If you're animating a character Houdini is geared towards doing all that in the Object context, not in the geometry context. Check out rigging tutorials. If you're creating procedurally animated geometry involving lots of SOPs that's better to do in a single (or several sensibly organized) Object.

Keep working at it. You'll get it. Problems like these are work for the student to prove they've learned the material. I spent a few minutes and think I got it, but I've got a dozen years plus of experience messing with these kind of things. Also, you'll want to never have an integer multiply a vector assignment, there on the right side of the equation. It will turn your vector into a float. Also you want to declare your attributes with f,v,i,s for float, vector, integer, and string respectively. @Cd=noise(posQ*chf("freq"))*2; //should be v@Cd = noise(posQ*chf("freq")); v@Cd *= 2; Do please spend at least another day or so at it before checking my hint below if you really really can't get it. Try quantizing a transformation of your v@P before trunc, then transform back.

Sweet! I was expecting a crumpled ball of paper, but a shirt is much more exciting. My intuition tells me to animate the rest length down slowly to as small a number as possible, with some non-animated noise or slow noise based on rest position. I might just give it a shot myself.

Hahahaha, exactly, no way! It certainly went through multiple artists, multiple 3d programs, and certainly even multiple studios. Also each sequence was probably done slightly differently depending on the needs of the shots. Worst of all some artist probably got a setup from another artist that left the show and had to swim through a morass of nearly unreadable code and or scene file with tetchy non-intuitive settings and no documentation.

Oooh, that sounds clever too! Please post a pic of your results if you can.

"." and ".." and "../." are unix based relative directory placeholders. The first is the current node/path/object/folder the second and third are the surrounding node/path/object/folder. if you want the input into the current node you need the hscript "opinputpath()" (run "exhelp opinputpath" in your textport for more info) The first input of the current node reads as such: opinputpath(".",0) the second input of the surrounding node (useful in DOPS context) is: opinputpath("..",1) HDocs on the topic: https://www.sidefx.com/docs/houdini/network/paths.html This is a pretty exhaustive explanation of paths and worth your time if it's unfamiliar: http://teaching.idallen.com/cst8207/12f/notes/160_pathnames.html