Is this another Rhino/GH quirk?

[Birk_Binnard]

I’ve got a nice Loft surface that looks like this:

I want to map some geometry (biscuits) on to the middle area of this Loft, so I trimmed off the top and bottom sections to get this:

But when I do the mapping to the trimmed result using either Sporph or SrfMorph the mapping is applied to the entire surface, not just the trimmed area. I thought maybe RebuildSrf would limit the mapping to just the trimmed part, but no - it recreates the entire original surface.

Then I though I’d DeBrep the trimmed surface and just work with it’s Face. But that behaves the same way - it acts as though it was the complete surface, not just the trimmed part.

Is there a way to make the trimmed part it’s own complete surface independent of the original Loft? Or is there some other (better) way to do the trimming?

another_quirk.gh (16.5 KB)

[martinsiegrist]

You will have to shrink the surface. It can be done with a little C script. I added it to your file.

another_quirk.gh (18.8 KB)

[mats_magnunson (Mats)]

One option would be to get a few section curves from that srf to generate a new untrimmed loft surface.
This should work later with the morphs.

[Birk_Binnard]

Thanks (again) for your help with this Martin. Apparently there really is something going on behind the scenes with the Trim function. I have no idea at all what Rhino’s Shrink command is or does, but it must be something because it does give significantly different results when I feed it’s output to Sporph and SrfMorph.

When I use Sporph Rhino displays the original set of biscuits to me morphed.

Needless to say I have no idea why. Switching Sporph’s input to my original Trimmed surface gives this result:

which is exactly what I want, except of course the biscuits cover the entire surface, not just the trimmed piece.

Note that both the above images resulted from keeping Sporph’s inputs all the same except for the target surface.

SrfMorph is different. When I give it your Shrinked surface I get this:

This is also correct except of course the biscuits are not wrapped all the way around the surface. I tried fixing that by increasing the U and/or V domains from (0, 1) to something like (0, 1.1) but that really messed up the resulting geometry. Obviously I don’t understand why (0,1) doesn’t work.

If I substitute my trimmed surface for yours SrfMorph gives me this:

Again, this is almost OK except the wrap doesn’t go all the way around and it covers the entire Loft, not just the trimmed part.

If I use a surface of revolution I get perfect results:

So after that I wanted to switch to a Loft surface which would produce a more interesting result.

It looks like I’m close to resolving this, but not quite there yet. I don’t mean to take up your time - I reckon you have a real job whereas I just do this as a hobby, but I get disturbed when things don’t work like they should.

[Birk_Binnard]

Thanks for that Idea Mats - I’m going to give it a try now and see what happens.

Well - good news/bad news: the good news is that instead of using section curves I picked the single interior curve from BrepEdges and used it to make a Sweep1 surface that duplicates my original trimmed one. SrfMorph gave nice results except for the same U/V wrapping problem I showed in my reply to Martin:

Sporph behaved the same way as Martin’s solution - it just showed the un-mapped biscuits.

I’m sure there is some little tweak required to fix this - it just needs finding.

[martinsiegrist]

Yes I have a real job I’m currently designing over 2000 m² of climbing walls for a gym extension in Switzerland. I developped my own algorithms and it can get complicated so I enjoy a different challenge from the forum every other day…

Sometimes U and V are flipped.

Post your latest file if you need my assistance.

[Birk_Binnard]

Well here you go Martin - as I sometimessay - be careful what you wish for. This file is pretty ugly because I expanded the cluster I made from your previous method and then added the stuff needed to make the result I wanted. I’ve disabled the Sporph and SrfMorph components so it will load quite quickly. The final SDiff is also disabled - that takes a while with just 21 biscuits - the actual number is around 67 or so. Also be aware that the Seed value can crash the whole thing sometimes.

squirclemorph.gh (56.3 KB)

[martinsiegrist]

UV on the reference surface was swapped.

Not sure how to automatically avoid this but a simple fix is to draw a new reference surface in Rhino.

squirclemorph.gh (56.1 KB)

[Birk_Binnard]

Very interesting - and even more quirky! I understand about UV stuff, so I thought “why not just use RevSrf to reverse the direction of the base rectangle.” Well, the answer is “becuase that doesn’t work.” So yet another quirk (or something) reveals itself.

Your fix works great…except for this:

Isn’t that infuriating?

But - Oh frabjous day calloo callay! Using a different Seed value (31) fixes that. (Would a normal person even think about trying that?) I think that must be quirk #57. (I really should have made a collection of these things.) At any rate, many thanks (again) for your help with this. Now I just have to add the stuff for making the base and I’ll be all set.

[martinsiegrist]

Sorry I did not see that and unfortunately I have no solution.

[Birk_Binnard]

Not a problem at all. Changing the Seed value is something I do on a regular basis just to get a set of Voronoi cells that I like. (I have quirks too.) Here’s my current result before I up the cell count to 65 or so and find a way to make pretty grooves in the base. I expect the final version will take between 4 - 5 minutes to calculate & render.

[Birk_Binnard]

Final result with 63 biscuits. Print time about 7.5 hrs. Thanks again for your help with this one.

[martinsiegrist]

Would be nice to know why the morphing failed on some corners of the biscuits in my example. Maybe just too far from the surface?

[Birk_Binnard]

Indeed it would. My guess is the morph code has some dependencies on the shape of the morph geometry that it doesn’t handle properly. I encountered these problems when morphing onto a base shape (like the one I posted) that is both concave and convex, as well as morphing on to a plain cylinder with straight sides.

In each case the problem went away after I tried different seed values that resulted in different biscuit shapes to be morphed. Sometimes I had to try 3 or 4 different seeds until I found one that morphed properly.

In addition, the morphing error can get huge with changes to the thickness (and not the shape) of the biscuits. “Huge” means that instead of extending a small bit away from the base surface, the morphed geometry gets extended really far away into the distance. I found that situation to be quite bizarre indeed. But again, some small changes to the input parameters was able to eliminate this.

Finally, I think there is significantly different code used for Sporph and SrfMorph. There must be a reason for this, but I have no idea what it might be.

Many years ago I was 1 of 3 people who wrote the very first 3D graphics software - it ran on really big IBM mainframes. We dealt with comparatively simple aircraft shapes, and we found out early on that there was a lot more code required than we anticipated. Plus the math went all the way up to 2nd order differential equations. So I guess we shouldn’t be surprised that today’s software has some quirks that can produce unexpected results.