Alignment problem

I’m kinda shocked that you haven’t been using SrfMorph all these years!? It certainly works better for some shapes than static Orient that ignores surface curvature. Remember this? (November, 2017)

Indeed I do remember that one. In fact, it was my first try at mapping the bullseyes onto my surface. But when I substituted my bullseye for the elliptical shape all I got back was the base geometry - no evidence of anything being mapped anywhere. I got the same results with Sporph. So after an hour or 2 of fussing with those two approaches I switched to Orient.

Every time I’ve used SrfMorph, including today, I’ve had to learn it from scratch. It’s not that hard. I can see that three years ago I used SubSrf (Isotrim) but it wasn’t required since I didn’t use it today. Orient is much more limited; it would fail completely with large “buttons” (or bullseyes or whatever).

misalignment_2020Sep26c5

I just remembered something rather important about SrfMorph… There is no need to modify the size of the bullseye shape to fit fewer (or more) copies on a surface.

All I had to do was modify the inputs to Divide Domain from 30 to 10 and 9 to 3. Morph resizes the same bullseye shape to fit the surface divisions! So simple, how could I forget? Naturally this can lead to stretching if the UV proportions are changed, but that’s a feature, not a bug.

Here’s version ‘d’ with the same bullseye and only the UV sliders changed from U=30 and V=9 to U=20 and V=6. Magic!

P.S. Here’s what happens when the UV ratio is changed to U=10 and V=6, same bullseye shape.

That’s a great example of the issue of keep shape VS stretch shape when applying a fixed piece of geometry onto a curved surface. I’m going to do some experimenting with a base shape that has much larger changes in curvature and see what happens.

My final result after 37 hours of printing:


I also find another very slick way of getting the points for Orient:

This came from a posting in the old GH forum and it works well. The only issue is that for shapes like I used above the vertical alignment of objects is variable as a result of the varying lengths of the contour lines.

I’ve learned a lot from all this, and for me the bottom line is “To morph or not to morph; that is the question.”

1 Like

Looks great!

My first post in this thread contains a disabled contour method of getting points but divides all contour curves by the same number rather than by distance, so they remain aligned vertically.

I used SrfMorph in another thread this morning - love it!

I plugged your script into mine and started it running with U Count = 30 which is what’s needed to fully cover my underlying surface. It ran for quite a while - more than 5 minutes - and then crashed Rhino.

I’m guessing there is a memory leak somewhere in the SrfMorph code that ended up consuming all my 16GB of RAM. Of course this is just a guess, but even if it’s totally wrong the long compute time SrfMorph requires compared to Orient puts it fairly far down on my list of desired approaches. I usually make quite a few tweaks to geometry before I get something suitable for printing, and I just don’t have the patience for multiple 5 minute (or longer) waita for internal computation to finish.

Hah! You waited 37 hours for a print job so waiting 12 to 16 minutes for a SrfMorph “proof” is nothing. That it crashed tells me you wired it wrong. I tried many variations a couple days ago, waiting patiently each time - and as I said, you want to make sure all the parameters are correct because the time factor is “expensive” when there are mistakes.

But the simple fact is that SrfMorph and Orient do two very different things.

Haven’t had a proper look at the thread. But just to address your original problem, another alignment of the planes seems to remove the alignment issues.
Original planes:


Aligned planes:

Resulting geometry:

Doesn’t get rid of the issue with losing the caps, though:

regardless, seems between yourself and @Joseph_Oster you’ve come up with a better method with better starting geometry! Well done on the print, looks great!

misalignment_AlignedPlane.gh (122.0 KB)

Thanks Rahul, needless to say the concept of aligning the planes with the vertical direction is something that would have never occurred to me. Frankly it seems like a strange, non-intuitive thing to do since none of the surface tangents at the points are vertical. It looks like your solution does eliminate the unevenness that started this discussion, and that’s nice, but it also raises the question of why, and how, it does that.

Perhaps this is another item for the Quirks list - I really don’t know. It does seem, at least to me, that the inner workings of GH & Rhino are “curiouser and curiouser.”

Certainly only knew about this because I have come across the same issue in the past!
What I had imagined is that aligning the plane would ensure the geometry maps exactly the same each time, thereby negating any discrepancy in the logic of the alignment component.
Though, I agree that a rotationally symmetrical object like this should map without alignment issues in the first place. Why and how are yet to be answered!