line-weight

Being able to make pseudo sub-layers using the same method as classes with hyphens would be useful, and I don't see any downside. "Layer groups" have also been requested, to serve a similar function.

I can see how this would be useful sometimes and annoying at others. I have a feeling another vector-drawing application I use, which by default draws fill like this, recently announced a new feature that lets users turn this OFF if they want to.

There is something that happens when memory gets full with what Apple calls "purgeable" data. As I understand it, that data is supposed to be using memory until something really needs it for something else, at which point it should be given up. My observation is that when VW tells me there's no disk space, there is usually a large amount of "purgeable" space there but for some reason VW does not access it. I actually filed a bug about this a little while ago but the response was that if it wasn't being given up, then that's down to MacOS and not something VW can change. However, I don't see the same behaviour with other apps with big file sizes, in the same situation.

This has just happened to me now, working on a 600MB file. I've been working on this quite a bit recently, but what I've been doing this morning is setting up various shaded perspective viewports. At this point VW became unresponsive; my escape from this is to quit Firefox which releases enough memory for Vectorworks to become responsive enough to save the file and quit. The next step is to get around this: This whole process (which is all too familiar), each time it happens, wastes about 5-10 minutes of my day (and sometimes means I lose a bit of work). I don't think it should be happening.

Do I understand this right, that updating all 9 VPs for the first time makes the memory usage go from 12GB to 26GB? It looks like everyone's results show that the biggest increase is at the 1st updating of the viewports. It would be interesting to know what happens if you updated them a 2nd and 3rd time. Will this match what I see, which is a ~1GB increase each time? Or will it be bigger, because you have overall much more memory in your system compared to me (128GB compared to 16GB)?

The results seem quite variable; I wonder if taking an average of 5 or 10 cycles of viewport updates would produce averages that were more consistent. When I was doing my own testing the other day, it looked to me like the average amount of extra memory used per round of viewport updates was vauguely similar to the basic size of the file itself. So, with the larger 1.3 GB file, each round of viewport updates added something in the order of 1GB to memory usage, and with the smaller 190MB, something in the order of 100-200MB was being added. That as it happens is what we see in @Tom W.'s test above, about 180MB being added. I am sure some will say that this kind of amount is not significant but file sizes in the order of 1GB aren't unusual. In those cases if each time a bunch of VPs are updated, the memory usage goes up by 1GB then it's not hard to see how problems might arise after a period of working on the file.

Did you give the memory 2-3 minutes to settle after each round of updates?

I had previously tested in VW2025 so I have repeated (with the smaller file) in VW 2026. In bold below are my results compared to yours: Opened v2026: 6GB 3.9GB Opened the above file: 8GB 5.2GB Updated all viewports: 8.75GB 7.8GB Updated all viewports: 8.75GB 8.8GB The obvious question is why the results differ. In your results the second viewport update hasn't changed memory usage at all, and in mine it's added 1GB. Were you in each case giving it a couple of minutes for the memory to settle at a stable level? Is anyone else willing to test either of the files I've posted?

Thanks for testing @Peter Neufeld. Is that with the larger (1.13GB) version of the file? Are you on Mac or PC?

Yes, the bit in bold, which you've added clarification to here, is what for me initiated the confusion. I would put it like this, because, as far as I understand, it does have an impact on the view rotation. And the reason I remove the "sadly" is that (again as far as I understand) that's only sad if you want to use it as a workaround for a defect in other software. If a DWG export did actually rotate the geometry instead of the view, then it would not be behaving as intended, or as users would expect. "Plan Rotation has no impact on the geolocation of geometry in a DWG export. It does not rotate the geometry, and it does preserve the view rotation" By the way, I don't really understand the bit in option 2, where you talk about multiple buildings in 3D all referenced with different georeferencing settings. Do you mean if they are all in different Vectorworks files? Is this something that arises when they get referenced into a master file within Vectorworks?

