Feature Request: Add surface normal to _Flow

Continuing the conversation from:

@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.

1 Like

I’ll tag on another discussion I’ve been having on the same topic. I was asking for a “Flow Along Curve on Surface” for the same reasons.

V7 Wish: Distribute Along Curve

Eric has much more technical info in his link than mine, but I think we are both looking for the same tool: _Flow + surface normals.

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.

Got that, thanks



1 Like

RH-56357 is fixed in the latest WIP


Oh, the happy tears…

Hey GIA @MikeM, I know who you are. We met at the '18 Santa Fe Symposium when I did the paper on resins.

Thank you McNeel!! You have no idea how much this helps our workflow!

Hi @EricM,

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.

I don’t know what way Paris college went with CAD. I don’t have any direct contacts over there these days. Maybe someone else on the forum here knows.

There’s been some buzz about Panther as well, but it’s pretty new.

I’d be happy to see the plugin when you have it!

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?

@brian @pascal

I seem to be getting some inconsistent results. Sometimes the objects come in oriented correctly to the +normal, sometimes they orient to -normal.

I’ve checked surface normals, curve direction, etc. Why is it flipping?

Flow TargetSrf flipped normals.3dm (2.6 MB)

Hi Mike - I’ll take a look - my guess of the moment is it is using the surface normal and not the ‘flipped’ normal on the face.

Yeah - I’ll see if we can pay attention to the ‘flip flag’ on faces. I do not know if that is possible.


To be clear, the normals in the photo are the original directions. I didn’t have to flip them to get them to point outwards.

@pascal yeah, I was just about to say we need an option to preview and flip normal.

1 Like

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…


Actually, yes that does make sense. thank you for the more detailed explanation. :+1:

@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.