Nina Ivanova

Anonymous block inside AutoCAD can be copy-pasted, thus creating more instances, but you can not insert it as you do with the named blocks and you can not edit its "definition". The only way to edit such an instance is to "explode" it and do the necessary changes. No way to change in one step all the instances. This is close to Vectorworks groups, so that is why we convert them to groups. There is no need to have an import option for this conversion.

Zoomer, An error appears during the DWG import when we try to scale the solid. So scaling is actually not done. The same error appears when trying to scale the solid from the OIP. This is something, which needs to be looked at by an appropriate engineer. I will enter a bug report. BTW, by now I have not seen a problem on import of solids when they are placed inside scaled symbols. It is normal to have solids inside blocks and it is normal to scale the blocks. So that is why I was curious to read about such a problem. Now I saw the reason - your scaled blocks are anonymous. This means, that on import we will convert them to Vectorworks groups (this is the correct workflow) and will scale all the objects in the group appropriately. If your solids were in a normal, named DWG scaled block, we would create a symbol instance, which would be scaled appropriately and all the solids would look perfectly. I did this test: just did a simple modification inside AutoCAD placing the solids in a non-anonymous block and after importing in Vectorworks everything was correct. Thank you, Nina

The error message is wrong. This problem was fixed for VW2017 SP4, so more likely in this case used Vectorworks version is VW2016. This error message would appear in case that DWG file version is newer than the one supported by current Vectorworks. In Vectorworks 2017 you will still be able to see the error message for DWG file version 2018, and it will be "This DWG version is a 2018 version. You can only import DWG up to version 2017.". In Vectorwork 2018 you should not see this error, as DWG version 2018 is already supported. If you do not have other way to check the DWG file version, use a standard text editor to open the DWG file. If this is a DWG file version 2018, the first thing on the first line should be AC1032.

Only some of the Solids are affected. Part of the walls, floors and other elements, which are also Solids, are positioned correctly. Windows and doors are blocks, but they are also composed by Solids. I entered this bug report: https://jira.vectorworks.net/browse/VB-146582. I will let the appropriate engineers to know about the scaled blocks issue, which you described above. Thanks, Nina

Thank you for the file, Zoomer! Yes, I was able to see the problem when units are set to Meters. Appears it is somehow related to the Solid objects boxes, which are too big in this case. I am still researching what exactly happens, but will enter a bug report and will assign it to the appropriate engineer. Thank you, Nina

Zoomer, I am not sure what exactly could cause some of the Solid objects to be positioned wrongly, but could check this if you send the the DWG file. What I see from the images above is that both imports - wrong and proper one - are done in documents with same units - for the correct import ruler shows, that the graphics is between x= -2500 and x= 12500, which is comparable to the wrongly imported graphics. As Art V mentioned, DWG files does not have units - you can choose in AutoCAD, that block insertions will be done using meters, but this does not mean, that the graphics is in meters at all. However this units setting is the only thing, which Vectorworks could use to guess what are the DWG drawing units. So, we might show in the Import Options dialog, that Automatically determined units are meters, but this might not be the case at all. The best case is to know from the DWG creator what is his/her drawing units and use them directly. In some cases DWG files are set to Unitless and then prediction of the units is nearly impossible. Internally solid objects (ACIS data) are always described in millimeters, so there is no direct meter-to-meter support. It is possible that during millimeters-to-meters conversion position is somehow calculated improperly, but in my opinion this is not likely to happen, except if the original drawing is not far away the UCS origin. It appears to me, that some graphics is just flipped - which might be related to the import of flipped blocks. Have you tried using "2D and 3D" import option? Is it possible that you have used All 3D import option for the wrong import and "2D and 3D" import option for the correct import? I would recommend using 2D and 3D import option even for the 3D graphics. Please, attach the DWG file or send it directly to me at nivanova@vectorworks.net. Thank you, Nina

