3dome

if they follow the same naming convention you can do something like group_`strreplace(s@shop_materialpath, "/mat/_Kitbash3d_StreetSide", "")` for further string manipulation look up the various functions (possibly even doing it in a wrangle, export as attrib and create group from that attrib)

I'm at work right now so can't look at your file, so I don't know how you set it up. But the way I'd do it is create a menu, as tokens I'd give it one, two, three with respective labels option1, option2, option3 and in the result parm use `chs("menu")` (or whatever the name of the menu parm) hope this helps

create a meta import node on the loop and use this as the group name group_`detail("../foreach_begin1_metadata1/", "iteration", 0)` (adjust path to metadata if you have to)

The performance does change. Linux has a better memory management and sim times are lower too, as a bunch of benchmarks have shown. The viewport performance from my experience doesn't change much. I've handled crazy scenes at work under CentOS and apart from the general Houdini viewport hiccups it works just fine.

if you go @pachan96's way, make sure to also set Scale Source Volume to -1 since VDB is flipped compared to regular Houdini volumes. another way is to use the static object DOP in volume proxy mode where you point to your vdb (though I'm not sure if you have to tick "invert sign". try it out or have a quick google search for it)

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