I have a three-dimensional grid of cubes arranged in a circle, each cube having six faces, giving me a data structure with four subscripts. I want to select the faces of the outermost cubes in each of four directions.
In two of these directions, this is a very nice application of the SplitTree component, giving it a mask of {?;?;0;1} and {?;0;?;4}, i.e. selecting the number 1 face from cubes in the first rank and the number 4 face from cubes in the first row. Fine!
But for the other two sets of faces, what I really want to say is {?,-1;?,2} and {?,?,-1,3}, where the “-1” would indicated picking up the largest numbered cube in that index. Except that the “-1” notion is not supported, of course. Is there a way to specify what I want using SplitTree?
I attach my actual solution to this problem, which involved using SplitTree to pull out the number 2 and 3 faces of all the cubes and then a dexterous use of PathMapper and List Item (-1) to find the last subtree. This worked, but there MUST be something better.
On a more general philosophical note, there are many components that work against list items where the analogous operation against path subscripts would be very natural. For example, Dispatch, List Item or Cull Pattern. Does anyone have a form of documentation showing the mapping between these basic list operations and how the same effect can be applied to a particular subscript of a path?
I found it hard to see the cubes until I used PShift(white group) on the mesh faces. Then MJoin returns the cubes and one more PShift groups the cubes into eight sets of 25 cubes each. You can connect the output of the white group to the ‘Tree’ input of the ‘Tree/List Viewer’ tool to see how they are organized at that point.
Then I found the center of each group of 25 using the average of their center points (Avr of Volume ‘C’ (Centroids)) and sorted the cubes by their distance from that center. SubSet(yellow group) returns the sixteen (‘0 to 15’) outer cubes in each group.
Finally, the blue group sorts those sixteen outer cubes consistently…
I know you asked for faces, not cubes, so this might all be a waste of time? Weird problem!
Thanks so much for looking at this. Your solution is certainly working for me - I see what you are doing in putting a bounding box around each chunk, which certainly identifies the required faces. It is wonderful to see other approaches to a problem, and how different they can be.
I remain irritated that the Split Tree functionality is unable to do what I want, unless I am prepared to construct a particular path mapping based on knowing the actual subscript of my largest path index, which prevents my use of a slider for controlling the number of cubes in each direction. Unless I am prepared to construct the path mapping string as a concatenation of text values, I suppose. Ugh!
Many thanks again - I am still learning this stuff and am constantly frustrated by the lack of component documentation. Sigh!
It looks like @mattgaydon has your answer - amazing, though obscure. Instead of Param Viewer, I use Tree Statistics ‘P’ (Paths) output for games like this (see the internals of my ‘Tree/List Viewer’ tool). But I gave up on Path Mapper very early in my exploration of GH as it was too easily broken when other parts of a definition changed.
With only a little more effort, the BBox approach I used can identify the mesh faces that touch the other two sides (yellow group below):
Hi. @bob.h.mackay
These are the four splitting masks I can get from your data tree branch path indices.
Have no idea why the second branch path starts at 1 rather than 0.
Thank you Matt for this amazing string formatting solution. I see how the parameter substitution works. Still kinda sick, but clearly works. I had seen that forum thread before - assuming it is a complete description, I believe that there is indeed no way to select paths from the upper end of a subscript in Tree Split itself.
Joseph - your observation about Path Mapper being fragile is the main reason why I wanted a mechanism where changes to the numbers of items in each dimension did no break the algorithm. Just feeding in a numeric subscript would have been wrong. Matt’s format gets round this. I do like your approach to getting what is needed in a purely physical way.
HS_Kim, yes, I saw that my grid had skipped the 0th subscript. I know why, but it did not break anything other than my first mask having to include a ‘1’ rather than a ‘0’. My original construction of the grid gave me points inside a square, skipping the points on the boundary. I should fix that. But the solution of hardwiring the upper subscripts was what I was trying to avoid, and the point of my question.
