Jump to content
Sean Harrington Architects

Tips for reducing file size

Recommended Posts

Hello everyone,


I was wondering if anybody had any tips for reducing file size for large site models other then the purge command? At the moment my file size is above 400MB and is really struggling to complete simple tasks...it will complete them but at a very slow pace. I am new to site modelling in Vectorworks 3D, however I am aware how heavy the files can get from working in 2D and  I am coming to the unfortunate conclusion that this I just something you have to deal with when working in this programme. 


However, any advice would be really appreciated. 


Thank you

Share this post

Link to post

Something to think about if your site model is formed from 2d poly contours converted to 3d polys.  This conversion, either via the Modify>Convert or via the automatic terrain setup steps creates 3d polys which have HUGE vertex counts.  All those vertices may not be necessary to form the site model you desire. eg if your contour interval is 2', do you need a facet on the site model every half inch?  One way to reduce the vertex count is via the Simplify Polys.  But this always changes the shapes of the contours past my tolerance.  Another way is to add an intermediate conversion step for each contour: Modify> Convert>2d polys to NURBS. Then convert the NURBS to 3d polys.  You can convert the lot of them in one go.  Just remember to ungroup prior to and after the 2nd conversion.


To demonstrate, in a new test file, create or paste a 2d poly contour. Duplicate it twice and color code the dupes so you can tell them apart and have a copy of the 2d original.  Convert one of them directly to 3d poly.  Convert another to NURBS, then convert the NURBS to 3d poly.  Select each 3d poly in turn and compare the OIP vertex count.  Overlay them on the original to observe changes in shape.  Run the Simplify Poly process on one or both to compare shape changes with that, too.  


Alternately,  Duplicate Along Path a 3d locus on each contour.  Choose a distribution that's about half the contour interval. These loci can be colored and classed so each z group can be differentiated. Create the site model from the 3d loci instead of from the contours. You may need to ungroup them.


Also, look at the non site model objects in your file.  Do you have repeated items that could be made instead as symbol instances? Elaborate trees/plants? Fence posts & caps? Patio furniture? Lights? Stuff from 3d Warehouse or manufacturer websites?  You might have a few items with gigantic vertex count mucking up the works. Replace them, or edit to remove unneeded geometry.


Do you have image textures? Remake the textures with lower pixel count version of the image.  Using large areas of grass or other "bumped" textures?  Cancel the bump shader until final render, or apply it only to very small areas.


Site models are big, complex chunks of code full of contained objects, mods, textures, etc.  They cause large file size, so you may never slim the file down to 100mb.







  • Like 3

Share this post

Link to post

Hi Benson, 


Thank you very much for your response. They are very helpful tips. This is probably a question I should have asked before I progressed too much with the model...it is relatively near completion at this point but those are definitely points I will consider if I am to remake it from scratch. The site model itself is quite a large site with buildings on it taken as viewports from other files, sir not many non site model objects are included in the file as of right now. However I have a couple of winding roads and A LOT of modifiers which I am assuming is causing the file to slow down?


Share this post

Link to post

Also if you have a lot of image textures, think about the source images versus the actual display size they are used at.


You probably don't need a 20 megapixel image for a texture that will be on a small object on the far side of the room in a render.


Similar with any other imported objects such as background PDFs. If you don't need them delete them. If you do need them, consider reducing the resolution as much as you can stand, deleting the first version and reimporting.

  • Like 2

Share this post

Link to post
On 3/16/2018 at 8:19 PM, Pat Stanford said:

Similar with any other imported objects such as background PDFs. If you don't need them delete them. If you do need them, consider reducing the resolution as much as you can stand, deleting the first version and reimporting.

Or put those in referenced files if they are vector objects and if you don't need to edit them, to keep the size of your working drawing smaller. E.g. dwg files as a background could be imported into a new VW file and used through a reference in your working file, it does make a difference in operational speed as well.

  • Like 2

Share this post

Link to post

Also make sure you have moved the origin by going to Tools>Origin>Center on Internal Origin this may help in size but definitely rendering.

  • Like 1

Share this post

Link to post

If I have a large 3D Model of a venue in my drawing.

Are you saying it Is better to ex-ref the 3D Model?


Lower file size and faster performance?



Share this post

Link to post

I think it depends on what you are doing.


If you are truly using model provided by others as a background and you have no need to edit it, then referencing can be very effective. It will isolate all of the layers and classes of that file and not have them show up in your file while still giving visibility control through the Viewport Layers and Classes settings. If you check the Retain Viewport Cache (or something like that) option, then it will not do a huge amount for your file size because it will still "import" the data (or at least some of it) into your file.


