VA3 Beta - VaExportToDwg - User review & feature wish

Hello,

vaEportToDwg should transfer everything inside layout view to .dwg. Here I summarise the state of the art of this promising feature from the user’s point of view.

A main reason for exporting VA geometry from layouts via this command is when exchanging CAD data with other professionals or team members. This happens multiple times per project development, and it needs to be as swift and reliable as possible, ideally without additional 2D editing necessity.

At first glance, I expected vaEportToDwg would export every part of geometry, as seen in layout - (from detail view and also from layout space inside page borders), directly to .dwg model space, but it is not a case. Instead, it takes geometry from Rhino model space and puts it into .dwg model space and also take geometry and annotations from layout space and puts them into .dwg layout (paper) space.

It is not what I expected, but fair enough. To get everything into .dwg model space I can use AutoCAD command CHSPACE, which pushes everyhing from .dwg layout (paper) space into model space, preserving scale (mostly used for annotation objects) . Again - it is a workaround and must be done on every layout separately, but at least it can be done…

I was quite happy with the new workflow as described above. But after a few test vaEportToDwg command executions, something went wrong. All new exports from my model end with misaligned .dwg detail and model space. I tested again on another model an it was not a case - so there must be some uniqe situation bug… I am sending you an email with files to investigate and lets move on to my other findings:

