Jeremy Best

Many users experience prompts to update Vectorworks as an imposition and therefore quickly dismiss them. This often results in many out-of-date installations which brings down the average user experience and increases demand on Tech Support and reduces their availability and productivity. Update prompts pop up at the worst time: A short while after opening Vectorworks. This is when a user is most keen to get onto what they opened Vectorworks to do and applying an update at such a time would delay them, interrupt mental flow and affect productivity. I propose that updates be announced to users under different circumstances, like so: Vectorworks checks for updates in the background as usual and if they are available one or more of the following occur: Vectorworks prompts to apply the updates when the user next quits the application. When restarting Vectorworks after a crash, the update prompt appears. Immediately after a crash. I realise this might require a new Helper/Service program which might not be viable. Benefits: Applying an update on exit won't delay a user or affect productivity, except when they're closing Vectorworks before a Shutdown or Restart. If they're restarting Vectorworks to remedy an issue, updating should be part of this process anyway. Prompting to update on exit will increase the propensity for users to accept update prompts. More installations will be kept up-to-date, improving typical software experiences. The act of applying an update can remedy some issues [even when no bug fixes relate to the issue concerned]. More up-to-date installations = less time will be spent submitting to Tech Support. This will preserve Tech Support and VW Engineering time as there will be fewer bug submissions from users on older Service Packs.