The downside is that when you move the file to a different location (folder, machine, network) you really want to send the model file with it unless the Viewport Cache is good enough.


If you need to modify the model in any way, then you want to import it. Or possibly import it into a VW file of its own (if not already a VW file) to edit and then reference that into your file. If you need to do a lot of back and forth, then a true import is probably better than a reference.

Share this post

Link to post

I use many referenced files, mostly for sites and venues that I've created myself in VW, though not always. These files do not need to be changed very often, but when they do, it's very simple because they are accessible from our server. Keeping those classes & layers sequestered in a referenced viewport is the only way to go IMO. I also always save the viewport cache because I often work offline and need those referenced files to appear in the drawings. I only turn it off when archiving old projects to keep the file size low.


Most of my projects are around 150-200 MB, but some of them do get up to 400-600 MB or more. I recall getting close to a gig once, but I was keeping way to much old junk in that file. Purging is helpful for internal organization, but doesn't really have anything to do with performance, except with the initial file load. The speed you're talking about has to do with how much of your model is visible on screen at a given time, not because you have a bunch of large images in your resources browser. That being said, @Pat Stanford is absolutely correct about not needing high res images in your models. I use A TON of graphics and I shoot for a 100-200K image size except in special cases. Remember, screen resolution is only 72/75 ppi, print is 150 dpi, and the rendered object you're applying a texture to is probably not even that. Keeping images small is a best practice. I do keep my files sizes as small as possible, but for the purposes of server storage and file sharing, not performance.


Assuming you've got a lot of good RAM (this is important), performance doesn't really have anything to do with file size directly. High performance speed during drafting is primarily about organization. Really, the only point at which the files size affects speed is during file load or file transfer. Once loaded, it's all about visibility settings. Using layers & saved views to make sure that you're only viewing the parts of a plan that are necessary at any given time will speed up your workflow. Break your work up onto logical layers, don't keep all layers visible at all times when only a handful of necessary layers will do, and if you have a large ref file, break it down into logical sections so that you can break it down in your working file as well. Use saved views to quickly switch between workspaces for your most common needs. The more geometry you have visible at one time, the slower your performance will be, and the more important good organization becomes. Turn off what you don't need and you're performance will increase. Classes can be of use too, but usually this duty falls on layers. Of course, there are times when you must have everything visible, and then you just have to deal with it, but I've yet to work on a project where I couldn't organize it into a slick system. The actual process of switching saved views does slow down when using files with tons of geometry, but it's still manageable, and the best way to go.


This concept applies to viewports as well. Make sure only the layers you absolutely need are turned on in your viewport, or rendering can take a very long time. The viewports seem to render all layers that are turned on, even if you can't see them in your viewport because they're in the background or cropped or something.


Also, the geometry contained within a single object makes a difference. As you noticed when you simplified polys, simplifying your objects as much as possible will reduce file size (because every parameter is a line of code somewhere), but also increase performance because there is less detail to process in real time. I once had a project (a 436.8 MB file) that was nice and fast suddenly slow down when a new object created by someone else was imported. Turned out that the object contained a hundred some odd screws with a complex helix shape that weren't even visible from the outside. That made rendering take forever, and navigating the design layers was slow too when this particular area was visible. I put them on their own class (a case where classes were the way to go), turned that class off, and everything came back up to speed. I could just have easily deleted them since they were unnecessary for my purposes. So, you might have a large file where it turns out it is just a single object nestled deep inside a small symbol that's causing your slow-down.


A lot of this depends on the particular type of drafting you're doing, but in general, keep your individual object geometry as simple as possible, and only show those objects that are needed at any given time, and you should find that your file performance is nice and responsive.

Share this post

Link to post


One strategy I have used succcessfully which was causing problems for online Statutory submissions with large image heavy files was as follows and may be helpful. The starting files size was 34MB - Finished File Size was 558 KB . I had tried compression both on Vectorworks Tools and Online Pdf Compression but they didn't really reduce file size by very much. 




1. Screen grab the group of images from the Sheet Layer 

2. Import into Paint ( or Apple equivalent) and crop only the image selection 

3. Save to Project Folder 

4. Import the saved image back into Vectorworks Sheet and print / export  to pdf 


The resulting image quality was still very legible at A3 


While this may not solve large file syndrome for larger files to be worked on by others or for printing ( Dropbox / We Transfer ) may be better .


Hope this of some help as it was causing a real headache. 





Share this post

Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


7150 Riverwood Drive, Columbia, Maryland 21046, USA   |   Contact Us:   410-290-5114


© 2018 Vectorworks, Inc. All Rights Reserved. Vectorworks, Inc. is part of the Nemetschek Group.