Make2D not working properly - Rhino 6 Windows

make2d
unhandled

(Carlo) #1

Hello everyone! This is my first post in the Rhino forum community.

I am an architecture student and I bought a Rhino 6 license to work on my projects at home on my laptop.
Lately I am struggling to get the Make2D command work: I have a site with buildings downloaded from Digimap.com (educational website for topography and other terrain data) and when I make 2D in Isometric view many lines are missing.

I work in millimeters and I already tried to reduce the absolute tolerance from 0.01 to 0.0001

Note: In my uni, with Rhino 5 it works just fine.

Any suggestions?


#2

If your buildings are georeferenced, it is likely they are pretty far from the world origin. You might try moving your scene temporarily closer to the world origin and run Make2D again and see if that works better…


(Carlo) #3

Hi! Unfortunately it did not change much.
I noticed the same problem also on other geometries which I made with polysurfaces.


#4

Can you post a small sample file so we can test and perhaps submit a bug report? Thx, --Mitch


#5

Another work-around angle: I believe that with your Rhino 6 license, even if it’s educational, you are able to download and install Rhino 5 along with your 6 and use it. You might want to look into this.


#6

Yep. But we would also like to know what’s wrong with V6 and fix it if possible… :thinking:


#7

Have you try to clean your 3d model before doing make2D?
Try a “boolean union” and after that “make2D”.


(Carlo) #8

Here is the file with the buildings on the site:

Make2D-Site.3dm (10.3 MB)

@Architex I think the model is fairly clean because it works well on Rhino 5.

@AlW That’s how I am working right now but I would love to get this fixed because: 1. Rhino 6’s Make2D is much faster than in R5; 2. It’s annoying to always export .3dm as Rhino 5 file and always have to change between the two versions; 3. Rhino 5 is not optimized for high-res screens making the entire interface very ‘meeehh’ .

Thanks for the help guys!


#9

Made in Rhino 5 SR14 x64 bits.
Make2D took about 5 seconds. Its all clean.
Sometimes its better to make parts of the model and in the end group and join together with help of 2D skills in 2D viewport…


#10

@ccampolo -

Your model is pretty far from the world origin and as well it’s in mm with some pretty large numbers.

If I move it close to the origin and put it in m or even cm, it works much better.

@GregArden can this be improved anyway?

–Mitch


#11

We have the same problem over here. The geometry is very close to the origin and the size is set to metres because our students have a Citymodell. By the way: in RH5 everything works just great.


(Greg Arden) #12

Thanks for posting the file. This is a great example that hits all the weaknesses of Make2d.

  1. Units The combination of Model Tolerance, units, size and location.
    First how its supposed to work. Tolerance is the desired accuracy of the result. I use model where it is in the coordinates its stored in. I use double precision computer arithmetic that has about 16 accurate digits. Since this model has coordinates with 7 digits before the decimal point and a tolerance = .0001 of 4 digits after decimal point that means I need to always get 11 accurate digits. This is too much precision. Tolerance should not be more than .01 for this model and moving it toward the origin will make things even better.

This is such a common problem I am going to have to try and make it work better. If the tolerance is too tight I should just use a looser tolerance. If the the objects are too far from the origin I should just make copies of everything and move the copies .

  1. Intersections between objects. The ground plane cuts through the middle of the buildings.
    Make2d will not find these intersections and will not produce a clean drawing without them.
    The general solution is to run the intersect command to produce intersection curves and then run Make2d including these curves. This makes the results much better but I am not seeing intersection curves in the result. I’ll take a look at that.

Working away from origin WORSE in Rhino 6 than in Rhino 5
(Greg Arden) #13

Please send in an example.


(Carlo) #14

Thanks for your answer. :slight_smile:


(Greg Arden) #15

For those keeping score from home I have opened three bugs from this model.

  1. RH-46133 Missing Intersection Curves.
  2. RH-46132 Missing Visible lines with planar model and large coordinates.
  3. RH-46131 Make2d must be more tolerant of bad tolarance.

#16

Hi @GregArden,

Why not to include calculation of intersections into make2d routine?

Thanks,
Dmitriy


#17

Mitch -

Hi ! This is Charley.

Say, “back in the day” when I was first experiencing make2d (can’t remember now if it was at -3 or at -4) I encountered a problem with make2D and the fact that it was pretty far from the origin turned out to be the problem back then, too.

Once we discovered that was the culprit, I 1. Moved it closer to world 0,0,0 , 2. ran make2D getting hoped-for results which I was able to use successfully, and 3. suggested developers plug in a temporary calc-from origin at the geometric center of the items being extracted to 2D.

ANY progress in the nearly last almost 10 years on #3 ? There’s really no excuse that this, this far along, is still something we’re dealing with. Also, we STILL find lines on top of lines, altho this is noticeably reduced, and small curves aren’t represented accurately, with intersections sometimes overlapping, tangent surface-edges not appearing right or not appearing at all (so I’ve turned these OFF in the settings) and some curves that SHOULD be hidden, falling behind an obscuring surface, STILL showing up and having to be CLEANED UP (tedious).

Now don’t get me wrong, faster and NOTICEABLY BETTER results, yeah, I move my -5 models to -6 to run, but these are the things I’ve noticed. Ok, ALL the VERY BEST to you and the TEAM !

Thanks -
Charley.


(Greg Arden) #18

Please provide models highlighting the most important bugs.


(Greg Arden) #19

Intersects are not found as part of the calculation, as opposed to raster rendering where intersection are automatically found where adjacent pixels hit different surfaces.

So there would have to be some extra time consuming step to look for intersections in a scene. This step would be a waste of time for “cleanly” modeled scenes.


#20

“Cleanly Modeled” == nonsequitur. Either the operation has been programmed to provide correct results or it hasn’t. “Too “time consuming” to program properly” not really an answer likely to be found generally acceptable. Sort of like a similar kind of answer on a similar but different subject, where the answer has devolved to “ok, we accept that this is a “thing” and will POSSIBLY have something at -7 TWO OR THREE YEARS FROM NOW .”