[Feature Request] Add “Flip Normal” Toggle in Surface Creation Dialogs

Rhino
1

image
image1920×1244 217 KB

AM64 Rhino8 - Buenos Aires -Tuesday, April 7, 2026

Add “Flip Normal” Toggle in Surface Creation Dialogs, Sweep2, Loft, etc.

When creating a new surface using tools like Sweep2, Loft, or similar, please include a simple boolean toggle: “Flip Normal” directly in the command options dialog.

This would be especially valuable when working with Record History enabled.

CURRENT ISSUE

In many cases, newly created surfaces are generated with inverted normals relative to the working view.

  • The surface appears visually incorrect (backface shading / display issues)

  • It becomes difficult to evaluate the result during creation

  • More importantly: Record History workflows break down, because fixing normals afterward (e.g., using _Flip) is not part of the history chain

So the user ends up in a loop:

  1. Create surface

  2. Realize normals are wrong

  3. Flip manually

  4. History becomes unreliable or unusable

EXPECTED

Ideally, Rhino would infer the correct normal direction based on:

  • View direction (camera)

  • Rail / section orientation

  • Adjacent geometry

However, since this is not always consistent, a manual override is essential.

:light_bulb: Suggested Solution

Add a simple checkbox in surface creation dialogs:

  • ☐ Flip Normal

Placed near continuity/alignment options (as shown in Sweep2 UI)

This would:

  • Allow correct orientation at creation time (real-time if possible)

  • Preserve full Record History compatibility

  • Avoid post-process fixes that break parametric intent

A more advanced approach could be:

  • Auto-align normals toward the camera by default

  • With the toggle acting as an override

Thanks for the great work

2

thanks for this-

YT here-
RH-94529 flip normals breaks history

1 Like
3

Hi,

I complained about this a while back and still nothing done.

Flip shouldn’t affect history - Rhino / Rhino for Windows - McNeel Forum

When is McNeel going to improve how history works in Rhino it’s terribly deficient and could be so much more productive. It’s intolerable that no history improvements are planned for V9
RM

4

you see the above bug report yes?

1 Like
5

That related bug report, RH-74574, deals with flipping after history. And I believe Grasshopper was designed to solve these history limitations. This bug report, however, deals with flipping before the history is applied.

6

Yes but that’s not a bug your post is a requested feature, if McNeel fixed flipping normals not to break history than you wouldn’t need this extra band aid. That’s what my post is about and would help you if McNeel implemented the fix.

GH isn’t an option in this case and wasn’t designed to fix history where history should be working in the first place and not break from minor changes and caveats.

My point is that history needs major improvements and was flawed from day one. Ignoring the troublesome is not great.

RM

7

It points to a structural limitation in how History handles surface direction.
The toggle is a simple, low-cost workaround that would improve usability immediately.

The real opportunity is making History more robust—but this is a practical step forward in the meantime.

Short-term fixes must be designed so they don’t block the long-term solution.