eikonoklastes

If you don't want to get into TOPs just for this, you can just use a For Loop. It is possible to vary any incoming parameter from your source geometry with any level of control that you desire. For very large iterations, you might want to turn that into a Compile Block to boost performance (be warned though, here be dragons...) In the example I'm posting, I'm varying the bend angle, and the probability of adding a hat to the result, but you can go nuts with literally any parameter on the source geometry. I have used separate nodes for each variation because I personally like that clarity, but you can just easily have all of them in a single Wrangle. variations.hiplc

Is your curve closed? Try using an Orientation Along Curve SOP before the Sweep. If that doesn't work, can you post your curve here?

Deselect the node before pasting, and it will paste as a disconnected node. Edit: the above info is wrong. I seem to have had a brainfart, I could have sworn that this is how it worked, but you're right - it stays wired to the original parent.

You can do this with the Distance From Geometry Node, and then use a simple Group Expression that says group points whose distance from the target is within the specified number. Distance From Geometry.hiplc

This is easily possible by packing the object, initialising a normal if necessary (not required if your object was already aligned to the world axes to begin with), and then using the Path attribute in the ROP FBX. Here's a preview of the exported tube: https://imgur.com/8xoYEYM Scene attached here. 210706_ROTATE_path_attr.hiplc

Use PolyPath to combine primitives.

@Alain2131Thank you kindly for your help. I should have clarified that this is a bit of a contrived setup as part of a learning exercise for compile blocks - I specifically want to learn how to reliably get them to work with complicated nested blocks. The generate_line_points wrangle was only created because I wanted to try plugging Block Begin into it, and the Line SOP doesn't have an input. That whole for each loop block is not required, and can be sorted with something simple like pscale, that will drive the line length as I need it. The Distance Along Geometry SOP just needs an internal named reference replaced with a spare input and it will compile. It's a minor oversight on SideFX's part; I've put in an RFE and they should fix it soon hopefully. Once again, thanks for your time, this forum is amazing.

Hi, can someone help me figure out how to fix the compile block error? I have a nested For Each Loop, and I likely need a Block Begin somewhere set to Fetch Input, but I can't figure out where. Reeds_test.hiplc

Slight modification to what Gorrod just posted. To keep things cleaner, set the Points per Point to 1, and define an attribute than returns between 10 & 20 randomly per point. The new Attribute Adjust Integer SOP is perfect for this.

I'm sorry, I'm still extremely confused. You mention a 6x6 inch grid, but I see a rectangle, not a square. Are you talking about each face being 6x6? Then you mention image 3 being an example of a 12x12 quad selection, but I see no 12x12 selection anywhere. It would really help if, rather than screenshots, you post a sketch of what you're after, or at least annotate over your screenshots, because I can't see what you're describing. Specifically, it would help if you could draw out exactly what "6x6" and "12x12" means.

The animation data is stored on the node you're keyframing. Shift+click the channel to bring up the Animation Editor for that track.

That documentation is for selecting gradient points in the Composite View, when working in a COP network. Is that what you're after, or are you referring to a ramp parameter in SOPs? If it's the latter, you can Ctrl+click to select non-contiguous points, or Shift+click to select a range in sequence. The visual indicator for the selection is pretty poor, but it does work.

I'm sorry, but I got completely lost. Can you post a couple of screenshots, preferably with sketches/annotations of what you're trying to achieve?

Sorry this is a bit off-topic, but surely the game engine you're running manages back-face culling by itself? Why manually delete perfectly good faces?

This was a bug that was fixed ages ago. You shouldn't be having this issue on any recent version of Houdini.