What I’ll throw in here, for what I’ve been able to grasp on the few posts about the topic is… a procedure that’s quite hard to pull and frustrating. I experienced that first hand for the last week+, trying different approaches but with no success.
Now I come to you cause as I gave up on “trying hard on my end”, I went back to those posts where this is was commented and it was mentioned the PolySpit SOP, and for the mini-tests I’ve ran…it seems to work. What this means is that I have a procedure question that can be easily addressed (for those who know, of course) rather than “any ideas on how to solve this situation” call.
///
PREVIOUS SITUATION
I’m working on this “rolling metal doors” HDA and as part of it I’m seeking to offer the possibility of having holes (from lost rivets) in the geo. Procedural booleans = a mess; that we know. Anyhow, after making it happen in two different instances of the HDA, I realized the resulting bounding geo of these two consecutive boolean instances resulted in a non optimal topology. Most I’ve solved along the way, but… there was still one that… was intrinsic to the basic boolean procedure.
Example of one of most usual problems:
I went back to my approach to these holes and thought of adding an extra point, perpendicular to the point where the cylinder-to-boolean will be placed, and in case these two are too close, fuse the new point to the so called “hole_pt”. Before I only had this working with pre-existing points on the grid, but in some cases a mid-way new point is needed.
I went down a full VEX approach first, and then… little by little mixing and playing with other nodes, looking for the combination that would render a clean result (a proper snowball). But, as expected, it doesn’t quite work good adding vertices to an existing geo xD.
Description of the approach:
On top of the described, I tried adding such vertex to both prims (both sides of the same edge), and still doesn’t work evenly. I’ve also tried with EdgeDivide and keeping only the point on the shared edge, but no : (.
///
CURRENT SITUATION
Today, as I said, I went back to square one and tried to find as much as I could on others experiences with something resembling, and found they mentioned PolySplit; I went back to Houdini and tried it on standalone prims, and… it seems to work evenly. By “evenly” I mean it generates a shared point/vertex for both prims sharing the edge. This would avoid all the extra “fixing the ill-formed topology” part, which… is a rabbit hole and a no-no if we are considering to make it procedural.
So, back to the whiteboard, what do I want to do:
The approach would be run a ForEach prim on the geo, check if it belongs to the “prims_to_divide” group. If so, establish an attribute/condition as 1, afterwards this condition would be read by a SwitchIf to determine if that prim is gonna be processed by a PolySplit node or not.
Once that is determined, on those to be split (if @condition == 1), find the edge number to be divided, or the edge “between given pts”.
The PolySplit doc offers both:
pa-b:t
Cut at t percent along the edge between points a and b, where a and b are integers and t is a real number from 0.0 to 1.0.
aeb:t
Cut at t percent along edge b of primitive a, where a and b are integers and t is a real number from 0.0 to 1.0.
Any could work I believe, that’s not a problem. Then also gather the UV.x value of “where to place the point” which is easily achievable with xyzdist().
///
QUESTION
How do I read that on the PolySplit node?
Hscript, yes. But how? And this is broader question upon… reading attributes on Hscript workspaces.
So, first, in order to read the primitive stored values we go with prim() expression function (not the VEX one, that I’ve learnt before xD).
Second, we have to add the “`” (backtick Google says) so the expression can be read in the Split Locations parameter.
Let’s set an example with the “aeb:t” approach:
a = @primnum
e = e (indicative of edge)
b = @edge_num
: = :
t = @percentage (the 0-1 @UV.x result)
How do I retrieve these attributes in the Split Locations?
For example, @primnum:
`prim(0, @primnum, ”primnum”, 0)` >>> this doesn’t work (@primnum is not local variable, was there a $ something for primnum before?)
If I replace @primnum by some determined primitive number:
`prim(0, 2719, ”primnum”, 0)` >>> returns “0”, not "2719"
Retrieving these by spare inputs wasn’t the mistake, I’ve tried (I know it should work by calling itself for the expression but… just in case xD).
Anyhow, I believe this is very silly for someone who knows Hscript obviously, and you know… I tried to avoid it, cause the whole “`” and mixed calls represented a mental mess for me, but since this would mean a possible solid solution for this whole “add a simple perpendicular point” snowball (such a relief), I think it’s great time to be at least instructed on how to call attributes on such situations.
///
THANKS
Many thanks for taking the time to read this, I hope you’re able to help me and… maaaaany others I believe, as… I feel it’s really hard to find clear info (“how to”) on these procedures, at least if you’re not someone with strong programming background, or someone who has a lot of experience. There’re plenty of redundant tutorials about simple techniques to “get this thing working”, but when it gets to… basic procedures of VEX or HScript not many ask/cover it and it turns out into a needle in haystack experience. Most times by watching others work you get to understand most of the basics but sometimes ain’t enough, so… why not asking around : ).
