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.
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.
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)
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:
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.