Hello Joey, The line weight was already explained by Art V and I agree, that this is related to used line thickness in the VW document and the scale of the exported graphics. As I see from the export DWF, page size is 11.5 x 8.5 in, but the drawing is too small for it. As it is seen from the export options dialog, you are using "Export Viewports as 2D Graphics in Model Space". On export as 2D graphics in Model space drawing size is set to the drawing extents and as the extents are given for some reason in this way, the line weight with fixed big value looks so thick. I would suggest you to set the "Export Viewports as 2D Graphics in Model Space" to OFF and export to DWF version 6.0 - in this way your original sheet layer size will be retained, graphics will be exported with the correct size and line wight should look OK. In my opinion when exporting to DWF it is not necessary to export as 2D graphics as the export to DWF itself will do this anyway. DWF export supports export of images and PDFs. We have had issues with image export to DWF when image, file or folder path contain special chars. If there is a problem on export of these objects at your end, try to use image and file names without special or Hebrew chars and to export to a folder, which does not contain such chars too. If this helps, please write to me. Regarding the imported in Vectorworks PDFs - there is a bug when you export with "Export Viewports as 2D Graphics in Model Space" set to ON, but PDF will export fine if the option is set to OFF. This bug will be fixed. Flipped text on export to DWF is a known issue, which does not have an easy solution. Vectorworks have a way to show the text properly, calculating the proper direction during the process of drawing the text. In the DWG, DWF and DXF file formats text needs to be saved in the proper direction, ready for direct use by the AutoDesk products, as they do not have the ability to do this on draw time, based on an option as this is in Vectorworks. True inside AutoCAD one could choose to mirror the text while he/she is creating it, but once created, text can not be auto-adjusted. To avoid this issue we do the necessary calculations and apply them on export, but in some cases it is not possible - like when text is inside flipped symbols or when differently rotated or mirrored viewports are used to show same design layer graphics. Please, send some example VW documents directly to me (nivanova@vectorworks.net), so I can analyze your problems in deep. Thank you, Nina

Hello Joey, Would you, please, send more info and examples about what exactly does not work when you export DWF files from Vectorworks? Thank you, Nina

Hello Patrick, Would you, please, attach your 2017 template file, so that we could look at the problem? Thank you, Nina

Hello Jim, Please, enter a bug with more details and images. Thank you, Nina

Hello Innes, Thank you for the file! We analyzed the problem and can confirm, that for this example document created by VW2014 DWG file size is smaller that the one, created by VW2017. VW2014 creates a DWG with size 8Mb, while created by VW2017 file size is 24Mb. This is because of the additional blocks, created in order to better control the viewports visibility and object attributes. For this exact document there might be a way to optimize the export. We will log a bug report for this issue and will work on the optimizations. Thank you for reporting, Nina

Hello Innes, Would you, please, add a bug report or send the document and the export settings you are using so that we could analyze the problem?

Does the "internal error" message appear always you try to export a document to DWG, or it happens for a specific document? If it happens for a specific document, would you, please, send it directly to me? Thanks, Nina Ivanova nivanova@nemetschek.bg

This one sounds as a bug, which is reported as fixed for the next version. A workaround in this case is to convert the title block to group and to export (also better to do this in a copy file) Nina Ivanova

Ziska, Would you, please, send the DWG file you are importing to me? Thank you, Nina Ivanova nivanova@nemetschek.bg Software Development Nemetschek

Sean, VW12.0 exports more that 1 sheet layer at a time. You can export the current sheet layer only (as it is in VW11.5), selected sheets or all the sheets. Best Regards, Nina Ivanova Software Development Nemetschek

Jason, I just emailed you the corrected VW12 file - there was a problem with layers view setting, which is probably due to the previous transitions - BP to MC or MC to VW12. All the exported objects are on their right places after the correction. Thanks for the files, Nina

Jason, Would you, please, send the VectorWorks document, which you export to DWG, to me: nivanova@nemetschek.bg Confidentiality is guaranteed. Thank you, Nina Ivanova Software Development Nemetschek

