All Activity

I have been testing with the existing Spotlight workspace in 2026 but just did the full migration from 2025 and everything came in except my workspaces. They are present but when I open 2026 it says it cannot load my primary workspace and when I go to Tools>Workspaces they are not present. Hoping I am doing something wrong and do not need to recreate the workspace. Thank you, Lonnie

Fitting the "Room" into the "Page" so it's quick to get a full view by CTRL-4. Just a workflow thing I do...

Wild, that definitely looks like a bug. Purely out of curiosity, what's the logic behind 1:37 scale?

I have a related issue - "VWX scaling a layer different from the rest, on it's own" here in Troubleshooting, but I DON'T want different scales for my layers. Any thoughts?

I have been fighting as issue with a file. (And it's happened randomly on a couple other files.) I change somethiong on a layer, and that layer will get re-scaled, leaving the others alone. So any other layers disappear. 😒 I thought I was going crazy, until I was able to repeat it. And it's not just 1 tool, but a few different ones. In the attached video, I'm moving an item in Z space. But it has also occured when I am using the Mirror tool in a Top/Plan view. Any thoughts? TIA!! I'm in VWX 2025 Spotlight, update 5 on a windoze machine. Win 10, 128G RAM, 64G VRAM Scaling Problem.mp4

A great new post on VW files and memory from another thread may help:

@Jesse Cogswell This is the best post on VW & memory/performance on the forum. It should be required reading. Thanks.

yes I feel that "corrupted" drawing files are less often a problem than in the past.

The recommended current workflow is to use Data Tags. I wouldn't expect VW to continue improving (or fixing) the IDs within the Door and Window tools. If you need help learning to use Data Tags, the forum community will help.

Make sure you don't have a lot of tabs - they can hog memory. In addition to the Mac's Activity Monitor, I also use AppTamer and iStatMenu to monitor and control RAM usage. Both are available on SetApp. While I've had to pay attention, I manage to be OK with 24GB RAM. However, my projects are smaller than 24 unit buildings and I do very little rendering.

Usually the number of sheets has little to do with file size (though there is a setting that cause an exception to that). Most of the time with Vectorworks, the file size can be affected by the following items (in no particular order): Texture resolution: Vectorworks doesn't do any kind of compression for images saved in a file. I do my very best to keep my textures to around 300 KB or less. It's really important to think of how the texture will appear in a Viewport. If it's a small placard in the background that doesn't need to be super legible, then it probably doesn't need to be a full 4K texture. Complicated object history: Anytime you use Add Solid, Subtract Solid, Section Solid, or Intersect Solid, the solids making up the operation are all stored with file. This can become huge if you are doing multiple operations to create an object (nested Solid Addition inside a Solid Addition inside a Solid Subtraction inside a Solid Addition). This be easily happen if you use the Push/Pull Tool in the wrong mode, since it creates a level in the object history with each operation. It's best to "clump" operations together, so if you have an object that wants four holes in it, it's best to create all four hole objects and subtract them in one step rather than doing them one at a time. You can remove an object's history by selecting it and running Modify -> Convert -> Convert to Generic Solid. This will make the object "locked", so it's best to do near the end of the design process, but can really speed up your file. Undo History: I've noticed that your undo history may be saved in the file. I've seen that "expensive" operations like importing PDF documents onto a design layer can balloon the file size, even if you delete the PDF. But if you save and close the file, then open it and immediately save it, the file size will be smaller. If I'm trying to reduce the file size on a drawing that I've been working on long enough to have a large number of undo actions, I'll often save and close, then open and save again. Referenced File Cache: If you have referenced files, such as using another drawing in a Design Layer Viewport, you have the option to Save referenced cache to disk. This can be handy, it essentially saves the geometry from the other drawing into the active drawing, so if the reference is broken, you don't lose any content. The downside is that if you are referencing a large file, then your working file will be even larger. However, having the option unchecked also means that every time you open the file, it has to "update the reference" and load the drawing geometry into memory instead. I once worked on a drawing where one of my referenced files was nearly 2 GB due to everything having 4K textures. I save a new working file every day and auto-save up to 3 backups, so having the geometry in my working file would have taken up a huge amount of space, so I opted to not save the file cache. But it took 20 minutes to open the drawing as a trade off. Really ate up some time with how unstable Vectorworks can be. Saving Viewport Cache: This is the exception to what I said about sheets. This option, found in Document Settings -> Document Preferences saves rendered and Section Viewports so you don't have to Update them every time you open a drawing. If your drawing is mostly Top/Plan views and a few Section Viewports, having this option checked doesn't make an appreciable difference to the final file size. But if you find yourself doing a lot of renderings on Sheet Layers with a high DPI, then the sheet layer count can really affect the file size. I used to fight this a lot, photo-realistic renderings can take forever to render, so I would rather have the Viewport saved so I don't have to re-render them if I'm publishing a drawing set. But your file is basically saving the final image of the viewport as an uncompressed image, which can make the file huge. What I started doing instead is rendering my viewports out on a temporary sheet (not part of my published sheets), then using the File -> Export -> Export Image to export the final rendering as an individual JPEG file. I then import that JPEG file as a referenced Image resource (not cached) and apply it as an image fill to a rectangle on the sheet layer. This makes it really easy to update the viewport (just save over the referenced file), it is always ready to export the sheet, and it takes up practically no space in the drawing file. Grouping items rather than making Symbols: This is something that I run into fairly regularly. It is easier to group items than to make a Symbol, so designers sometimes do that. But if you group a collection of objects, Vectorworks is still tracking each of those objects individually. So you if make an group of 10 objects and copy and paste that group 10 times in the drawing, VW is tracking 100 individual objects. But when you create a symbol instead, VW only has to track the original 10 objects against the Symbol Insertion Point and then the location of each Symbol instance in the drawing against the origin. IE, 20 objects in this example. Now imagine you have groups consisting of 100s of objects. It can make a huge difference. Mesh Objects: This is likely what you are running into when working with files imported from Rhino. Complicated mesh geometry can wreak havoc on file size and performance, and unfortunately there's not a great way fix it. If the objects are relatively simple, you can recreate them using standard VW tools. But while you can run Modify -> Simplify Mesh to try to reduce the complexity of the mesh, you can quickly run into major degradation. One thing you might try in your case is putting the imported Rhino geometry into it's own Vectorworks file and referencing it in as a Design Layer Viewport without caching. This way it won't be added to your file directly, but might take a while to open. Anecdotally I've had improved stability with this method as well, but running tests on CPU and memory performance didn't show any major difference between referencing geometry and having it native in the drawing, so it may not help much on the performance front. I do have a plug-in that will Delete Object History across the entire VW file, which can be a shotgun approach of determining what is causing a large file size, but it won't tell you specifically which objects are large. I could feasibly write up a script that searches the drawing for objects with history and count the number of layers to determine the heaviest objects, that might take me a bit of time.

Thank you. This makes a difference. There is so much to learn about this program. Thank goodness for this forum!

This is a know issue and will be fixed in the future. The issue exists only for older stage decks used in 2025. New stage decks created in 2025 will not have this issue.

Honestly, the time I would save would make buying the new Studio worth it. Getting back to the original post, I think I had a toilet that was hogging a lot of rendering time and have switched to a toilet with 2D components and the file has sped up a bit. A computer upgrade would be equally is beneficial.

@homero another setting I reccommend you is to set the smoothing angle of your hidden render background setting from 1 deg. to 15 / 20 deg to eliminate some of the meshes you don't want to see :

Have had quick scan. Were couple of references to importance of ram, @zoomer says he’d never go below 32GB + that’d be my advice too.

As I can recall, I was under the impression that the M2 to M4 upgrade would be enough. Many had suggested waiting for the new M4 Studio, but I just couldn't not wait. Seems to me that Mac oversells their M chip developments when RAM (which we can't modify/increase) may be the larger factor. We are always in a perpetual "wait for the next upgrade" hamster wheel.

