PVA - Admin

It looks like the fix wasn't complete in time to make SP2, but it is marked as fixed in SP3. It may also appear as VB-156040, a duplicate filing of the same issue.

Discussion related to this SP can be found here:

You should now be good to go, let me know if it gives you any further trouble after restarting and launching the application again.

It sometimes takes a bit to propagate to all locations. It should either pop up automatically on it's own or show up after running Check for Updates a few minutes after this post.

Nearly 800 bugs were fixed in 2019 SP2 overall, the above is a summary of only issues that were corrected between 2019 SP1 and 2019 SP2. If you have any specific issues that you do not see here that you would like to know the status of, please let me know or link me to the bug and I will attempt to track it down for you.

Below is a summary of issues corrected and changes made between Vectorworks 2019 SP1 and Vectorworks 2019 SP2. A full list of all fixed issues listed with their bug IDs can be found HERE. General: Sheet Layers - Extensive quality improvements to appearance when switching layers Multiple Drawing View - Significantly increased redraw speed in certain configurations Attribute Mapping - Increased stability Hybrid Objects - Improvements to stability and quality of Generate 2D from 3D results PDFs - Improvements to ungroup results, speed, importing PDFs from server locations, and migration from previous VWX formats PDFs - Image Effects should now properly export to PDF in all cases Sketch - Viewports should now properly display Sketch results in Foreground Render Resource Manager - Multiple fixes related to graphics and redraw after the palette is moved or resized Title Block Manager - Corrected a problem where the wrong Active File could be shown Viewports - Fixed an issue where Layer Opacity would not appear as expected Viewports - Fixed an issue where viewport scaling did not properly affect all contained text Viewports - Corrected a problem that could stop Black and White Only from affecting Annotations Undo - Extensive fixes related to application stability after performing various Undo-related operations Image Effects - Corrected an issue that caused Preview not to function on certain hardware Class Overrides - Corrected a problem where some wall component overrides did not always show properly in Best Performance graphics mode Data Tags - Extensive fixes to visibilities, linking, viewport interaction, and display of tag geometry Data Tags - Should now properly pick up pop-up data fields Data Tags - Should now see IFC Entity values as expected Offset Duplications should now work as expected in 3D views Title Block - When the stacking order of sheets is changed, the order should now update automatically Title Block - Conversions from 2018 should now include all text fields Title Block - Corrected a problem where editing a title block was unusually slow in some files Layer and Class Filtering - Filter button should no longer require multiple clicks to alter its state Fillet - Corrected a problem related to Best Performance graphics mode not displaying Fillets Xray Mode - Corrected a problem where the OIP would accept B key input erroneously Object Info - Fixed a problem that could cause the OIP to become unresponsive until closed and reopened Images - Cropped images should now display cropped as expected after being moved or copy/pasted from another locations Workspaces - Creating a new workspace from scratch should now include Object Context Menu Selection Highlighting - Should no longer flash during viewport renderings Import 3DS - Fixed a stability issue related to importing older 3DS files Stipple Tool - Increased responsiveness Rendering: Renderworks Backgrounds - Corrected a problem where RW backgrounds would not appear in viewports OpenGL - Line thicknesses should now appear in OpenGL as they do in Wireframe OpenGL - Textures should now display as expected in OpenGL when viewing mesh objects migrated from 2018 OpenGL - Should now display Hardscape objects as expected Clip Cube - Cube caps should now show as expected in render modes with Edges enabled Hidden Line - Extensive stability improvements Hidden Line - Fixed significant slowdown in render speed compared to past versions Viewports - Corrected a problem that could cause solid white backgrounds when the background should be transparent Project Sharing: Project Sharing - Fixed an issue where rendering in a working file caused significant instability Project Sharing - Corrected a problem where unneeded checkouts were required Project Sharing - Corrected a problem related to changing referenced PDFs Marionette: Marionette - Corrected a crash related to GetBBox Marionette - Corrected a crash related to Get Curve Point nodes Architect: Horizontal Sections - Corrected a problem where objects within invisible containers would still show Horizontal Sections - Corrected cut graphics pen attribute graphics in many scenarios Slab - Fixed a crash related to Pick Walls Mode Slab - Corrected a problem where Textures did not display as expected without nudging or otherwise regenerating the slab object Stories - Corrected a problem where editing a Level Type would cause incorrect Z height appearance in Sections Section Marker - Fixed a number of cosmetic UI issues Section-Elevation Marker - corrected a problem with the first section line inserted did not use the expected defaults Landmark: Site Model - Multiple corrections to sculpting interface and graphical appearance Plant Catalog - Corrected an problem related to deleting plants from a custom catalog Foliage - Fixed an issue that caused the tool to be unusable on certain hardware configurations Plants - Corrected a plant graphic issue tied to using Best Performance graphics Landscape Area - Stability improvements Site Model - Site Model from Boundary should now display it’s tooltip as expected Spotlight: Spotlight Numbering - Sorting should now be saved across sessions Label Legend Manager - Changing the purpose to Right Reading should no longer display improperly Load Overview - Hierarchical View button now has correct graphic Lighting Device - Fixed a stability issue that occurred when swapping gobos Lightwright - Several Undo alerts being triggered erroneously should now be removed