Ramon, There is a strange problem with cropped SVPs, which prevent presenting info in AutoCAD. As a workaround I will suggest you to remove the cropping objects and to export again - your info should be converted correctly. I added a bug report concerning this issue. Thank you for the file, Ramon, and sorry for inconvinience. Best Regards, Nina Ivanova Software Development Nemetschek

Ramon, Thank you for the DWG and for the picture! I was able to open your DWG without problems in AutoCAD 2002 and can confirm that all the doors and windows are at their right positions and have proper rotation. Nina Ivanova Software Development Nemetschek

All the door and window PIOs have to be exported at their proper location and rotation. If you see some PIOs, which are not exporting correctly, please send the .mcd document and your export settings to me: nivanova@nemetschek.bg Thank you, Nina Ivanova Software Development Nemetschek

You have to convert rendered viewports to groups. Then you could export to DWG. Nina Ivanova Software Development Nemetschek

When exporting from a sheet layer Design Layers are not rescaled - as a result 11.5 exported some of the hatches with wrong scale. This problem was fixed in 12.0, but if you are using VW12 and you still see it, then please send the mcd document directly to me. If you are using an earlier version, there is a workaround - at first save your VW doc using different name to avoid undesirable problems in the original drawing, check what is the viewport's scale on the sheet layer which you want to export, then go and edit each Hatch definition - set the hatch scale factor same as the viewport's scale (use Apply to All Levels). After this change document should be exported correctly. HTH Nina Ivanova Software Development Nemetschek nivanova@nemetschek.bg

If you are not using VW12.0: Import files in different VW documents and after that use Workgroup References. If you are using VW12.0 - simply make sure that the "Center After Import" option in DXF/DWG Import Options Dialog is unchecked. HTH Regards, Nina Ivanova

Tom, Thanks for the files - they really cleared the situation. As I understand, you export from VW, import the DXF in Rhino, do something there, export it as DXF and after that import the resultant file in VW. This is very long way hence there are multiple places where things could go wrong. Your original .mcd document uses Feet&Inches and when you export it as a DWG/DXF, your AutoCAD drawing will be in Inches. If you now import back just exported DXF in a blank document with units set to Feet&Inches, you will see in the Import option dialog that Model Space Units in the file are Inches - check that Determine Automatically shows: 1 DXF Unit = 1". Finish import and compare both original document and just imported document - you will see that both docs are identical: - Objects are with same sizes; - Line Style applied to 2 of the objects in the original document is preserved and corresponding imported objects are drawn with proper line style; - There is no missing objects; - Notice the high quality of the imported objects. I opened in AutoCAD the DXF file which you have exported from Rhino and checked for Units - they are set to millimeters - your drawing is already approx. 160mm x 320mm in size (compared to 160" x 320" in the original file). This change could happen on Rhino dxf import, on Rhino dxf export, or inside Rhino. I also noticed these changes: - Line Style is lost; - Quality of the Oval object is lost; - Some objects use Color 255, which is seen inside AutoCAD as White on black background and as Light-gray on white background (instead of Color White). If you now import in VW the Rhino's DXF in a blank document with units set to Feet&Inches in the Import options dialog you will see: Units Setting In File: Millimeters Determine Automatically: 25.4 DXF Units = 1". If you confirm these settings, your 160mm x 320mm drawing will become approx. 6" x 12" which is absolutely correct. VW can help you to receive your drawing in its original size: Knowing that the dxf has been saved by Rhino in millimeters instead of inches in the Import options dialog you could change Units: Determine Automatically to Inches - in this way you will have 1 DXF Unit = 1". Import and see that the size is same as in the original file. Note also that there is no missing objects - there are some objects drawn with White color - VW always import Color 255 to White and exports White to Color 255. You could use Set Colors to Black and White import option to check that all the objects are imported. HTH Best regards, Nina Ivanova Software Development Nemetschek