@pascal This is a high priority request from jewelers. All the plugins we use (Matrix, RhinoGold, Armadillo) implement this, but none of them are history enabled.
_Flow does a space morph between a base reference frame defined by:
Pb - point on the base curve
Nb - CPlane normal
Vb - direction of the curve at Pb
And target reference frame:
Pt - point on the target curve
Nt - CPlane normal
Vt - direction of the target curve at Pt
The only change is to the Nt if a target surface is supplied:
set Nt = normal of the nearest point to Pt on the target surface
A base surface is not needed. The current behavior of Nb is sufficient.
Yeah Mike, this is the same thing. I tried for a long time to get physical spacing to work like we need it with _FlowAlongSrf, but it’s difficult on single curved and impossible on double curved surfaces.
_Flow neatly solves the spacing issue (curve length or _Stretch for domain) and orientation (curve direction), but you can’t make your stones face up .
There’s still the array and scaling issue, but that’s a separate thing.
That’s right! It was good paper. I remember you telling me about how you were doing all of your jewelry in native Rhino. We’ve gone there too since in our classes.
Are you planning on going to this year’s final SFS?
Yes, I can’t miss the finale. It’s sad that it’s ending.
Since posting YouTube content again, I’ve been hearing a lot more about the MatrixGold revolt. Seems like everyone is either going native or back to V5. Do you know which way Paris went?
I’m almost done with a free-to-use finger rail plugin. I’ll send it to you next week.
Hi @brian
Is there any chance that this will end up in a Rhino 6 service release, or will we have to wait for Rhino 7 for it to be officially released?
Hi Mike - brep faces can have a normal shown by say Dir that points one way, but the underlyting surface’s ‘natural’ normal as determined by the U and V directions (right hand rule) may be the opposite. It looks like right now we’re using the natural normal. When surfaces are joined, the resulting object needs to have a consistent normal direction, and where this contradicts the underlying surfaces’ natural normals, Rhino adds a ‘flip’ flag so that a face is treated as having that required normal for most operations (like Booleans for example) . It looks to me like Flow is only using the natural normals… I hope that makes sense…
@pascal my problem was on a natural normal, but I couldn’t flip the targetsrf without breaking history. I know you can flip the input curves, but that causes side affects, too. A lot of times our targetsrf will be defined by one parent crv that’s offset and lofted. Flipping the one parent curve flips the offset direction.
Right, I saw that. I think using the flip flag will at least be better, I’ll ask if we can do that or add an option. A flip option inside Flow is (probably) less likely in the short term at least, I would say.