Attached with this post is a smaller version of the file. The amount of geometry in the design layer is smaller, but there is an increased number of viewports on the sheet layer. For me, this opens to use about 4.4GB of memory. First update of all viewports takes that to 6.87GB. Second update takes it to 7.44GB. So the effect is still visible, but it would take a larger number of viewport update cycles to start producing a significant problem. This matches what I see in real use - it's large files that cause the most trouble. memory leak test v2025 smaller.vwx

Vectorworks is full of confusing terminology but the fact is, it rotates the view of the geometry, not the geometry relative to "the world". There's another function specifically for that. I'm interested in not making these threads any more confusing than they have to be, for those who subsequently read them.

Plan rotation in vectorworks means view rotation. So, yes, I'm pretty sure that's what was meant. If we're discussing Vectorworks then it really helps if we stick to following vectorworks terminology; this is why I think you are causing confusion by assuming your own definitions for "plan rotation" or "true north". In this instance it seems that Revit is causing the problems, not Vectorworks, which as far as I can tell at the moment, is doing what it says it's doing, upon file export. That of course doesn't solve your issue so you have my sympathy there. Luckily for me I seldom have to interact with Revit.

A mixture of standard hidden line "top" views, some hidden line section viewports, and shaded perspectives. My feeling is that the shaded vports have the most effect on memory, then the section ones. Have not tested this rigorously though.

Ok, here is a test file, size 1.33GB: https://www.dropbox.com/scl/fi/klh3f3xjizwdtdhb58aso/memory-leak-test-v2025.vwx?rlkey=yamq44kh8ucs30faskzvwfw4v&dl=0 I am on a mac (Sequoia 15.4) and am observing memory usage via "Activity Monitor". This is the number I am recording and this is what it looks like when I first open Vectorworks 2025 (no file opened): 1. Open Vectorworks 2025 - for me VW2025 memory usage starts out at about 3.14GB 2. Open the file "memory leak test v2025". It should open on a sheet layer with 9 viewports. - for me memory usage goes up from 3.14 to 9.13GB 3. Select all 9 viewports and update, and watch memory usage while the update process is happening - for me memory usage goes up and down quite a bit, peaking at about 27GB 4. Once the updates have completed let things settle for a little while, until memory usage is no longer fluctuating. I give it a few minutes to be sure. - for me memory usage is now at 16.27GB 5. Repeat step 3. - for me memory usage peaks around 27GB again 6. Repeat step 4. - for me memory usage settles at around 17.62GB this time 7. Repeat steps 3 & 4 again. - for me memory usage settles at around 18.17GB this time 8. Repeat steps 3 & 4 one more time. - for me memory usage settles at around 19.35GB this time 9. Close the file (and close the "untitled 1" file that opens automatically, so we now have no files open at all) - for me memory usage now drops to 7.5GB. 10. Open the test file again - for me memory usage now rises to 12.97GB 11. Close the test file again - for me memory usage now drops back to 7.69GB 12. Open the test file again - for me memory usage rises to 13.10GB Observations - Opening a 1.33GB file in VW causes it to use an additional 6GB of memory. No idea if this is reaonable - therefore I'm happy to accept this as "it is what it is". - Updating 9 viewports (with no changes made to anything on design or sheet layer) causes it to use an additional 7GB. That feels like a lot to me. - Updating those viewports again (again with no changes made) seems to add a further ~1GB and this seems to be cumulative; every time I do an update another 1GB or so gets added on. This is what seems most problematic to me. Obviously in the course of working on any "real" file, viewports get updated over and over again. If on each cycle more memory gets taken up then of course eventually there's going to be a problem. And 9 viewports is hardly an extreme number; most files will have many more than this. - Completely closing the file leaves VW using twice as much memory as it did before I opened that file. This suggests to me that at this stage memory that should be getting released isn't. This is potentially something that's gong to cause problems when people are opening and closing multiple files in a session. It's not clear to what extent this is also "cumulative". Closing & reopening the file a few times does show memory creeping up a little but by a relatively small amount. This in any case is not going to help. I'd be interested to see what happens if others try and replicate the steps I've described, on other hardware setups.