Vectorworks, Inc. has released its second Service Pack (SP2) for the Vectorworks® 2019 product line. This Service Pack includes multiple fixes and improvements in the following areas: Heavy focus on correcting issues related to the Undo command Numerous stability enhancements in a number of areas such as: Multiple Views, Class Overrides, Attribute Mapping, Project Sharing Extensive improvements to VGM display of Annotations, Fills, Textures and more Large number of improvements to the behavior of the Data Tag object Improved the performance and quality of Generating 2D Graphics from 3D Components This Service Pack is available for all licenses as a downloadable updater. To install the Service Pack, please select "Check for Updates" from the Vectorworks menu (Mac) or Help menu (Windows). For a full list of fixes and improvements in the 2019 SP2 updater, please visit THIS PAGE. Contact us at tech@vectorworks.net if you have any technical questions or problems during this process. Please note this Service Pack is currently available for all non-localized English versions.

Article updated today, Nov 20 2018:

Article updated Nov 20 2018

Expect one shortly.

Correct, which is what is very odd. I would have expected perfectly fine performance with the Macbook > eGPU > Display configuration, though I'm going to try it lid shut today and see if thats enough to disable the internal display being the primary. Supposedly when you move the menu bar to another menu in the Arrangement pane of the Display preferences it is supposed to do this, but the performance results I'm getting disagree. More poking.

You may have Tools > Options > Vectorworks Preferences > Edit > Separate Sheet Views unchecked. I usually leave this on so when I switch back to a sheet layer, it remains in the zoom/pan orientation where I last left it.

According to System Report I have the internal display driven by the dedicated GPU and I still get very weak performance vs expected. However, you're supposed to be able to Get Info on the app and set it to use the dedicated GPU, which it does seem to do as the performance rises slightly over the internal card when going only to an external display and I have the integrated one disabled, but nowhere near the performance that I get from that card installed natively in a windows machine, or when I use it in the eGPU enclosure with the Mac Mini. I'll be poking at this more, I really hope I've just configured something improperly.

I have had far less success improving the GPU performance of a Macbook Pro 13" both when using the internal integrated display as well as an external one connected to the eGPU directly. In some tests, I got scores even lower than the integrated card. I will test this further to see if its a configuration issue. It does not appear to be related to the RAM or CPU of the host machine as neither of these were anywhere near maxed out in Vectorworks or in Cinebench.

You should now be approved, let me know if it gives you any further trouble.

I like nothing more to facilitate work and disseminate knowledge. I am very glad to hear I can help.