My experience suggests that it is more likely that the objects concerned - or perhaps something they rely on in the file - are corrupt. The process of converting a file [to a newer version's file format] involves Vectorworks reconstructing/rebuilding objects based on the parameters that define them and this process can correct corruptions. There are various ways to invoke this process, including: Toggling parameters of the object/s in the Object Info Palette. Copy-pasting the object within the same file, or (perhaps more reliably) to another file and then back again. When the problem object can't be easily identified; Import all objects into a new blank document, via Tools > Organization > Design Layers > 'New…' > Import Design Layers, select desired layers, select 'Import Layer Objects'. Export the file to a previous version, then reopening it in the current one. It's also possible one of the Vectorworks preference files could be corrupt and responsible for this, although I've not encountered them being responsible for this particular behaviour. To rule them out simply quit Vectorworks then rename the Vectorworks 'Settings' folder found within the Vectorworks User Folder found here: On Mac: ~/Library/Application Support/Vectorworks/2023/Settings (Use 'Go To Folder…' command in Finder). On Win: %AppData%\Nemetschek\Vectorworks\2023\Settings (Paste into the address bar of any File Explorer window). You'll then need to re-setup all your Vectorworks Preferences.

Hello @Peter King, We have one user in our jurisdiction (New Zealand) that has reported this behaviour. I verified it then submitted it to Vectorworks engineers in November. After a decent search of the Forum yours is the only other report I can find, so it seems like very few users are affected. Your steel section objects are 2D plugin objects, so I'll add here that 3D plugin objects also fail to be moved when included in the marquee selection. I confirmed the issue is absent in Vectorworks 2020, but present in Vectorworks 2022 and 2023. If any other users are affected by this issue, please use the 'Vote' up button to the left of the top comment. This will help engineers gauge how many people are affected. Add comments if you are severely impacted too.

To determine if this is a deficiency in the software of Vectorworks 2023, you'd need to perform the exact same operation with the same file in previous versions of Vectorworks. Try exporting your file to Vectorworks 2022 and testing it there in exactly the same way. Many operations must first determine what objects are subject to the operation and which ones aren't. While I am not privy to the software code Vectorworks uses to perform this operation, my knowledge of how software in general works and Vectorworks in particular, I'd say that this operation takes longer to process when the objects to be trimmed are surrounded by other objects due to the strategy employed to detect whether a line should be trimmed or not. If a different strategy was employed it might be faster when surrounded by objects and slower when not. It's all geometric calculations and all geometric calculations are math; so it's all math! Give the computer a bigger equation to calculate and you can expect it to take longer. 😁

Sorry @Tom Klaber, I did not absorb your mention of this. I was addressing only your memory consumption comment so the uninitiated will have some perspective. If Vectorworks crashed when it wasn't doing anything - in my view - this makes it more likely it was caused by something other than Vectorworks, but I'm not asserting this is the case. If Vectorworks is crashing every time a particular action is performed, or if crashing of any kind becomes a frequent problem: Contact Tech Support for your region. I recommend all users have 'Error Reporting' turned on (preferably 'verbose') in Vectorworks Preferences as this helps engineers recognise systemic issues.

I reiterate: No matter how much RAM you have installed one of the most important aspects to monitor is the total percentage of memory consumed. - There is no limit to how much memory consumption user actions can induce, so if the work performed is the sort that creates a lot of demand it is necessary to learn how to manage that consumption. Is there a bug involved? I will be concerned if there is a significant percentage of users experiencing high memory consumption that does not correlate with user actions. I am not receiving reports of this in my market so at this stage I'm not suspecting a software bug. If it were a bug, it may be dependant on conditions or workflows that aren't common in our market. Why is my Vectorworks installation slow? There are various potential causes of slowdowns and high memory consumption so submissions should be made to your region's Tech Support. Due to the number of variables that can be involved with memory consumption and slow-downs, they may need to get online with the user while the issue is happening. If you are experiencing behaviours in Vectorworks that do not correlate with the demands induced, log into your Vectorworks Customer Portal to contact Tech Support for your region.

@Tom Klaber, Your screenshot doesn't show Vectorworks using 42%. That percentage at the top represents the total memory consumed by all processes currently running on your computer, including the operating system and other programs. If Vectorworks' use of ~4GB is 42% of your total memory you probably need more memory for your work as Vectorworks 2023 does indeed have a higher baseline than Vectorworks 2022 did. In relation to Vectorworks using more memory when all files have been closed vs when Vectorworks is first opened: If you have had a Vectorworks file open this session Vectorworks will retain some aspects of your interaction with that file in memory. I wouldn't expect those to remain indefinitely but if they did and it wasn't in order to offer some benefit to the user - such as being able to reopen that file faster - then it would warrant a bug submit or a enhancement request.

No matter how much RAM you have installed one of the most important aspects to monitor is the total percentage of memory consumed. Getting slightly more technical; The amount and the rate that memory is being extended to the disk drive is a concern - more so for those with an HDD (hard disk drive) as opposed to an SSD (solid state drive). For Windows users: If the 'Memory' graph in Task Manager indicates the majority of memory is in-use then that's when you should start to consider either reducing the demands you place or increasing the RAM installed. That's the least technical way to measure but it's not the most accurate. If you want to be more precise or nerd out, this question on Superuser.com elicits this excellent comment which provides a more accurate way to gauge if memory size is an issue. For Mac users: Open Activity Monitor. In the Memory tab, look at the graph at the bottom. If the graph is yellow, orange or red while you're trying to work, you need more memory OR to reduce how much demand you're putting on the memory. If this happens often, more memory is warranted.

As per Vectorworks' System Requirements page for Vectorworks 2021, macOS 13 (Ventura) is not supported. If this issue began after upgrading to macOS Ventura then this will almost certainly be the cause. In which case the solution is to upgrade to Vectorworks 2022 or the current release, Vectorworks 2023.

@Benson Shaw When in orthogonal view, zooming simply enlarges the view, hence everything just gets bigger and bigger with no theoretical limit. This is simply due to the nature or orthogonal geometry where actual parallel lines are displayed in parallel. But when in perspective - where lines that are actually parallel converge on the screen - zooming actually 'moves' the viewer forwards/backwards. So, at some point the viewer will penetrate surface of any objects in the way. It does indeed seem that issue - as you assert - is the point at which the viewer penetrates the object. Based on chats I've had with the engineers they'll know why Vectorworks 2023 'penetrates' earlier than prior versions. I suspect the difficulty will be adjusting this without affecting the other 'flashing surfaces' issue.

An engineer posted a video of this 'object peeling' symptom to the bug report of the other issue you mention - the flickering surfaces seen when in Shaded mode and perspective view. This infers that this symptom is at least suspected to be related. I've confirmed that this happens in VW2023 SP2 on my Mac and VW 2023 SP3 on my Windows computer. For the uninitiated: This 'object peeling' effect is indeed also caused when one or more objects are too far away from the document's Internal Origin - which is distinct from the User Origin. EDIT: This behaviour directly correlates to the scale of the Design Layer. In Vectorworks 2021 SP5, with a Layer Scale of 1:1 'object peeling' doesn't occur until you are essentially 'inside' the object concerned but object peeling occurs when much, much further away from the object when the Layer Scale is 1:200. The behaviour is 'normal,' however the threshold for it to occur is lower in Vectorworks 2023.

@Matthew Walker, @mjm and anyone else affected by this bug, here's a suggestion to help you cope with the impact to your workflow: Saved Views can be set to quickly toggle your view from 0.00° to the rotated view you're working in. A simple double-click in Saved Views any time you need to edit a group, then another double-click to return to the set rotated view (or use the 'Previous View' button).

Hi @Peter v G, the build number of Vectorworks in your region may be different to that used in other areas and as Service Packs are released at different times in different markets we can't assume you've updated to SP3. Can you please specify what Service Pack (SP) you updated to?

Hi @line-weight, yesterday I saw a contribution to the bug submission for this. It was a video recreating the symptom you describe above - let's call it, 'geometric object peeling.' Just letting you know it is continuing to receive due attention.

@Chuck Hunter, You crash will not relate to this 'DirectX 11' issue. By default, 'Autosave' doesn't automatically save your primary file. The default Autosave settings will create one or more copies of your file in its current state. It will only save the file you're working on if you use the setting, 'Overwrite original file.' If you use the default setting 'Autosave a backup copy to:' you must still manually save your work as-you-go. I would only endorse the use of the 'Overwrite original file' option if all your files are either backed up automatically every hour by something like Time Machine or if all your files are stored in a cloud storage folder of a service that supports 'file history' which enables you to roll back changes you may not want. I've received occasional reports from users of the Autosave function ceasing. It is most often a fleeting problem, fixed by restarting Vectorworks. Sometimes a Vectorworks preference file needs to be deleted. Some - maybe most - of such cases are caused by user oversight. If it is set to appear, when the Autosave prompt pops up some users [mistakenly] choose 'No' [don't autosave a backup file] while also selecting, 'Don't prompt me for the remainder of this session.' Then you can end up with work being lost after a crash.