I don't have time today but when I get a chance I'll try and dig out a test file that I think I used to try and do some objective testing a couple of years ago. I might even have posted it on a thread somewhere...I forget now. In any case it was possible to see it happen on my setup within a time span of minutes rather than hours or days.

Part of the issue is that we'd probably need to agree in advance what behaviour would count as a bug, or at least "unreasonable". My feeling is the tendency can be shown with a file <1GB in size. But what would we need to demonstrate - is Vectorworks using up 16 or 32 or 64GB of memory with that file open acceptable? Is the amount relative to the amount available on the machine? And so on. Over multiple threads I've attempted to get some engagement from someone at VW, to basically discuss that question, but with little success. If we don't agree what would demonstrate a "problem" then I'd fear I'd just waste more time producing a load of testing that goes into a black hole or is labelled as "working as deisgned".

Can we somehow jointly assemble sufficient evidence to show that this really is a problem, and submit it as a bug in an attempt to get something done about it rather than watching the collection of threads grow for another 15 to 20 years? It really is a waste of everyone's time (and computing resources).

But it's not supposed to! "Rotate plan" isn't supposed to move any geometry, only your view of it. Maybe I have got the wrong end of the stick somewhere but it seems like you are causing loads of confusion by expecting VW to do something it's not supposed to do. (Is this some kind of a hangover from older workflows from before georeferencing became a thing?) Here is what a drawing looks like, with building drawn square to the screen: At this point it's just floating in space with no reference to the real world or any notion of "true north" because I haven't told VW where true north is. I do that by adding georeferencing information. I can tell it that true north is 20 degrees off the Y direction here: and then I get this: The compass ring has been added at bottom left and we can now see where true north is. Plan rotation remains at zero. If I now want to rotate my view of the drawing, so that true north corresponds to straight up on my screen, I can do that by adjusting the plan rotation, in this case by 20 degrees: True north is now aligned with the screen. Nothing except my chosen view of the plan has changed. The building is still in the same place, and true north is still in the same direction relative to the building. If I want to export this to someone and include geolocation info, then the information that is critical when it comes out at their end is what's the angle between true north and the orientation of the building's main walls. Not what view rotation I happened to be using to look at the drawing just before exporting - that's irrelevant. If the exported geometry changed according to what my view rotation was, then something would be going wrong. Like I say I may have got the wrong end of the stick somewhere but it all seems dead clear to me: if you want to export the drawing with geolocation info then to specify the angle from true north, you do that it georeferencing settings and not in "plan rotation". The question for me is whether that info reliably comes out at the other end, as long as I (to the best of my knowledge) have set things up properly in my file.

When you talk about "true north" what do you actually mean? Do you mean, as set in the "angle to true north" georeferencing settings in Vectorworks? Can you show us a screenshot of the plan in vectorworks where we can see the compass pointing to "true north" and then the equivalent for the exported DWG as it appears in ACAD?

No harm in filing it as a bug? It comes up as an issue quite repeatedly and can effectively crash/freeze VW sometimes. And most other applications that deal with large files don't seem to have this behaviour.

This is exactly what I'd expect, because that's not the intended purpose of rotated views. I'm not sure what the two screenshots tell us other than that acad and revit are making different choices about how to display the same data. What matters is that true north, relative to the building, is the same in each case - is it (there's no way to tell from the screenshots)?

It is yes.

Actually, isn't it that it rotates everything relative to the user origin grid. So it either rotates everything *except* the user origin grid or it rotates *only* the user origin grid, depending on your frame of reference. Or an alternative way to see it is that it temporarily creates a new, rotated user grid that exists for as long as you want to use it. You can always go back to the default one.

Yes, this matches my understanding. This is why I don't understand why you'd use "rotate angle to true north" while working on the drawing and then revert it for export.