Fenolis

Why not, indeed? leaningBooks.hipnc I apologize in advance if any of the code appears sloppy, I might have done some things in a more roundabout way than was required... Of course, credit for the procedure should go to Anastasia Opara, I merely reverse engineered it following her presentation!

After rewatching the video (for the umpteenth time) and paying extremely close attention to Ana, I finally understand what she meant. I'm happy to announce that I have solved my problem!

In Anastasia Opara's talk at SIGGRAPH 2017, she mentions a procedure for generating a line of books leaning on one another (28:26). I have managed to replicate most of the steps (her explanations are excellent), except for the last step, in which Ana describes calculating the offset for a case in which the height of the current book is shorter than the distance from the top right corner of the previous book to the point used to instance the current book, at about 29:10 in the video. As proof of my attempt, here is my current progress: I am encountering the exact problem she describes, where the books appear to be floating due to the height differences. Her solution, in essence, was to take the top left corner of the book and measure its distance from the previous book's bottom right corner (or right bounds, this was not explained as clearly), but it seems to me that would only work for the first/second books, since the bottom right corner of the first book shares the same x-value as its xmax bound. I could not achieve the same result as demonstrated in the video. Failing to replicate the offset calculations, I then tried calculating a ray from the top left corner of the current book towards the previous iteration. This seemed to work until I ran through the random seed value and discovered that this method was not effective either. Would anyone have any idea of how to calculate this offset amount, or an explanation of how Ana's method works?

This is great for modeling a grape branch!

Okay it's probably not the bug I was expecting. I didn't notice that Pasting Relative References into the curve's coords field was pasting them as strings, and I guess converting a float value to a string has some...weird consequences like adding them together in a string field becomes a concatenation operation. Changing the pasted "chs()" into "ch()" resulted in the behaviour I was expecting, and the correct one. My bad!

Ah. I was replying to a comment >2 months old regarding the point sorting order. I thought perhaps sorting by uvs would cause the smallest number to always be in the same position. Edit: Cool model, by the way. Missing proper normals on the windows but I like the style!

Point Sort > By Attribute > uv?

I created a Curve SOP and used float parameters on a Null to control the curve's points. Strangely, when the float values are (rounded to) integers, the curve's points are located incorrectly. Attached short video demonstrating the bug. 2018-05-05 15-09-13.mp4

In order to ensure a smooth seam, the curve needs as many points as its Order to interpolate. By merging the two end points into one, it avoids a hard "Corner" vertex.

What is the difference between using the Skin SOP after the Sweep, as compared to using the "Skin Output" option on the Sweep SOP? I imagine you could do a PolyFill after skinning, then finding a way to subdivide that. Maybe with a PolyExtrude inset?

Attaching your scene is usually helpful, if you're allowed to do so. Most of the issues regarding use of the Cookie/Boolean(Updated version) node is related to the inputs you provide. If you provide contiguous surfaces (no holes) it usually works fine. Here is a thread you may find helpful: Boolean

Turn your process into a HDA at the SOP level, and be the change you want to see!

I had fun with the math shape. astroid.hipnc

looks like you did an inset after... PolyExpand3D!?

That was very helpful! Thank you! Here's a design using Polybridge.