Make 2D does not take into account draw order?

I am not getting the desired result when running the Make2D command on Rhino 6.

This is the input, 3D curves in SE viewport.

This is the output, 2D curves in TOP viewport.


1 Like

Is this the standard behavior? I have no control over what gets projected on top of what, unless I physically move the geometry along the Z axis, solution that does not work in isometric for it modifies the model…

Is there no solution to this issue?

Hello - I guess I need an example file - I’m not sure what we’re dealing with, exactly.


Hi Pascal, thank you. If you look carefully the images you will notice some cyan lines on the model were lost after the Make2D command run. Maybe I should have pointed that out in the OP.

Make2Dproblem.3dm (264.9 KB)
Here is the file.

Thanks - I see this, I’ll get it on the pile. Looks wrong to me.


1 Like

You are right that Make2d does not use draw order. It tries to eliminate duplicate lines on top of one another. Therefore it chooses one line or the other. The choice is based on depth, the frontmost line wins. If the lines overlap in 3d it is probably unpredictable which gets represented in the Make2d output.

I’ll leave this as an open problem. Do you like the results where the cyan lines are produced? In particular the black lines are trimmed back where they overlap with the cyan lines. Seems like draw order controls could be used when depth testing fails to resolve the issue.

Aha. Thanks for clarifying this.

Indeed, cyan lines should remain on top, just as the draw order shows in the “SE” viewport. (First image in OP).

Why is this not getting fixed for R6? Are y’all gonna give a major discount on R7 upgrade? 'Cause the only thing we’ll be getting R7 for are bug fixes at this point. Which seems a bit unfair if put lightly. That’s 26 seats. Potentially 30 by the end of the year.


Really? SubD? RhinoInside? Grasshopper 2?

Nope, we don’t use any of that.We do use Make2D sometimes though. We’re not a design company.


I haven’t heard any discussions of doing anything different than we always do - offering a discount to the upgrade for a period immediately following release, and then offering the normal upgrade price after that.

And, as always, Rhino 6 won’t ever die. So if Rhino 7 doesn’t have anything you need, please don’t upgrade. We don’t want your money or your upgrade if we’re not giving you anything of value.

1 Like

It seems I am not following this discussion anymore… this issue won’t be fixed for Rhino 6…?

This sort of major change in how a command is designed is too risky to do in a released product version.
Major changes like these get done in the Work-In-Progress process where the bugs can get worked out and the unintended consequences of these major changes.

To add to what @John_Brock said:

The problem you’re seeing is actually a lot trickier than you might imagine. In your viewport, today, the cyan lines draw on top of the black. This is likely due to layer order, and perhaps even the order in which you drew the objects. It could also be related to using draw order tools in Rhino like “Bring To Front”, “Send To Back”, etc. In short, you may be seeing cyan on top purely because you’re lucky.

Make2D wasn’t designed with draw order in mind (sorry, maybe that was an oversight), and so coincident lines are chosen at random (I bet there’s more logic to it than random, but I don’t know it) for being hidden or shown. Getting that draw order information passed into Make2D, passed around through all the functions that comprise Make2D, and causing different results takes effort. It also means changing code that is, for the most part, working well in Rhino 6.

The risk to implementing your fix is that we break other things (because changes nearly always result in breakage). And since we don’t have an exhaustive set of tests to run on Make2D, we can’t really guarantee that our changes will not have dramatically negative consequences for the rest of our customers.

So… we choose to do major work like this in the next version.

1 Like

I would like to add, that not just one discipline should be taken into account.

In some fields one’s view of draw order may be correct, in other - wrong.

In this case, draw order would be limited to the explicit settings that objects can have when using “Bring To Front”-like features. If you don’t want draw order set, don’t set it, and Make2D would not consider it.

I can’t imagine how “random” could be useful in some disciplines.