Feature Request: Add surface normal to _Flow

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.

(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?


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.



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