In the image above there are 3 boxes, when I Make2D shouldn’t I get 3 rectangles?
When I set them aside I have one rectangle an 2 other polylines.
I’d say ‘yes’.
Also, I wonder what triggers which of the boxes to get an entire outline and which only the remaining edges.
Make2D of the top view gets the green box to be completely outlined; from the front, it’s the blue one…
But then, in the greater scheme of things, I would also expect the edges of faces to be joined into a closed polycurve. And different faces of the same object each retaining all their edges. I thought we were going that way based on lengthy discussions a long time ago but clearly I haven’t been paying attention…
1 Like
It’s not always consistent I notice. Sometimes I get 2 rectangles for the exterior boxes and for the box in the middle just two shot lines at the endings.
Yeah, this looks broken/incorrect to me - thanks.
Hmm- thinking a second longer, on the other hand, it might tricky to solve - one of the complaints for old Make2D was that there were unnecessary curves generated - my guess is this result may be part of that clean up and it may be hard to win for all situations. The good news is that you can make three separate Make2Ds (or two, I guess, in this case) and they will register correctly with the full set of curves.
-Pascal
In this case, would be useful to be able to run Make2D in a script for each object in objects selected.
Yep - here is a very quick and dirty python that you can use - it assumes the Make2d settings are already as you like them…
import rhinoscriptsyntax as rs
def Make2dPerObject():
ids = rs.GetObjects("Select objects to draw", preselect=True)
if not ids: return
cmdStr = "_-Make2D _Enter"
rs.EnableRedraw(False)
for id in ids:
rs.UnselectAllObjects()
rs.SelectObject(id)
rs.Command(cmdStr)
rs.EnableRedraw(True)
if __name__ == "__main__":
Make2dPerObject()
1 Like
When you don’t know which object or surface a curve belongs to and you just get a bunch of duplicates on top of each other, then, yes, one can say that they are unnecessary. If, on the other hand, all edges of one surface are automatically joined into a closed polycurve, there wouldn’t be any unnecessary curves. And it would make it easy (or rather - for complex scenes - feasible) to hatch surfaces for illustration purposes. I’ve used countless hours in the past cleaning up the results from Make2D using join and CurveBoolean to achieve this and I really thought that the new Make2D would automate this.
In any ‘real’ scene with hundreds of objects, I don’t really see that as a solution.
1 Like
I do agree with you @wim on both points. It is important to have a 2D representation of 3D objects which behaves in the same way all the time, otherwise it is not reliable. Boxes should always be rectangles, if 2 faces are overlapping there should be two lines overlapping as well. And yes, the script will be very slow in a real scene with many objects.
Cleaning up after make2d has been one of the most time consuming and extremely boring task for too long.
1 Like
Yeah, me too…
Philip
Well, yes, you’re right- if we keep track of the objects, it should just work.
https://mcneel.myjetbrains.com/youtrack/issue/RH-40611
-Pascal
@Bogdan_Chipara, @wim - Hi all- I’ve been chatting with the developer about this and indeed a bunch of code is in place to avoid stacked lines… so… a couple-three questions -
- Unless you separate the lines as in your example, what is the real-life drawback to this output?
- Is there a workflow or some output that is made difficult or impossible? e.g do you expect to be able to separate the output and see the entire objects, something like that?
- Would you expect the full object to be drawn and if so, are any of the lines hidden lines?
thanks,
-Pascal
Hi @pascal
In short : make2d per object will make life easier when sorting elements, dimensioning , tagging, hatching, setting line styles, calculating areas.
Some examples of common tasks:
in urban planning, creating 2d drawings from a 3d model of an urban area from top view. usually buildings touch each other and have very unexpected shapes. each resulting polyline must be filled with a hatch according to height or nr of levels or function of the building. Same situation for roads, sidewalks, green areas, which have common borders.
for architecture drawings. walls are made up of several layers finishings insulation etc. in order to hatch, and annotate them for floorplans, they must become closed polylines sorted correctly following the 3d information. Walls are usually interrupted by windows and doors which are made of profiles which have common faces with the walls and with each other, so they must become overlapping polylines as well.
in early stages of building design, rooms are drawn as boxes and arranged into a coherent volume which has to mach the areas needed. in a second stage those boxes must become closed overlapping polylines for more detailed planning.
when creating building elevations from a 3d model. the wall has to be represented with several closed polylines, window frames, the areas of glass with other polylines.
1 Like
Hi Bogdan - thanks, it sounds like some way to create regions within the 2d drawing would be a good thing, but which ones? Should all possible 2d regions created by single objects be returned as closed curves?
For now, you can get the ‘regions’ in your original from CurveBoolean, ComineRegions=No and AllRegions, This is more work, to be sure, but on the other hand you can choose the regions to generate. @GregArden has some ideas about creating regions, it would be good to have an idea exactly how these should work from a users perspective.
Thanks,
-Pascal
All possible 2d regions created by single objects to be returned as closed curves, yes! If an object is behind another its curve should be closed following the profile of the object in front.
Somehow it would be like a silhouette of each object which takes into consideration the objects which are in front.
CurveBoolean doesn’t retain the properties of the initial curves (layers, colors etc), that’s the drawback, everything has to be reorganized. So it doesn’t work on a real scene with many objects.
Hi Bogdan - in the case of your 3-box example, looking at the boxes from the large side, does this mean you’d expect three rectangles (two as 'hidden), one of each color, or one rectangle to account for all three boxes?
-Pascal
From top view, just 3 rectangles. If one box is higher its rectangle could also be brought to front but no hidden lines for the lower ones.
And for 3d it would be like in the image below :
Hi Bogdan - but for a side view, looking straight on at the large side - that is, objects exactly occluded by other objects - would it be best to have a curve per object in this case?
-Pascal
Ah, now i understand your question.
From side view one box covering entirely the other two. To me it seems useful to have one normal rectangle and 2 other rectangles with hidden lines, all of them with the proper color and layer.
Having just 1 rectangle might not be such a big problem, but I have to bump into this to understand fully the situation.
1 Like
Hi Bogdan - Thanks - OK, I guess I get the upshot - all possible closed regions per object. My guess of the moment is that this might be yet another option, at some point in the future… I updated the YouTrack item request to be a little more explicit, though I would not be surprised if there were more questions and corner-cases from the developer.
-Pascal
yes, it could be good to have it as an extra option. I suppose that “all possible closed regions per object” might be more slow to compute. Even if so, better to let the computer do it for 1 hour than a user spending 1 hour trying to find the right polylines to close 