@Tom W is correct. Databases can only display data that is somehow linked to the object specified by the database criteria. If it is not associated, then when an object get added or deleted or the sort order changes the worksheet would not have a way to know what object to keep the data with. So add a custom record, or use an unneeded field in an existing record so you can type in the data you want.

I recreated my Templates a few years ago from scratch, after migrating them over years before. Not sure if that really helps if I copy over 80% of content later anyway. Like Projects, when migrating Templates, I open them and do all "Utilities" like resetting PIOs and such and resave them again. Might sound a bit esoteric but I did not have big issues with migrated files as I had at the beginning with VW. Where a file was constantly crashing just because of a single corrupted Door found by VW Support.

Be interested to see what advice you were given. Have searched but can't find it. Are you using a second display?

Thank you. I had posted here last year about buying a new Mac. I thought this one would be adequate. I'd hate to keep buying a new one every year, but sounds like that may be a solution. I just have Chrome running.

I'll do my best! In the meantime, we're always listening and taking notes for these requests. 🙂

Thank you well noted. I only ever use the timber sill + didn't think to check at the time how the other configurations work but I did realise afterwards they were different... Hopefully @Matt Panzer will tell us the day we have a better functioning sill is edging closer... 🙂

Also... the 3d preview is kind of useless because it doesn't know where the back of the sill is actually going to end up, so just draws it in some default location, which makes the preview image misleading and confusing.

Against my better judgement I thought I'd try to get some sills working, and of course just ended up completely wasting an hour+ of my day. ^ worth noting that: a masonry sill aligns with the external face of the core component a timber sill aligns with the internal face of the core component a brick sill aligns with the external face of the core component This urgently needs improvement... we should be able to do what @Tom W. says above, and also, if the behaviour of aligning relative to the core component remains, then this needs to be indicated on the diagram in the window sill settings dialogue because otherwise everyone that tries to use this is inevitably going to be frustrated and confused.