Other remarks:

  • The thing I dont understand is the logic behind geometry placement in .dwg model space:

    • While exporting multiple layouts at once, their model space geometry is stacked verticaly with pretty big spaces between drawings and 0,0,0 (around 10000mm) - it could get a bit confusing to navigate. Also, some kind of annotation or title (perhaps derived from layout name) could be placed near the model space geometry, so It would be a bit easier to navigate.
      Example image - export of three simple Rhino layouts as seen in .dwg model space. It would be much better, if they were placed closer to 0,0,0 and to each other and distributed not vertically but horizontally - from left to right, as we use to read.

    • While exporting a single layout, it also gets placed around 10000 mm above 0,0,0. What is this good for?

  • There are two default Layouts included in every .dwg created with vaEportToDwg. They are a bit confusing and ugly - can we get rid of them?
    image

  • vaEportToDwg ignores “Detail Off” state of Layer. Dont get me wrong - layers are indeed correctly exported to .dwg detail view on layout with the correct layer states. But for whatever reason, the hidden layers are included and present in .dwg model space! Can You change that? Hidden shoud remain hidden :). This could scale to an insane level of additional 2D cadwork, if working with multiple hidden layers (which is Rhino 3D model full of) and when exporting multiple layouts at once (as vaEportToDwg is intended to function). Because in this scenario, different combinations of layer states for different layouts are not respected and would colide if the result should, at the end of the day, appear nice and clean in model space. (Again with a bit of help from ACADs CHSPACE

    To say it differently - when I set up my Rhino layout design, I want no other geometry to be included in any export of this layout at any time. Makes sense?

    Example image - pay attention to the blue text in the middle of the groundplan, which is on layer with “detail off” state:

  • If a part of VA geometry - Wall, for instance - goes beyond Detail border:


    vaEportToDwg exports it without hatch:

2 Likes

Hi @MichalKrizo thanks for this useful feedback on the vaExportToDWG feature.

Is that what you expected how you wish this command worked? I mean, why would you like to have what lies in the Rhino Layout space as 2D geometry in the “.dwg model space”?
Wouldn’t it be controversial to mix all the geometry you have in Rhino in two spaces (model and layout) into one “.dwg model space”?

The goal of this feature is also to keep the page layout in the dwg as similar as possible as you have it in Rhino. But just converting the 3D geometry you have in the layout details into 2D geometry in the AutoCAD model space.

In any case, we could consider adding a setting to that command and ask the user how to export the geometry. So we could include the option to export everything visible in the Rhino layout to the .dwg model space. In that case, would would you expect to find in the dwg layout space? any geometry at all? or just the layout with the “detail” views to the model space where you have everything that was visible in the Rhino layout?

We fixed a bug related to a wrong export of some files (the results were rotated) in the next update. I suspect you are experiencing the same problem. If you have a model to test this I can tell you if it’s the same problem or not.

That was the way to make this feature possible. We could change the arrangement of the 2D geometry in each layout to a horizontal distribution (instead of a vertical distribution), or let the user control the separation between each set. (I add your vote for the change to a horizontal distribution). This separation is now calculated automatically to ensure the drawing sets in each detail don’t overlap each other in the model space.

I think the first set of drawings is meant to be placed on the 0,0,0. We will revise this.

I’m not sure if we can avoid creating these layouts. I think AutoCAD generates them. For example, if you save a Rhino model to DWG, even if you had no layouts in the Rhino file, you see these two layouts in AutoCAD when you open the DWG file.

I cannot reproduce this error. If you have any sample file to test, it will be a great help. Of course I also agree that VisualARQ should export only the visible geometry in the page layouts.

This whole topic is so riddled with quirks and problems, it’s mind boggling. Excuse me saying this, but it’s true. It’s hard to know where to start.

Let’s start with this:
Apps like Revit or Archicad, who are damn good at 2D graphics (especially Archicad, believe me) have a strict separation between 3D space and it’s (automatic) 2D projections (floorplans, elevations, …), in which all the necessary 2D work needs to be done. They have a 3 step approach: 3D model space → automatic 2D projection space → layout composition space.

Rhino/Autocad only have 3D model → layout space, and like AutoCAD, it allows for 2D graphics (text, annotation etc.) in model space AND layout space. It does so because it copied the old concept of model / layout space from Autocad, which did it like this since the time when CAD only meant 2D CAD.

Although Autocad is capable of 3D, very few people use it for that (ugh!). Working in Autocad normally still means drawing in 2D. Thus, it does not make much difference if you annotate in model or paper space. It also happens often that Autocad people print directly from model space, which is perfectly possible.
Thus, people expect DWGs to show up nicely in model space, annotations, hatches, text and all.

Rhino, however, shines at 3D. This raises a complex problem: how to derive good 2D projections out of your 3D data, and - where to put this 2D data?

You Visualarq guys, of all people, should know about all the complexities.
There are a few ways to go about this.

  1. Put vaPlan/SectionViews into model space - but where there?
    Disadvantages:
  • The moment you move them side-by-side, you loose the absolute coordinate relation.
  • The scene quickly becomes cluttered with all sorts of 2D garbage flying around, and keeping layers logical becomes a challenge.
  • The 3D>2D projection engine is not yet capable of creating hatches, nor hidden lines (PLEASE do something about this!)
  1. Use ChangeSpace to put vaPlan/SectionViews into layout space.
    Advantages:
  • Clean model space.
  • vaPlanViews even have a Scale parameter. However, for vaSectionViews, the Scale parameter is missing. Could you please add one? Thanks!
    Disadvantages:
  • Dimensioning the vaPlan/SectionViews won’t show the correct measurements, and also, no good ‘Make 2D’.
  1. Use Detail views in layout space to look into the model space. (Your preferred option)
    Advantages:
  • Clean model space.
  • Annotations in layout space ‘see’ the correct measurements.
  • Shaded/textured objects
    Disadvantages:
  • Does not translate well into 2D DWG!

Here’s a layout space screenshot of a simple test scene.
Rhino:

Sounds good.
After vaExportToDWG, this is the result in Autocad:

  • 3D objects did not come across.
  • Viewports were converted to bitmaps - that’s unsportsmanlike! The floorplan kind of works, the 3D viewport is garbage.
  • Interestingly, the layout space annotations show a value (mm, but without scaling, no wonder).

What’s the conclusion… Rhino needs:

  • a modern, parametric 3D-2D projection engine (like Archicad), which produces hidden lines, hatches, vector drop shadows, section styles… The new Section Tools are only halfway there. I’m not too happy with them.
  • an additional 2D space, like the BIM apps have, to host all things 2D related.

Both are huge and expensive features, development-wise. But without, we will run in circles and never really get to a satisfying drafting solution.
My opinion. Thanks for reading!

5 Likes

i absolutely could sign under this. Eugen is an obvious pro and knows what he is talking about. I wrote down my doubts in this topic with same conclusions Technical vector print is bogus

1 Like

from what i have read on forum about this i believe everybody who demanded this feature thought the same …

1 Like

@Eugen thanks for your valuable contribution to this discussion!

If it does not make much difference to annotate in model or paper space in AutoCAD, does it really matter if VA exports what there is in the layout space to the layout or the model space in AutoCAD? It seems logical to me to preserve the model/layout space where objects are exported in the dwg file, but we can change that behavior if most people prefer to have everything in the model space.

We are currently revising some issues with the vaExportToDWG command. The one of “3D objects did not come across” may happen due to an error where 2D geometry of these objects is rotated in the model space and generated outside of the detail boundaries in the AutoCAD Layout. If you go to the Model space you may find that geometry. We will fix this problem in the next update.

Please notice that only detail views in Hidden display mode are meant to be exported correctly to DWG as 2D geometry. The details in other display modes (rendered, shaded, etc.) will be exported as bitmaps. I can see it’s not working well in your case, seeing your screenshots, so if you can share that file we will take a look.

Please share that file so we can take a look at this issue as well.

All right, but I’d like to understand why. If someone created texts or dimensions in the Rhino layout space, why would they prefer to have them in the model space in AutoCAD?
(If they create them in the Rhino model space, they will get them also in the AutoCAD model space)

Sure, I forgot. Here it is.
test VA floorplan in layout.3dm (386.0 KB)

@fsalla
To me, the vaExportToDWG tool would be valuable, if it truly exported the Layout view WYSIWYG to Model space DWG. Fully automated, and no intermediate geometry generated in Rhino. Just type-of “save as…”.

Reasoning:
Even though the views derived from 3D objects are extremely useful in creating a proper PDF drawing set, in AEC everything is still required as DWG as well. DWG is used as a QA-tool, where the receiver can easily check an individual measurement, detail, etc… that is not present or visible in the PDF. So, even if the PDF is used to convey information, the additional DWG is still needed, or at least good to have.

Currently, it is actually quite difficult to derive 2D-DWG from the basically 3D-object views. If it would work well, I could see myself even re-importing vector PDF’s back to Rhino in order to get a matching DWG. And the need to have PDF+DWG set is currenty easier by generating 2D-drawings. It’s not so eloquent, and a bit more work, but requires less work in sending out documentation.

Properly functioning Layout-DWG export would change this completely, so I would not need to consider the difficulties of post-generating 2D-DWG. I could just rely on the fact that the tool would function as needed.

PS.
And for me per Layout to DWG would be sufficient. If needed, I could easilty compile the DWG’s to a single file. KISS, I would say.

2 Likes

Because in Autocad, people tend to draw everything in model space.
Layout space is used solely to, well, layout. Title block, plus viewports that show a part of the model space. Nobody does annotations, text, etc. in paper space there, because everything is 2D. Often, xrefs are also used to collect and present a bunch of those 2D plans in paper space.

In Rhino, we have the predicament that the model space can be a 3D as well as a 2D space, freely mixed, if one likes it so. But where should annotations/text/etc. be put in Rhino? Serious question. There are only 2 options, model or layout, and both have advantages and disadvantages.
Put documenation in model space, and the cluttering begins, and quickly leads to chaos, if you don’t keep the strictest of discipline. And since there are no real standards for anything in Rhino, it will be necessary to communicate your (even maybe well thought out) layer order. And believe me, the next Rhino guy will probably not be willing or interested in keeping the same order.

If you put the 2D documentation in layout space to keep the model space tidy, and export this as DWG, then, on the other hand, the Autocad guys (external professionals, mostly) will wonder who had the bright idea to put them into paper space…

We are talking about a mixed pipeline, of course, which is the reality.

It’s an unsolvable riddle, until McNeel and you start thinking about a better solution, and introduce a new 2D space, next to layout space. This extra space would host the automatic projections, plus any documentation.
Just like the BIM apps do it.

Will you, maybe for a minute, give this a thought? I’m well aware that this runs deep into the guts of Rhino, and McNeel would need to be convinced.

As a compromise, bringing layout space to model space in the DWG export, would be of great help.

1 Like

I fully agree with @Toni_Osterlund.
For most of our production partners, and even for our internal workflows, it is very important to have a fast and reliable option to convert all our output data (finalized layouts) into ‘flat’ (i.e., model space only) .dwg files.

When we need to send an editable version of a project to our contractors, a model space-only .dwg offers several advantages:

  • It is easy and fast to read (navigating between a large number of layouts in .dwg can be cumbersome).
  • It minimizes the chance of human error (different annotations distributed among layouts can be easily missed or overlooked).
  • The entire project can be understood within seconds of zooming and panning.
  • Editing is straightforward (we often exchange multiple .dwg files with contractors, making quick sketches and iterations before applying changes to our BIM model).
  • It is great for archiving purposes, providing a quick snapshot of a project’s current state with everything captured and nothing hidden in different spaces.

I also fully agree with @Eugen regarding the urgent need for a separate 2D space in Rhino, similar to what Archicad or Revit offer. This is closely related to our discussion about vaExportToDwg, but it opens up many other topics (and years of development). To keep it simple, vaExportToDwg with “model space only” option will be more than enought for now :wink:

3 Likes

VisualArqers, please listen to Michal and Toni!

If you do, it will bring us to the problem of back-projecting 3D geometry to 2D. Something you already provide for many years, in the form of vaPlan/Section view.
However, this projection engine, as you know and as mentioned, lacks a few important features - hatches, editable text/annotations, drop shadows…
Archicad does all this. Sketchup even supports auto-converting textured surfaces to background bitmaps in it’s projection engine.

If you just rely on your trick of rendering out a detail view as bitmap if it’s not in Hidden display mode, people who read the DWG will get only that - a bitmap, instead of a precise, usable 2D CAD plan. (Besides, in Autocad, the viewport background is traditionally dark, and embedded bitmaps stick out extra ugly).

This is the second big missing feature that should be tackled, better sooner than later. It’s 2024.
Thanks!

3 Likes

@MichalKrizo @Eugen @Toni_Osterlund thanks for your feedback!

Just a question: Imagine a page layout in Rhino with two detail views, each one in different scales. And we put all together in the DWG model space after we export it to DWG. Each drawing will have a different scale in the DWG model space. So you won’t be able to dimension that. Is that what you prefer?

Frances, apparently you haven’t seen many civil projects, have you? :wink:
Cheers, Jaro

@fsalla
I think you are correct in your thinking that there is and will be complexity that is not readily solvable with a single universal solution. Different methods of working, etc…

Generally, I would be as happy as a clam if it would work like Print. I would get WYSIWYG PDF and DWG out, with selectable output ‘scale’ (comparable to page size in PDF print). This would solve 99% of my use cases.

1 Like

In Autocad, dimenstions can have a scale parameter. The Rhino detail scale could translate to that.

@Eugen
It’s always a bit risky to mess with the dimension text override. It’s hard to spot.

I completely agree. I tried developing a few other solutions but quickly ran into complex problems. This one should do the trick :).

This sounds like you are not concerned about the scale of the 2D drawings that will open in AutoCAD, am I wrong? You wouldn’t be able to measure these drawings in AutoCAD if they come with no dimensions.

@fsalla
This depends on the use case. Generally speaking, everything should be 1:1 on Model space.
Currently, I have 2D drawings in Model space 1:1, and Layout Detail determines the scaling factor.

If I would have the option to determine the DWG export output scale, this would solve that. ie. print to 1:50, the exported DWG would be scaled 50:1. However, it is not a drastic step for one to manually scale the outputs, if needed.

And I would not put any weight to the issue with different Detail scales on one Layout. Those cases are rare, and more for presentation purposes, I would say.

2 Likes