Here’s a relatively simple ICE tree that arranges hexagons on the XZ plane. The “difficult” part was creating the arrays of position coordinates. For that I used the standard modulo technique. It’s funny, it all makes perfect sense when you’re plugging stuff together, but afterwards it’s hard to make heads or tail of what you did
To understand what’s going on here, it helps to look at the final arrays that are built:
The math for arranging the hexagon tiles is pretty simple. I started with a simple test point cloud to make sure I understood what I needed to do. After that, it was just a question of setting up the arrays.
If you want to take a look at the ICE trees, here’s some compounds. Note that this isn’t a finished piece of work. It’s more of a draft version. For example, my hexagon has a side length of 5 and that’s hardcoded into the ICE tree right now.
Let’s build a regular hexagon!
In this example, I take the vector (5,0,0) and rotate it by 60 degrees, then 120, then 180, and so on, until I have the 6 points of the hexagon. In ICE, that equates to getting an array of rotations, stuffing that into Rotate Vector, and getting an array of positions back.
Notice how the length of each side is the same (5), as is the distance of each point from the local origin.
Before I jumped into building the polygon, I first did a quick test with a point cloud, to make sure I understood how to add points in the right places. In general, I think it’s good practice to do some kind of “proof of concept” before you really dive into the details.
Here’s another way to split an edge into N new edges of equal length. This time, I use the offset.
With a split ratio of 1, I get a bunch of new, zero-length edges that all pile up at the far vertex.
But I can use the offset to move all those edge vertices down the vector between the two original edge vertices:
Sometimes it’s interesting to look back at how you wired things together on the first go. For example, look at that weird Pop from Array bit on top; I kinda like it, but maybe doing two explicit Select in Arrays is more understandable.
Anyways, here’s something that could be useful when splitting edges…
Here’s the basic idea of how to split an edge into N equal-length new edges. Notice how I work backwards (in the sense that my split ratio decreases). That way I don’t know have to know (or care) about the new edges. I just keep splitting the same edge, whose EdgeIndex I already know.
Based on that observation, here’s a rough draft of an ICE tree that takes an edge of length N, and splits it into N equal-length edges.
Here’s a modified version of Mr Laforge’s compound that does the extrusion length and inset based on polygon area. Yeah, it uses a Repeat so I don’t think you would use it on a dense mesh and then just leave it in the stack to be reevaluated over and over.
The main idea is that you have to store the polygon indices (and the lengths and insets) before you do the extrude.
See also ICE Modeling – extruding polygons with random lengths
Here’s a little ICE modeling example that chains together a few basic polygon operations:
And here’s the same thing, but with no ICE:
Here’s an ICE tree I was fiddling around with…given some polygons, this ICE tree resizes those polygons by moving points along the vector between the original point position and the polygon position.
Since the introduction of ICE modeling, you may have hit context mismatches like this:
That’s because compounds like Test in Geometry and Randomize Around Value are built to work with points/particles. For example, if you look inside Test Inside Geometry, you’ll see it is getting the point position.
So, when you want to use these convenience compounds in a different context, you’ll have adapt them.
I didn’t look yet at the Random Extrusion compound Guillaume posted yesterday, because I wanted to work through the basics on my own (but do go get his compound, it’s sure to be pretty useful). Here’s a simple ICE tree that uses a different random length for each extruded polygon:
You can’t get different extrusion lengths for different polygons without using the Repeat node. That’s because the length, inset, and transform are basically per-object, even though you can plug seemingly per-poly values into those ports.