3dome

right. no and no. For every parameter (no matter if one or more channels) there is a function defined somewhere in the code that takes the values you enter in the channel(s) as function arguments. Keyframes is a different story. you will memorize the syntax of the most common functions over time. If you're not sure, open help or when you type a function name and then the first open bracket houdini should pop up a help to this function where you can see how it's being used centroid("/path/to/sop", 0) instead of centroid("path/to/sop", D_X) and so on should all be in the docs. http://www.sidefx.com/docs/houdini/ref/expression_cookbook.html they are referred to as expressions, which makes sense as they are not variables that represent constant values!

1) return => function int sum(int x, int y) { return x+y; } takes 2 integers and returns their sum .. so yeah it gives you back something 2) yes 3) surface node is any SOP. those "cells/windows" are parameters. They can have 1 or more channels (= "cells" per row) 4) probably Dimension. Don't care, I'm lazy and use 0, 1, 2 5) centroid() is a function, $CEX, etc are global variables. Difference is centroid() can grab centroid of any SOP whereas $CEX always returns the centroid of the SOP you use it on 6) yes

There is no clear rule how to construct your scene. It's up to you how you want to structureit. In the end all you pass to the dopnetwork (and other nodes) is references (=> paths) to a node somewhere in the scene. You might want to structure your scene in kinda logical steps. For a destruction scene that might be one object level node called prep_geo where you load in your alembic of the house or whatever and prepare it for fracturing. Next might be a object level node fracture_geo where you do all the fracturing. Now here it really starts to come down to personal preference. You could create a new node constraints where you build the constraint network and then a dopnet at object level. Or you do all that inside the fracture_geo (which you then might wanna name differently). That's what I like to do because constraints depend on your fracturing so if that changes I don't want to dive in and out of nodes all the time to switch from fracture to constraints, etc. Also, although I tend to not use them, I like the inputs on the dopnet as quick way to feed it data. On object level they are useless. Everything that comes after the main sim (debris/dust/instancing hiRes pieces/etc) is also totally up to you how to structure it. Sometimes I can't be bothered and I do everything in 1 node TLDR - for your constraints to work it doesnt matter where you put stuff, you just need to check that all references/paths are correct. Also if working with object level nodes make sure transforms are zeroed out (or take extra care when object merging things)

alternative code if(idtopoint(1, i@id) != -1) removepoint(0, @ptnum);

download the scenefile from the description and see how he did it?

on your mantra rop, go to edit rendering parameters and search for exr. click on Set EXR Data Window and add the 4 highlighted paramters to the mantra rop. Uncheck the tickbox and it will not discard any empty pixels.

you might wanna try to fake the expansion with a squashed-sphere shaped divergence field in front of the muzzle. Did that recently and although not 100% happy it kinda worked for my purpose

that's of course true and an important thing to remember! Thanks for pointing it out. I was referring to accessing a certain component, maybe should have included the transformation behaviour for completeness

one thing you could try that just came to my mind is use a pointcloud lookup that sets the color of a particle to the color that is found the most within the points in the searchRad. Having a very hi-res sim though you might wanna be smart where to run the lookup in the first place. e.g you dont need it where the emitters pour down, so you could peak that collision sphere to group points to run the point cloud functions on. then maybe run a pc lookup with a "big" search radius to further filter out areas where there's only one color anyway. hope that helps

1) in houdini it doesnt matter if it's xyz, rgb, 012. Any vector component can be accessed with any of those conventions (attrib.x and attrib.r but attrib[0]) 2) use a attribcreate, set type to color and you get rgb in the spreadsheet instead of 012

it's not like the parameter is locked in the 0-10 range. if you got more than 10 objects just use the value ladder or type the number you want to examine or put in (adjusted) $F to get 1 iteration per frame and scrub timeline

you might aswell delete the points and then use a pointwrangle, first input the pieces, second input are the decimated points and use if(nametopoint(1, s@name)==-1) removepoint(0, @ptnum); to blast the pieces before feeding them into transform pieces. yeah, not sure if thats what you want to avoid when you say "deleting packed geo" but thought i'd post it anyway

I took the route of using 2 circles, might be a way too complicated solution but haven't had my morning coffee yet dm_normal_along_geo.hipnc

crappiest motion in history of odforce but this was a 5 min setup to show one way of aligning packed prims to velocity the harsh turns in orientation come from my extremly sophisticated force set-up^^ dm_alignPackedPrimAlongVelocity.hipnc

which is interesting since a solver is a dopnet + bottom right it is selected as the current one. maybe a bug? RFE it?