Feature Request: Add surface normal to _Flow

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

-Pascal

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…

-Pascal

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.

https://mcneel.myjetbrains.com/youtrack/issue/RH-56566

-Pascal

I can tell you this is critical and will be a huge complaint once it goes live. Every plugin has a static version of this, but we’re desperate for a history enabled one. That doesn’t leave an option except to add a preview when a targetsrf is selected and allow for a flip in the command.

Sometimes you can’t even flip the curve and get the srf to flip.

We definitely need something to be able to logically control the normal result. On my test project it’s going 0 for 3 for normal direction.

We have a different workflow than Eric. We’d be using part of closed polysurface as the target surface, so we may never even see what the original brep normals look like before running flow.

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

I agree with Eric here. I think this would be a very elegant solution from a user’s perspective. Using the flip flag would help, but being able to pick +/- normal direction within the command would be more flexible.

1 Like

@pascal is there a good workaround you’d recommend until then (hiiIII hope you’re well :smiley: )?

RH-56566 is fixed in the latest WIP

The latest WIP introduced a lot of bugs into this command. This model I did yesterday now flows skewed.

FlowTargetSrfBug.3dm
(156.7 KB)

Also, editing the target surface has the tendency to swap the orientation from the surface N to the V.

First try using the current WIP (7.0.20028.12435, 1/28/2020) and I’m getting weirdness. Stone flowed right side up(correct normal), curve flowed upside down (flipped normal)

FlowBug.7.0.20028.12435.3dm (488.6 KB)

If you keep playing with the curve, It starts confusing V for N and flows on it’s side.

@pascal can you reopen https://mcneel.myjetbrains.com/youtrack/issue/RH-56566?

Hi Eric - thanks I’d like to be able to reproduce this from the inputs - are the base curve and target curves the gray one and the one on the surface edge or? I thnk so, and I get this:

Is that correct so far?

-Pascal

That is correct. Try point editing the purple base curve and the child curve will start following the target surfs V instead of N.

Also, there is a mix of rigid and non-rigid child objects. Doing multiple flow statements with the same base and target objects results in both inverted and non-inverted target surf normals.

Hi Eric - What it looks like so far is that the bug is that the replay of the flow operation takes into account the current CPlane at edit time and not the original CPlane , for the update.

https://mcneel.myjetbrains.com/youtrack/issue/RH-56784

-Pascal

Okay, I can see that. The oneview bug might explain some of the really strange things I’ve been seeing.

RH-56784 is fixed in the latest WIP