This is an exactly correct assumption. I'll give you the super-oversimplified summary of whats going on behind the scenes: Vectorworks is built in two programming languages, C++ (an older language but still a very common one) and Vectorscript, which is very similar/based on Pascal which is declining rapidly in popularity in older applications and nearly unheard of in newer ones. All NEW tools or commands we add to Vectorworks are written either in C++ or added on the side, like Cloud Services, a service which effectively gives Vectorworks more abilities without actually being completely PART of the software itself. So when we add newer things or semi external services, THOSE aspects of the software package CAN be worked on concurrently and have resources poured into them to get a proportionate boost in development speed. The older stuff is effectively carved in stone and has to be transcribed manually. We cant "port" or directly translate things that were made in Vectorscript directly to C++, an engineer needs to sit down, do a full study on the tool or command or whatever they may be replacing, and completely rebuild that tool from scratch in the newer language. It isn't so much like dropping a newer engine into an older car as much as it is showing a modern smartphone manufacturer a picture of a horse and buggy, along with a list of things that horse and buggy can do, and then telling them to create a device that covers all those bases. For some items like "Rectangle" this simple and straightforward, but for complex things like our Site Model tool, the list of "things it does" is incredibly long, its interoperability with other features immensely complex, can sometimes be subjective, and often the coding methods that need to be used in C++ to accomplish the same tasks as Vectorscript are very odd or require that it be completely re-engineered. The re-engineering and effectively repeating decades of work is always, ALWAYS worth it in the end so we keep it up, but there are many limitations into how fast they can be accelerated. None of you in this thread are wrong at all, and many of the assumptions made above are exactly the conclusions I'd have come to as well if I didn't have the good fortune to be able to have a chat with the engineers that work on it daily. Personally, I think that things the way they are today are nowhere near as good as they have the potential to be, and that there are far too many things in the way of it getting better as fast as I feel it should. Many engineers and managers here, along with many of our users feel exactly the same way. We agree with you, and are removing as many stops as possible. I feel that Biplab becoming the CEO was one of the best possible things to happen to this company in a long time as far as this topic goes. (And no, I'm not just kissing up to the boss because it's near review time 😁 we disagree and debate on plenty) As the former CTO, he is incredibly familiar with these limitations and even created entire engineering teams to not only try to mitigate the slowness caused by the limits, but also scheduling and allotting the more unusual resources needed to modernize out entire package. It's the older bits that got us here, they got us here because they were powerful and gave users abilities that they never had before and tools they'd always wanted, but they are now holding us back. We will of course not throw them away, so they will be rebuilt. The modernization of Vectorworks is an inevitability here and all of engineering knows it. Some of the issues that need fixing are huge, but when I first started here in 2006 the workplace culture was much more timid, now it has become one of "How do we climb that mountain?" rather than going another direction entirely.

As soon as I can get a legitimate test together, I will post the results directly.

Ive talked about this a few times but the core issue (oversimplified) is this: We can not throw more than a handful of engineers at the legacy codebase problem at a time, mainly because of how old the code base is. Modern programming languages and software architectures allow for this, but the items we have left over from decades of history do not. So when you see shiny new things pop up, its because that is what we can assign new engineers to and create new tools that add functionality. If it were simply a choice between doing only functionality fixes VS only new features, we would choose fixes, but it is not that simple unfortunately. We need MANY fixes and updates and enhancements still, and just like we are far and away beyond 2014 and older versions in terms of document complexity that is possible, speed of use, and what hardware can be used at all, a few versions from now we will be equally far from where we are today. We have very large leaps in core functionality still actively in the pipe.

If you undock the Attributes palette from the Snapping palette, does it behave the same way after you expand it to accommodate the text the first time?

This could come down to which is the limiting factor in Vectorworks, the hardware itself or our OpenGL implementation, which is much better than it used to be but still not highly efficient when measured against others like C4D. I have also found some more strangeness in HOW I connect the eGPU that affects performance. The great performance in my test case is only possible when the connection is: Mac Mini >(USB C)> eGPU >(HDMI)> Monitor If I connect it: eGPU >(USB C)> Mac Mini >(HDMI)> Monitor which from what I can tell is a supported configuration, the performance in Vectorworks and the Cinebench OpenGL score are far, far worse than even the integrated Intel UHD 630 performance which makes no sense to me. I have tried manually specifying that Vectorworks and Cinebench both use the eGPU in this configuration as well as checking to see if the eGPU is driving the primary display, but the controls for doing the latter can't be seen unless more than one monitor is connected. I will poke at this further, but let me know how you have your hardware configured and if you have similar results if you have time.

One of the core purposes of Project Sharing was indeed to reduce file size. I believe that as @elepp stated above, that it is capable of more compression than the standard VWX format. You could confirm this though by attempting to zip the VWX version of the project file and see if it gets much smaller. Resources within files like image based textures and HDR backgrounds dont compress well or at all, but documents loaded with plugins objects tend to get much smaller.

Thats very odd. I almost always suggest Mac users to use "Any Printer" so they have full control over their page size templates and margins, where some of the printers try to lock them in. I have not however encountered an instance where one page or document was different from another on the SAME printer.

This sounds very, very familiar but yes, please send it to me just in case, I'll double check.