Art V

The threadripper is basically good for heavy duty multi-core capable software (charging a bit here), e.g. rendering software or FEA software that can use multiple cores. For most CAD purposes it is overkill as most CAD software is still single core and serial (except for rendering and a few other functionality things). It would be better to get e.g. an 8-core processor at high clock speed than a threadripper at a lower clock speed. I went from an 8-core i7 to a 4-core single threads i5 (for just a year or two at the most when waiting for the upcoming new supposedly super CPU's) and aside from rendering I hardly noticed a differences with CAD software. So if you don't do a lot of rendering of large models etc. you may want to save quite a bit of money by going with a good 8-core (e.g. Ryzen 7) instead. The RTX A6000 card is basically a Quadro card and in most cases is only beneficial if there are specific drivers for your CAD program available. There are none for Vectorworks. Or if you you are using specific software that would benefit from the functionality of the card even if there are no specific graphics drivers, but then you would not need to ask if you have such software. For Vectorworks a good nVidia GeForce RTX card should be sufficient.

@line-weight you may want to look at this website http://www.northlight-images.co.uk/commercial-photography/training/colour-management/ Keith Cooper has quite a few readable (though also some very technical) articles on colour management and the caveats/use or don't use it etc. that may be of interest.

It depends on the quality of the dyes and the environmental/use conditions etc. but typically they should last at least 5 years without serious issues and maybe a few years more. For critical calibration purposes I'd check against another new/calibrated device approx. every 1 or 2 years if possible (e.g. if you know someone who has a new(er)or recalibrated version of your device). If the differences are large then it is probably time to get a new one. For personal/hobby use it is less critical. In that case you may want to forget about calibration if your purpose is to "make sure" that the colours someone else (random) sees on his/her monitor are similar to what you see. That is not really the purpose of calibration. You need calibration if you want consistency across your publishing workflow of which you are in control or e.g. when you have to send files to a printing service where they use calibrated printers etc. (in that case they would provide you with a profile). What calibration does is creating a translation table that converts/translates the colours of your monitor, printer etc. to a known standard so that on another device calibrated to the same known standard the colours should translate consistently (note that I am saying consistently and not saying accurately because that depends depends on the quality of the calibration (device and process) to a large extent, but that is something else for another discussion, though it should be reasonably accurate as well when using a decent device). It also makes a difference whether you calibrate for sRGB or Adobe RGB, if you calibrate for the latter and it gets viewed on an sRGB monitor some of the colours could be way off. Because you have no way of knowing what someone else equipment and settings are (e.g. brightness turned all the way up, old monitor with faded colours, bad backlighting, manually adjusted RGB values etc.), let alone whether the other side is using calibrated monitors etc., calibrating your monitor with the expectancy of more or less predictable colours on someone else's side is basically a moot excercise. The safest bet would be to set your monitor etc. to use sRGB as most people who don't use calibration are very likely to have a monitor set to sRGB as well using the default sRGB profile. Most non-professional (e.g. office) colour printers are sRGB as well. This is as close as you can get to a predictable colour across multiple devices/monitors as you can get without calibration (with the caveats mentioned earlier). Maybe a bit too much info and a bit too technical but I hope you get the idea of whether it is still useful to calibrate your monitor or not depending on you final purposes.

Another thing to keep in mind is that older colorimeters (e.g. Spyder 2 and probably also 3) are not really suitable for flatscreen/LCD monitors with LED backlight, they will still work for flatscreen/LCD monitors using CRT backlight

For colorimetric devices (e.g. Spyder) this is true as the colour filters contain (organic) dyes that can/do degrade over time. For spectrophotometric devices (e.g. Colormunki Photo/Design by Xrite) this doesn't really apply to the same extent though aging hardware/electronics may cause issues over time as well, but to a lesser extent than colorimetric devices like the Spyder. Though it is possible to (re)calibrate colorimetric devices if needed, the question is whether it is worth the cost vs getting a new colorimeter.

@zoomer (and others) You may want to look at Basiccolor Display for calibrating your monitors, it can work with various display calibration hardware models, including some older ones. https://www.basiccolor.de/products/ The software is available in English and German (it is a German company)

NBC ARENA MASTER v2021-dwg.zip

Not everyone was suffering from it back then esp. on Macs it looked like it wasn't much of an issue, and it is not sure yet if the cause is the same but it looks like it could be. But I agree it is disappointing to have this issue again as it is an aggravating one.

It depends on whether you want/need 3D PDF support (i.e. viewing because VW already can export 3D PDF). If yes then PDF XChange might be worth looking at: https://www.tracker-software.com/ but it runs either on Windows or a Citrix environment, so you would have to run it in a virtual machine on Mac. Otherwise Adobe Acrobat is your only other option for 3D PDFs as far as I know for affordable software plus that it is rental and not a permanent license. Another potential option might be Foxit PDF Editor Pro: https://www.foxit.com/pdf-editor/ According to their website it should be able to convert DWG files to 3D PDF, so it could be that it supports viewing of 3D PDF files as well, will have to look at this myself soon. Currently that feature is Windows only, don't know if it will become available on Mac as well. It 3D PDF support is not required, then PDF Studio Pro might be one to consider: https://www.qoppa.com/pdfstudio/ It is one of the few that are multiplatform and have viewers for iPhone and Android as well and so does Foxit) Bluebeam, Adobe Acrobat and PDF XChange from Tracker Software sees as far as I have been able to find the only options for small and medium business that can handle 3D PDF files. Foxit might also be supporting 3D PDF now, but would have to check by testing its viewer/editor. Otherwise you will have to look for corporate/enterprise level kind of software. Or wait until Bluebeam comes up with its cloud option.

The problem was very bad in VW2019 and then improved over various SP's in VW2020 to become usable again. It would be a bit disappointing if the issue returned with VW 2021 SP3. What happens if you disable Master Snap but leave one of the "normal" snaps that is the most useful for you on? I do remember there being an issue with Master Snap on, but don't remember if it was also affecting this particular issue, but turning the Master Snap off made an improvement in speed as well.

Another thing you can try is to disable all snaps in the snapping palette before selecting and moving, that way it won't have to spend time trying to locate a snap in a crowded selection/drawing. I had this issue with earlier VW versions as well and one of the things that would speed this up was disabling layer with geometry that is not needed for moving and disabling all snaps.

The World Imagery server should be able to provide higher resolution images. Another option could be to use QGIS or GlobalMapper to retrieve geoimages, these can provide higher resolution images for small(er) areas as well, at least considerably higher than Geoimage currently seems to be able to. It seems to max out at a resolution of roughly 2000 for smaller areas with not that much detail if you need to zoom in at e.g. a neighbourhood. My guess is that this might be a licensing limitation because of the deal between VW and ArcGIS and you may need to get a paid subscription to some of the ArcGIS services to get a higher resolution. Though some of these free geoimage servers that QGIS/Global Mapper are using are basically the same as from Google and ArcGIS free image servers, so they may not be the most up to date images for higher resolutions. Though if you have the server address it should also work from within Geoimage. You may also want to look if there are public (i.e. funded by national/local authorities) image servers that provide geoimages (and other data). These may also be able to provide higher resolution images. The downside is that you won't have live images and may have to download a new image after a while if there are updates to the area.

It just means that a full save takes more time (though with smal(ler) files you may not notice), the more "wasted space" you allow (a higher save percent value) the longer it takes to do a full save. It will basically save only the new objects while leaving the old unchanged stuff alone, i.e. an incremental save until the percentage of wasted spaced reaches the value in the save percent setting then it will do a full save and remove the wasted space and reduce your file size. This is what makes saving files a bit faster. Setting save percent value to 0 (zero) will cause BricsCAD to always do a full save.

If you can't open the working file then I wouldn't worry about replacing it with the backup file, it works the same as with Vectorworks in that case where I also replace the damaged file with the most recent working backup file.. What I usually do is delete the damaged file and then rename the *.bak to *.dwg, or do that to a copy of the *.bak file in case you want to keep the *bak file just in case.

No, not really, if it does then it is more a side effect. What does affect saving speed is setting the save percent variable to a larger value so that more wasted space is allowed before it does a full save (which takes longer). The downside is that the file size may become a bit larger. Recover updates (or replaces) the existing file so in a way yes. Though I never really bothered to find out exact inner workings of recover vs audit as long as it fixes the file well enough.

This is what I usually do as well, as there is no point in doing all the work again if it is in the backup file. The only issue I have with VW backup files is that it is not so easy to check data in records compared to the previously saved version, it is far easier to see if geometry is still there than it is to check e.g. record data updates still being there or not. It would be nice if VW would have a standard drawing comparison tool that would show the differences so that you can see if certain data updates are in the most recent backup file or not. (As well as other updates of course).

Bricscad has two types of backup files, the *.bak which are created upon saving the current file and creates a file that is a backup of the version saved before the current manual save operation, this is similar to the VW backup on save. Then there are the *.sv$ backups which are the autosave files, similar to VW automatic backups/saves and keeping x number of backups except that Briscad does not have a number limit and those are by default stored in the temp folder but you can specify a specific directory if you would like to keep the autosave files in case of a crash so that you can use the most recent autosave as a starting point instead of the perhaps much older *.bak file. Recover is used for when you cannot open the file in a normal way, audit can be used when you can open the file but is may have errors in it. In most cases they are doing practically the same thing. Audit and recover can delete corrupted/invalid (crappy) geometry if it is there, but more often it fixes the internal file database structure by e.g. cleaning up object ID's of deleted objects etc. that are still floating around. I like VW's autosave and keep x number of backups better also because you can have it save into a subfolder of your working folder so that the autosaves are kept with the project and not have all projects lumped together as Bricscad does by default.

Illustrator's import used to be mediocre at best with curve import being quite messy at times, CorelDRAW did a much better job in the past and still does a good job importing DWG files so I use CorelDRAW for importing DWG files. Because I haven't used Illustrator for years now I can't comment on the current quality of Illustrator's DWG import but you could try using CorelDRAW to see if it does a better job. There used to be a macro for CorelDRAW to export files for CNC use, but I'd have to look up if it is still current. Another option could be exporting as R13 DXF and open the file in e.g. Inkscape to see if that gives a better result. Exporting from AutoCAD to Illustrator is probably exporting to EPS, which has its limitations. It is better to open the DWG in CorelDRAW or to export to DXF R13 (or 12) and then open in a graphics program other than Illustrator.

This is one of those things that happens in the DWG world as well if components of a symbol/block have defined layers etc. That is why DWG has the layer 0 (zero) for blocks, any block that is completely created on layer 0 with properties set to bylayer will take on the properties of the insertion layer. Hard defined linetypes (e.g. dashed line) will be kept, as long as it is all on layer 0. VW should have something similar for standard symbols, that could save a lot of dealing with predefined classes that one doesn't want anyway because of company, client or even project standards. Especially when working on a multinational project where local standards use different class/layer names (e.g. local language names) and things are defined at the project level to keep everyone using the same naming system. Symbols can often be the same, but class/layer naming can as often be different.

This is a bit baffling, why should a section viewport hold an object (and its related layer/class) captive when deleting a class. The normal class deletion procedure should have priority over a section viewport and the section viewport should update accordingly to the choice made when deleting a class (as per second dialog above). This could mean that objects will be removed from the section view if the new class is not included in that viewport or deleted together with the classe but that is a choice the user should make, not VW.

It would be nice if there could be a setting that would fix screen plane to sheet layers only so that design layers would always be in layer plane. There can be use for screen plane on design layers in specific situations but it does have its restrictions compared to layer plane if you are also used to other CAD software.

In theory text should import with the same alignment as in the DWG file, but... it could be that the UCS (= VW user origin) of the drawing was mirrored relative to the WCS (= VW Internal Origin) and Vectorworks does seem to use the WCS upon importing (it used to be that way as I found out with strange imports and noticed the UCS was not aligned with the WCS, not 100% sure if that is still the case so I would have to test that). This might cause the text orientation to be a mirrored upon import, just a guess for what might be the possible cause. Or the drawing was mirrored in the DWG file and VW is still using the original text direction of the text blocks, which might be another possibility, assuming it only happens with that one DWG file. There are lots of ways to mess up a DWG based drawing from a drafting perspective while still making it look ok. 😁 The downside is that when importing it into other software it may cause a bit (or a lot) of a mess with some (or a lot of) things.

True, plus that it is free which means it can be used for sharing GIS info with those who cannot afford ArcGIS. It is probably also the most ArcGIS comparable program of the GIS applications in the sense that a lot of basic things work in a similar way. I use QGIS, Global Mapper and BricsCAD with Spatial Manager (the latter has a standalone desktop version as well, besides Acad and other CAD plugins) as well as Vectorworks Landscape for GIS projects and at clients office ArcGIS if I am on their systems. Both QGIS and Global Mapper can open the ArcGIS geodatabase files etc. without much trouble and then use them for extracting/exporting data usable for Vectorworks. Data exchange from Vectorworks with ArcGIS and v.v. through shapefiles has never been a major issue in all these years. So I am a bit curious what it is regarding the use of Esri products in relation to Vectorworks that is the area of interest. Is it connectivity to e.g. ArcGIS online, direct import of geodatabase files, something else?

From a Mac perspective it looks like a good upgrade compared to your current system. However... because of the Cinebench test above I did a Cinebench on my Ryzen 7 2700X (2018) system and for single core it beats my system but not for multicore performance. When looking at the current (late 2020/early 2021) processors I'm not convinced that for power users the M1 is the best option for upgrading, especially if you have a more recent system, because it is "just" some 10% faster for single core performance and some 15% slower for multicore performance compared to Intel/Ryzen CPU's, unless you cannot wait. If you can wait then like @zoomer I'd suggest to wait for the next M-chip (M2?) to see how that turns out.

I agree with @jeff prince that Rhino is probably the best bang for the buck for complex surfaces. Rhino combined with the Xnurbs plugin might be an ever better solution as it will generate such surfaces that are in multiple directions more easily than doing it manually. Though there are surfaces possible where you have to make manual corrections anyway.