Flip shouldn't affect history

Please make it that Flip doesn’t effect history it’s for rendering and display and is a real pain to work around or to get right when working with surfaces from edge curve command. Flipping an object should not break history.
Please fix for V7.


I agree. I also think that flipping is a necessary step just to continue building a model with history, where some rhino tools are pretty stubborn (or rather careless) about which direction to create normals. For example: _Patch would create a surface with the normals in the inverted direction of all its boundaries! :man_facepalming:t2:


1 Like

Hi RM - It can indeed be a pain - but flipping constitutes ‘editing the output’ - it is not a neutral operation like changing color or something, and that is, for now, how it is. Flipping might indeed be a reasonable thing to expect History to pay attention to as Input to a history operation. This will not change in V7, nor in 8 I would guess, either.


Hi @pascal
I don’t really understand what you mean it seems Rhino doesn’t care which way objects are flipped Rhino is render both sides friendly. Can’t the developer just quote out that line that calls history violation seems easy as a " mark in front of line of code which wouldn’t effect any code or it’s functioning in other places.

I really wouldn’t care normally as previously I would flip all my models how they would need to be orientated after the fact and save and export in some kind of format, obj mostly.

But recently my workflow has changed from saving models to synching models which is so-o much better than saving and exporting models. Thus normals orientation has become a problem in my downstream app that is non backface friendly. I know this doesn’t matter to Rhino.

I foresee that exporting models is becoming a thing of the past and thus Rhino will need to play better with the other kids on the block if you want to sell your product. In fact you guys will be shooting yourselves in the foot to not accommodate more modern workflows.

Appreciate your candid reply.

I don’t think it is as easy as that, I think it means a reverse history call needs to be made to the parent in this case, that tells to replay the history with flipped normals instead of just flipping the surface.

Hi @Gijs

Even if it’s not that easy why can’t this be fixed it makes no sense? This is another faux pas in the way McNeel crafted history and refuses to listen and fix any bugs or limitations. It could be such a powerful workflow but the tons of caveats and worse the lack of McNeels interest in making it better and fixing it is beyond comprehension, I have yet to see McNeel fix or take one user suggestion in the history area.
Thanks for your reply,

1 Like

Preach! :+1:

If rendering were the only thing that depends on surface direction, it might be that easy. Surface direction is affects a lot of stuff, but the main point here is that flipping is editing the child in a history chain - as you know, that breaks history.


What about a feature called “Update history” or “Ignore History change”, which will enable the user to preserve the History on a specific object (surface or curve) even after flipping the surface or curve direction?

1 Like

A robust history implementation should automatically do what’s called “geometric matching” behind the scenes. Just as with blends and other things jumping to different edges after a trim and ruining the model, that’s completely unnecessary! History should not just record an ID, but also some characteristics of the geometry it’s associated with, including transform. So, before Rhino does any history update, the affected geometry should do a transformation check, and if it notices that the geometry has updated its transform then before blindly moving along it should first check if any geometry at the old transform matches the characteristics associated with the ID and if so update the ID to that geometry rather than updating the transform.

The above is not my invention, btw. Other CAD packages have been doing this for a very long time. As always, McNeel is either too resource constrained or too blind to get with the times (which I guess is why they can keep the price so low).


Hi Pascal,
But in this case flip doesn’t affect anything except breaking history. I don’t get why you can’t see the pain of it not working properly and instead defend a bad system?

We’re all willing to chime in and give our thoughts and we actually already have but McNeel won’t even take the time to enter into a polite conversation, listen to what users want, attack what’s wrong and fix it. It’s computer programming it should be changeable and fixable, faults should not be carved into stone tablets nor defended.

I understand that it can be a nuisnace, what I am saying is that surface direction is not necessarily something trivial that can just be ignored if it is changed, it is in the geometry that is part of the object. History is built to break when the child geometry is changed. There are, as far as I know, no checks for particular types of changes. It seems possible that the ‘flipped’ flag on a face can be ignored as a special case, I can ask the developers, it is certainly worth a try, but I don’t know what all the consequences might be, I would not count on it. The surface direction is a property that is a consequence of how it was made, so re-making it to update with History and knowing to flip, or not flip, the result seems iffy…

That said, it is incorrect to say it is not working proplerly - there is nothing here that breaks the rule that says editing a child breaks history - it is not working as you want, right now, that I understand.


I’m not saying this shouldn’t be addressed, in fact it’s one of the things I run into frequently myself when modeling. I just wanted to point out that things that seem very simple from a logical point of view are not guaranteed to be simple to solve from a programming point of view. And sometimes it’s the opposite. In any case, I agree with you that this should be looked at.

1 Like

Hi @pascal @Gijs
I can see this being important for more complex surface matching but I’m not talking about that.

If you reread my first post I am talking about a simple surface from the command “surface from edge curves”. And worse it’s only three lines used and they are not connected to any surface. Which actually makes finding which curves to flip harder.

Perhaps there is a bug in the 3 edge curves? Because no matter how I select the curves in the attached file it always results in a surface being orientated the wrong way.

In the attached file…
Use surface from edge curves and select the curves while in a backfaced render view mode.
(I’ve attached mine if you don’t have one)

For me no matter how I select these lines clockwise or counterclockwise the problem surfaces always results in a surface facing the wrong way.
The only workaround is to flip the lines first but then I have to create a surface that is improperly orientated in order to find out which lines to flip so very tedious.

Can’t history be tuned or turned off for “surface from 3 edge curves” since the only solution is to create a failed surface first. And it doesn’t matter which order the curves are selected so there’s no other option but to create wrong oriented surface then flip some of the curves then recreate the surface.

Because there are only lines and no surfaces’ edge curves used this won’t effect history of an already made surface so hopefully it shouldn’t be a problem

Thanks for your input and for taking a look.

HistProbSurfaceEdgeCrvs.3dm (208.9 KB)

BackFaceRendered.ini (12.1 KB)

I don’t think there is a bug in EdgeSrf. Curves that form a closed loop and are oriented clockwise, will generate a surface facing the camera, and facing away from the camera when they are oriented counter clockwise.
But in this scenario, you cannot keep all curves rotating the same way, since you are using the curves for multiple surfaces. What is clockwise for one set of curves, can mean that for the next set, a shared edge is counterclockwise.
I’ve added RH-74574 Wish: Flip preserves history


Hi @Gijs
Thanks for your help and for taking a look at the file.