Jump to content

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

Link to comment

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?


Link to comment

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
Link to comment
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
Link to comment

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.

Link to comment
  • 1 month later...

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.

  • Like 2
Link to comment
  • 11 months later...


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. 





Link to comment
  • 6 months later...

Degrade high-res images to what you will see printed, an oil paint filter in Gimp will do the trick and looks less pixelated that simply changing image resolution.


With huge images I tile them and class each tile to a different class. AFAIK VW includes all information in a viewport including information outside the viewport frame - which is stupid really. This way page size can be reduced a lot

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...