acey195

Just got another badge after "reacting" to our wonderful memes Does anyone already have a speedrun on getting all the new badges xD?

OK yeah, maybe I should have been more clear there are nodes that can done faster in VEX than native, the partition and measure SOPs come to mind. Its just that Remesh is a much complex beast. If you are a researcher in the field or just want to learn how to do it, then by all means go ahead! But I think that those things: remesh, poly reduce and also uv layout and uv relax(hopefully at some point xD) are among the most difficult graphical problems you run into on a regular basis

the remesh node is done in C++, doing it yourself in VEX is unlikely to make it faster That said, there are some things that you can optimize on top of the node. One very easy optimization is to split your mesh by connectivity (create a "class" attribute with the connectivity SOP) then loop over this attribute with a foreach block, and in turn, use compile block around that. My suspicion is that because in each iteration of the loop, the remesh node does not have to consider irrelevant (far away) data, doing a bunch of smaller pieces separately (in a compiled fashion) is faster than processing it as one large chunk. This can speed it up a loot, depending on the target mesh density etc.

Or if don't have too many points for which you need to process this, you could also make a preparation wrangle, to build primitive groups, for each point, of what they are allowed to connect to: (I wrote this blind, but it should work.... more or less.. xD) //running over the collision primitives: //second input being the points you want to snap later int nOpts = npoints(1), i; float maxAngle = radians(chf("maxConeAngle")); vector oP, oN; string grp; for(i = 0 ; i < nOpts; i++) { oP = point(1, "P", i); oN = point(1, "N", i); oP = normalize(oP - v@P); // get direction vector from the current primitive to each point grp = sprintf("pt%d_primSelection", i); setprimgroup(0, grp, @primnum, acos(dot(oP, oN)) < maxAngle); } then in your actual wrangle you can just use something like: //running over your points //second input your collision geometry with the created groups string grp = sprintf("pt%d_primSelection", @ptnum); v@P = minpos(1, grp, v@P); If your collision geometry is extremely high-res or you are testing a very large amount of points, this solution might be less scalable than ray casting. If your collision geometry is splines, instead of polygons, you probably have to split them into individual segments, for example with a carve node. if you want your check to be more strict, you could also choose to make a point groups instead of prim groups, and then promote them to primitive groups with the "only include when whole thing is selected something something"

Yup array slicing is awesome ^^ I'm wondering though, for when I actually cast a string to a character array (or string array, as chars don't exist in hou) it seems to error unfortunately. Of course I could just loop through the entire string to build the array.. but is there also an elegant way to do it? example of working, but "unelegant" code : string test = "Lorem ipsum"; int n = len(test); string charArray[]; resize(charArray, n); for(int i = 0; i < n; i++) charArray[i] = test[i]; printf("%s\n", charArray);

By default you will fetch the tokens if you use chs() on an ordered menu parameter. if you use chi() it will give you the index in the list. Do you need to have 2 strings (the token and the label separately) ? If not you can just copy the label value to the token value. For fetching the actual label string.. I'm actually not sure for VEX from the top of my head.

Yup that is correct if you are creating these attribs by binding in wrangles, you can specify the attribute type with a prefix (or set the type in the bind export node in vops) in wrangles for example, you can use i@blahblah to create an integer attrib, or v@blahblah to make it a vector(float3) if you do not define the type, by default it will become a singular float attribute type.

clicking those buttons should trigger this callback script. But I'm not aware of a built in way to trigger 2 different callback scripts for plus and minus. To do that, I think you have to keep track of the previous number somewhere (which is also not super trivial I guess), and check if the new number is higher or lower than the previous one.

Yup never rely on floats with == checks a further alternative would be something like: if(abs(dot(ynorm, {0,1,0})) > 0.001) or if you want to set a specific angle: if(acos(abs(dot(ynorm, {0,1,0}))) > radians(<angle in degrees>))

I also would like to know this, don't think its currently possible (haven't checked in h19 yet) but maybe a RFE is the way to go

ok you are right, its a bit more finicky than I realized

My suggestion for older versions would be to use NURBS curves if you start from a right angled shape, with control points (vertices) at the marked blue locations and convert it to a NURBS order 3, I believe you get what you would want: edit: if you are using an open curve instead of a closed one, you must add at least one more vertex in the middle of any straight segment, and make sure the curve starts there

more toggle's for group nodes (like the group combine SOP) to interpret missing groups as an empty group (so you can choose for it to return a warning, instead of an error. While I know there are workarounds, its quite annoying if your delete node cleans a group on empty geometry and then the group combine returns an error :P) for the "Convert line" SOP to be able to maintain vertex ordering (instead of basing the new vertex ordering, on the input point numbering) (sorting by vertex number does not work in cases where you have closed primitives, resulting in the "last" edge of an original primitive to have a reversed direction) Edit: Update the find shortest path, so it can output the start point attribute even when you are not outputting paths (this way you could use this reference attribute to transfer attributes to the flood-filled network from the closest start point: (right now its possible to work around this by setting the output paths to "from EAch start to any end" and then write some vex to find the lowest value in the cost array, that is not -1, and use that to link the points, but its a bit clunky ) Some heavy nodes (in particular the remesh node) could make more use of multithreading, right now, cooking times can be massively decreased by splitting the mesh (using some kind of internal connectivity logic) and using a for loop, even without compiling sometimes as is the case here: and because of how the remesh works it keep those isolated pieces isolated anyways, so "free" perf yay!

Generally speaking completely flat N-gons are fine (as long as you keep them in houdini for logic manipulation :P) if they get very concave they might get rendering issues though as it will do internal triangulation for the rendering, that in some rare cases will create self-intersecting geometry (only on the render side) So for render performance keeping your geometry as n-gons does not really help.. HOwever, in terms of RAM in your Houdini session it can save a lot of data.

You probably want to store the time in a previous node, that does not "recook" between your outputs you can use a detail (global) variable for that, if you need code reference for that, look for: hou.node and hou.geometry in the documentation then you can reference this stored value in your rop nodes, that should not change, unless you change the input, above the node that stores the time.