Jeremy Best

Hello Tamsin! A clarification on this point please. On this page of the Vectorworks Help manual it says, "Once users have created working files from the project file, don't rename the project file or move it to a different folder. Never make copies of a project file." I'm quite sure that the manual says this in order to prevent Working Files (.vwxw) loosing track of where the Project Sharing file (.vwxp) is, but just in case, can you please comment on / clarify this? Is it not suitable in the above scenario to create the initial (.vwx) file in the desired shared folder, and then convert it to a project sharing file [that will replace the .vwx file]? Thanks! Jeremy

If you're not intent on this being a Marionette, it sounds like the sort of thing best met by selecting a script from the Script Palette. Use the 'Custom Selection' command to create a script that will select the desired objects. Then just double-click the script in the Script Palette any time you want to action it.

Hi Rolan, I provide Tech Support for Vectorworks in the New Zealand market. Hope I'm not too late to provide some value for you. If so, other users could benefit. I'm happy to tell you that correlation does not equal causation in this scenario and that this problem is extremely unlikely to be due to any bug specific to Vectorworks 2023. The most likely cause for this issue, - especially if you have noticed problems specific to a tool that has its own preferences - are the Vectorworks Settings files, or some other data kept in the parent, 'Vectorworks User Data and Preferences Folder.' Issues with these files can occur at various times or various reasons. I suggest you try setting aside your current Vectorworks 'Settings' folder and seeing what results. The method is as follows: Quit Vectorworks 2023. In Finder, open the Go menu and choose, 'Go to Folder…' Paste in, '~/Library/Application Support/Vectorworks/2023' and click Go. Rename the 'Settings' folder to something meaningful like, 'Settings @2023-04-20' Reopen Vectorworks and see if the issue continues. - If it does, repeat the above process but rename the parent folder, '2023.' This process will of course retire your current Vectorworks Preferences and tools settings etc, or all customised content if you retire the whole User Folder. This data can be reinstated as-required but in this scenario, if issues return after reinstating files or folders, correlation will equal causation and said files should be permanently removed.

Renderworks Styles offer the option to have textures turned on or off. Check that first. If that doesn't apply… This is the kind of symptom that warrants restarting Vectorworks. If that doesn't resolve it, try restarting your computer. If the above do not restore normal functionality, contact tech support for your region.

Graphics card drivers can be set to deliver different results for individual applications. Check if there are any relevant settings in the Nvidia Control Panel that might be causing this for Vectorworks 2023, compared to Vectorworks 2022 (assuming you have them set up individually).

Hi Tom, I believe what you're experiencing is indeed a bug, for two reasons: The ability to manipulate files in any 'Windows' window (be it an Open dialog or otherwise) is a convention of the operating system and when software 'calls' on these windows, it is fair to expect that 'conventional' operations will work, at least those operations that match the context anyway. I too experience Vectorworks going indefinitely 'not responding' in File > Open… dialogs on both macOS and Windows in relation to Vectorworks. However, I can't recall what the operations were. So I'll do some tests. Note: This might be a bug of the operating system, particular to this context (software employing the file handling conventions of the operating system). But it also might be a bug of Vectorworks but subject to particular conditions. In my tests just now: On Windows, in the File > Open… dialog in Vectorworks 2023 SP4, I've been able to: Duplicate a subfolder using Ctrl-drag. Move a file to the Desktop folder in the sidebar. Use Cut then Paste to return this file back to the original location. Create a text document (via right-click > New > Text Document) but as expected it immediately was hidden as it wasn't a .vwx file. Use the Search box to search within the current folder/directory. No issues, but I was expecting Vectorworks to go 'Not Responding' during at least one of these as I have experienced this on Windows. On macOS, in the File > Open… dialog in Vectorworks 2023 SP4, I've been able to: Duplicate a subfolder using Option-drag. Move a file to the Desktop folder in the sidebar. Use Cut then Paste to return this file back to the original location. Create a text document (via right-click > New > Text Document). - Can't be done. Inappropriate context. Use the Search box to search within the current folder/directory. However, it did invoke an abnormal amount of CPU activity which doesn't happen when searching in Finder windows. So for some reason, on this occasion I was unable to invoke 'Not Responding' on either platform so it seems like that it is subject to particular conditions.

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.

Hi @ptc, I've received reports of this from a few different users over the years, including recent ones with Vectorworks 2023 SP2. Engineers can't fix software bugs unless they can reproduce them (for analysis) and this issue seems to be extremely difficult for them to reproduce, so I'm trying to collect as much circumstantial data for them as possible. When was the last time you were affected by this issue? How often does it happen to you? Have you noticed any correlating factors?

Hi @SeanOSkea, I've received reports of this from a few different users over the years, including recent ones with Vectorworks 2023 SP2. Engineers can't fix software bugs unless they can reproduce them (for analysis) and this issue seems to be extremely difficult for them to reproduce, so I'm trying to collect as much circumstantial data for them as possible. When was the last time you were affected by this issue? How often does it happen to you? Have you noticed any correlating factors?

Hi @Anelisa, If you are still using that 2012 MacBook Pro that definitely is a likely cause of any performance or behavioural issues you encounter with contemporary software. A general rule-of-thumb is that professional computers should be no more than four years old at best, or at worst, no more than six years old. If you are on a contemporary computer using an operating system that is current or is at least still supported, then here are the two most likely causes: Vectorworks or the computer has had a 'hiccup' and just needs a restart. Try restarting the computer. One of the Vectorworks settings files may have become damaged. Try this: Quit Vectorworks. Open the Vectorworks User Folder. Append the name of the 'Settings' folder within, with something meaningful. E.g. 'Settings @ 2022.12.22' Reopen Vectorworks. If the issue persists, quit Vectorworks, delete the new Settings folder that has been created and reinstate your previous one by changing the name back to just 'Settings' If the issue has gone, go thought Vectorworks Preferences and set them up again. Also, to help others help you better, can you please include in your comments or add to your signature: The version and service pack of your Vectorworks. E.g. 'Vectorworks 2023 SP2' The spec's and operating system of your computer. (See my signature for example). They provide crucial context when troubleshooting.

Hi @pfalvi, at least for the sake of narrowing down the cause, can you please try restarting Vectorworks then see if the by-face texture shows up. In the following fashion: Quit Vectorworks. When Vectorworks has finished quitting, wait 10 seconds. Open Vectorworks again. If the issue persists, try restarting your computer as well - unless your colleague has experienced the same problem as you. While this is the kind of behaviour more likely to be a bug than due to some conditions particular to your installation or your files, the next appropriate step before making a bug submit is to verify if this issue is particular to the file/s in question. As you probably start projects from a template that needs to be ruled out as well. The method to do that is: Go: File > New… > Create blank document. Create the required objects and assign textures to a face/faces. Convert the file to a Project Sharing file and put it in the usual place. Open the project sharing file to create your working file and look to see if the texture appears on the applicable face/s. If it does, have your colleague open the project sharing file to create their own working file, create new objects and apply textures to faces. Then Save and Commit. You open their test file and see if the issue occurs within this. - If it does, it's a almost certainly a bug and not specific to your files. Submit the bug here.