anim

you can't use VEX as parameter expression language, all tools with parms that accept VEX are referenced by Snippet VOP as a part of VOPnet where it gets evaluated, in other words it's treated as pure text until compiled by VOPnet, so it's very specific case, and can't be generalized for all parameters for python the usage would be hou.node("../box1").geometry().boundingBox().sizevec()[1] OR hou.pwd().inputs()[0].geometry().boundingBox().sizevec()[1] also for the confusing meaning of "replaced by" you can read this https://www.sidefx.com/forum/topic/57809/#post-258876

no loops necessary and you should try to avoid them if you can also first point of the primitive doesn't guarantee that it's at the start or at the end or even that the primitive has any start or end if it's closed, so you are better off using points belonging to first or last vertex and either checking if the prim is closed or using the neighbourcount() test so to detect all you can combine first test with test whether point belongs to the first or the last vertex of the primitive int pts[] = primpoints(0, @primnum); int isend = neighbourcount(0, @ptnum) == 1; int isfirst = @ptnum == pts[0]; int islast = @ptnum == pts[-1]; i@group_ends = isend; i@group_start = isend && isfirst; i@group_end = isend && islast; OR mentioned open/closed poly test int pts[] = primpoints(0, @primnum); int isopen = !primintrinsic(0, "closed", @primnum); int isfirst = @ptnum == pts[0]; int islast = @ptnum == pts[-1]; i@group_ends = isopen && (isfirst || islast); i@group_start = isopen && isfirst; i@group_end = isopen && islast;

couple of things, but to not go into too much detail on how to make it work with the whole streams paradigm POPs are built around, let's just assume you have the need to control all particles, therefore we can leave your condition @ptnum==@numpt-1 for now 1. the main thing you need to do is to inherit the streams the original last particle is in or at least the stream the POP Grain is acting on, the easiest way to do that is to clone the chosen point instead of just creating the new one at some P, so this : int newpoint = addpoint(0,@ptnum); setpointattrib(0, "P", newpoint, @P+newdir); you can also rearrange where the popwrangle is plugged in to make it look like it follows stream workflow, but not necessary as it doesn't now 2. optionally you can create correct id's, while this is not necessary for grains to work, it's always nice since in your case your wrangle always creates just one point at a time, you can do this: int nextid = detail(0, "nextid"); setpointattrib(0, "id", newpoint, nextid); setdetailattrib(0, "nextid", 1, "add"); see the file with all the changes createGeoinPop_v01_fix.hiplc

all arguments of a context level (shader) function have to be initialized with default value and yes, whatever program calls the CVEX shader function may pass some arguments

in CVEX you define it as an argument and if it's fed to the shader it will be automatically populated, so in most geometry CVEX contexts it will contain actual ptnum in others like lens CVEX shader it will stay the default value (in this case 0) etc. cvex randomshader(int ptnum = 0; export vector Cd = { 0, 0, 0 }) { Cd = random(ptnum); }

this can help with the first steps https://www.sidefx.com/tutorials/houdini-165-masterclass-opencl/

I like the idea of getting checksum from the input graph instead of from the contained geometry itself but if the comparison script needs to cook the live input geo to retrieve checksum detail attrib, then what's the point of having the geo cached? Especially for heavy sequences. would maybe be worth of generating input checksum on the filecache node itself for comparison so that the input graph is not cooked EDIT: just read your final post, where you mentioned exactly that, ignore me then

you are overwriting v@newdir every iteration from v@dir attribute so it will always wipe out your found intersection value

as I mentioned, you better report a bug or a rfe for handling such cases, maybe specific projection or custom polygon N would be a good hint for the algorithm to handle this, but clearly this is not the case currently

to me it seems to scale linearly with the number of curves the error/warning is not because of your loop but because of arbitrary geometry for straight skeleton computation, which is straight line so even single line takes forever until it falls back from its internal infinite loop if you for example split each line and jitter points a bit in XZ just so that it actually knows the curve's plane, it will get fast again, see example so you either find an alternative to polyexpand for perfectly straight lines or submit a bug to maybe have an option to have such edge case handled, whether it'd need some helper primitive normal attribute or something odforce.polyexpand_mod.hipnc

since parameter pane is of type PathBasedPaneTab you can use its currentNode() function http://www.sidefx.com/docs/houdini/hom/hou/PathBasedPaneTab.html

it's not a group scope, its literally for treating groups like an attribute so if you say... "prim", "attribname", value ... it will find @primnum whose attribname value is the same as your value and ... "primgroup", "groupname", value ... will find @primnum whose grupname membership is the same as your value (0 or 1) so in your case I'd assume you'd do: findattribval(0, "primgroup", "prims", 1) ; however it doesn't seem to do what it says, I'd assume it'll give you 2 as that is the first @primnum with the prims group of value 1, but I was always getting -1, it feels like a bug you can always use expandprimgroup(0, "prims")[0]; even though it may be slower However I assume you were hoping for group scope to limit which prims the findattribval() is searching, so I'm afraid that's not implemented

in your screenshot you are dealing with RBD Packed Object so in terms of Position you most probably want to fetch just Geometry (DOP Import, Dop Import Fields, DOP I/O or Object Merge SOPs can do that) since packed RBDs are represented as a single DOP object with Greometry containing packed primitives therefore RBD Packed Object doesn't have Position data directly as each point's P in Geometry represents the position and primitives intrinsic transform represents rotation and scale

like this: examples of 1. sphere_object1 DOP object, Position data, Options record, displayed in Geometry Spreadsheet where you can see all the data fields in the record as well as imported to SOPs using DOP Import Records and shown in SOP level Geometry Spreadsheet as points with attributes that represent the fields 2. same principle, just showing sphere_object1 DOP object, Geometry/BulletData subdata, Options record