Seth Thomas

Every workflow is a bit different and my situation certainly doesn't match yours exactly, but I thought I'd share the auto save procedure I've developed over the years that works very well for me at the moment. I make heavy use of layers to organize multiple versions and various parts of a drawing, and all my symbols remain in the file for the duration of the project. I do mainly trade show design, so most of my jobs are based on show cycles that repeat on a yearly or bi-annual basis. Each cycle is based on the previous unless we're doing a complete redesign, so the 2020 file is a copy of the 2019 file, which was a copy of the 2018 file, etc. I will generally purge the new file of unused resources from the last year, but those resources remain in the old plan, so those act as a backup. For the duration of the project I keep one backup every 15 minutes in the same location as the original. I used to keep more, but because I never delete resources from a file until purging before the next show, there is really nothing to lose. That means if I do experience a crash (which is rare, as I will explain in a moment), I never need to go back more than one backup, therefore is no reason to keep more than one. There is nothing in a 30 minute old backup that's not in the 15 minute version, and if I accidentally purged something I need it's in last years file. So my total backup file size is just that one file. As for crashes, I used to experience them so frequently that I once wrote a haiku about them, but no longer. There are often crashes that accompany upgrades, or anomalous behaviors that Vectorworks is famous for (some time ago my rig crashed every time I selected a blue fill from the menu, though it worked fine if I typed in the RGB number), but those are eventually fixed through a service pack (usually), and we can put those aside. I find that the crashes in our office mainly occur due to the user asking too much of the computer in one shocking moment. That's not to let VW off the hook. They should be able to let you know that you're overloading the system and stop your process without crashing the entire program. But I did find that crashing practically disappeared when I began diligently organizing my file into manageable visibility chunks, used Saved Views to navigate them, and kept my geometry as simple and streamlined as possible. If you ask the computer to manipulate too much geometry all at once, it will likely crash. Ultimately, I find that exquisite organization is the key to a happy Vectorworks experience. I described the details of that in an other thread that I participated in some time ago in relation to keeping file sizes manageable (see link below). Another thing I noticed is that auto saving itself can cause crashes, I think when it tries to save while in the middle of some process. So, auto saving too frequently can be a problem because it creates more opportunities for a crash.

Thanks @fabrica for posting the screenshot. This is exactly what I am talking about. I need to un-check that box.

When I create a sheet layer viewport which displays a mixture of internal design layers & design layers containing referenced viewports, the layers with referenced viewports are not visible when a crop is applied to the sheet layer viewport. When I remove the crop, the referenced viewports re-appear. This is another exciting new feature/bug of VW 2019. Anyone else seeing this, or know of a solution? Right now I'm using a hack workaround to mask what I would usually crop.

Hey @zoomer, Your describing the specific situation I was talking about, and yes, I can see the value there. If I used textures that update frequently and needed that reflected in my drafting, I can see it being very useful. I use references for similar reasons elsewhere. My main point is: Why isn't it optional? and why is it the default? After all this time, to suddenly make it default without explanation is... I was going to say odd, but I guess it's not that odd for this company. I really just want to be able to change it, and I'm wondering if anyone knows if and where this setting might be found.

Whenever I add an image to VW 2019 it comes in as a referenced file instead of importing. This never happened in previous versions. While I can sort of see how this might be useful in some specific situations, it definitely isn't in mine, and I find it quite obnoxious as my job uses tons of graphics. Does anyone know if this is a setting that can be changed and where that might be located?

Just adding to the chorus. This happens to me all the time. I'm running 2019 SP2. Refreshing the view one way or another usually makes things reappear eventually, but having to work around glitches constantly makes my already fast paced, high demand job even more difficult. Agreed, though I can't say I've never experienced this from VW. Things like this happen with every release. Hard to say which version has been worse, but I often describe the latest VW releases as Betas that should have had a half-year of practical testing before release. I'm getting very tired from the very real amount of time I spend troubleshooting when I should be done with my job and relaxing instead.

Thanks @Jeremy Best. VW offers many great mysteries to test my troubleshooting skills, though I would much prefer if it just worked. That's another interesting case. There are many moving parts that can have issues. Sometimes we just have to start from scratch and let go of the desire to know why.

I found another user who had the same problem. Good to know it's not me.

You're welcome.

Did you migrate your settings? Check your default compression setting. I just went through this and figured out that if it is set to JPG the rendering turns white, but PNG works. I had a discussion about it here:

It's the default compression setting. It works in PNG mode, but creates a solid white render in JPG mode. I use JPG because they are usually smaller file sizes and we use A LOT of graphics, so I do what I can to keep the overall file size small. When I migrated my settings the first time, it brought with it the JPG setting. Reinstalling initially fixed the problem, but when I went through and manually setup my preferences, it came back. I deduced that it must be one of the settings, so I decided to go through and test them all one-by-one. Fortunately my first inclination was the correct one, and it didn't take long to figure out. Now I can toggle the problem on and off by changing the default compression setting. Glad I know now, but this needs to be fixed. I don't really understand why PNG is an option anyway since it is intended for the web, not for print. If I could get a proper CMYK output from VW I'm sure my prints would look much more like the screen, but I digress.

OK Jim, so I have a clue. I just uninstalled and re-installed 2019 after which rendering worked as it should. The same files that were displaying the symptoms I described above rendered properly. This worked multiple times on both computers. BUT, there is one thing that I did differently. The first time I installed the software I used the Migration Manager to move all my settings across. That is when I had the rendering problems. This time I skipped migrating my settings and everything rendered as it should. It still flashed and made me think it wasn't going to work, but in the end the rendering was persistent. Then I ran the Migration Manager on the newly installed VW and the rendering problem returned. I can't imaging what the specific problem could be, but it has something to do with the Migration Manager. I also tried rendering after installing 2019, but before installing SP1.1. The rendering was OK, but the black squares were there. I discovered that refreshing the sheet by pressing command-4 fixed the black squares, but it also looks like SP1.1 may have fixed this also since I do not see the squares after that update. Another oddity: I'm pretty sure the first time I installed and migrated my settings, VW did not ask to update resource libraries. The second & third times, when I did not migrate, it did ask to update resources. Could this be related? Are the resource library settings stored in personal settings? While I'm super annoyed that I can't translate my custom settings over (because I customize practically everything), I'm happy that I've figured out how to make 2019 work. Hopefully that's a clue you can use to figure out what's going on, and pass along to anyone else who has the same issue. Thanks for your help.

Unfortunately, I do not have permission to send any files. Everything I work on is confidential and I would certainly be fired if I let information leak, even for something like this. I've asked before. Sorry, I know your trying to help, and I appreciate it. I may try an uninstall and fresh re-install.

I've done this on multiple files with multiple machines. I've restarted the application and rebooted the computers. I've also tried re-converting files from 2018 to see if the file somehow became corrupted during conversion. No luck. I have a Mac Pro (Late 2013), 3.5 GHz 6-Core Intel Xenon E5, w/ 16 GB RAM running macOS High Sierra 10.13.3 and a MacBook Pro (Retina, 15-inch, Mid 2014), 2.8 GHz Intel Core i7 w/ 16 GB RAM running macOS High Sierra 10.13.2 I can't send a screenshot because since the SP1.1 update it never even gets to that point. Since then, the viewport goes completely white when the rendering is complete (I also have to be very careful about sending anything because I work for a very litigious company with a lot of trade secrets, but I will provide as much info as I can). To describe it though: As I'm sure you know, a camera rendering starts in the center of a viewport and renders out squares in a bit of a spiral pattern until it reaches completion at the edges. In my case the final few squares at the edges would remain black, to differing degrees for different attempts. I'll also note that, unlike 2018, my 2019 makes the entire viewport black before the image begins to render, then flashes the entire viewport white occasionally as the render progresses.

Just installed SP1.1 and can confirm that it did not fix the rendering issue I mentioned above, and in fact it is now worse. It now goes straight to a white viewport when rendering is complete and never gives a finished view. Very dissapointing since @JuanP stated that: Three of the five items listed above relate to rendering, and yet RENDERING STILL DOES NOT WORK. I can work around annoying glitches, but if I can't render than the whole program is useless.

This is happening to me as well, but I'm still on High Sierra 10.13.3, so it's not strictly a Mojave thing. As @Tom Klaber mentioned, it's not technically random, but it is definitely wrong, and very disconcerting. I know this thread is about Mojave, so I don't want to go to deep here, but another issue I've experienced is: If I render a camera viewport on a sheet layer it will render correctly the first time, but when I switch to a different sheet, then return to the sheet just rendered, it presents as a fully white viewport. Then, when I re-render the viewport it will render about 95% and leave black bars for the final few blocks. The percentage & location of the black bars changes with each subsequent render. Then, when I leave the sheet and return, it presents as white again. It's not just a screen refresh thing either because it exports this way also. It also flashes while rendering, which almost gives me a siezure. I've had 2019 for less than 24 hours and it's already a huge disappointment, but that was to be expected. For every one thing they fix, they break something else. These releases are barely ready for beta, let alone an official release. And even after SP2 of any given release, many issues are never even addressed. I know of no other major software with problems of this magnitude. It's very frustrating.

Anyone else having issues working offline? Since the 2018 release (maybe 2017; I skipped from 2016), using working files offline has some absurd problems. There are too many obscure issues to list (or remember at this moment), but here area a few: Can't draw a rectangle Can't create a group Can't create a symbol And many more that are so simple and fundamental to drafting that I'm astounded they haven't been fixed. My schedule is so full that I rarely have time to post here, or I would have months ago, but I finally got the chance. I work offline all the time, so this is a big one for me. I spend way too much time these days working around VW problems. Is anyone else experiencing this, or is it just me?

No, my HDD was plenty big enough. I've actually resolved the issue since then. Turns out it was the OS. I don't have all the details, but it seems that Apple changed the way it manages VM in High Sierra as compared to Sierra, and VW 2018 is using this new process, which caused my memory problem. Upgrading to High Sierra solved my problems. In my case I actually had to upgrade my entire computer because our IT department would not install High Sierra on my old Mac Pro Tower, so I ended up with a relatively new cylindrical Mac Pro. Anyway, problem solved.

I would love to see the Replace With Symbol… command offer the option to keep the user input scale. Right now, when I replace a symbol who's scale I have modified, it reverts to none. This is an action I perform all the time, and having the symbols revert to none forces me to re-scale everything, more than doubling the amount of time the operation should take. Also related, let's combine Replace... & Replace With Symbol... Perhaps there is a reason for two seperate commands, but I have yet to figure out what that is. Combining those, and expanding the dialog to allow all the various options (class, record format, etc.), as well as full access to the resources browser would be fantastic.

Yep, that works too. When setting a 3D view I always make the look-to and view heights the same, but not usually with the camera, so I hadn't noticed. Doesn't make sense for a camera to produce parallel lines, but from a practical stand point in VW it's definitely good to know. Either method is a good workaround, but a proper 2 point would still be nice. Yeah, this applies to the Pan, Flyover, Translate and Rotate tools also.

Just tried this, and yeah, it creates a perfect 2 point perspective. All my verticals were 90º. Thanks for the great tip. So it should be no problem to add this to the camera functionality. This is a good work around, but I would still like to use it from the camera tool in order to take advantage of it's options and adjustment capabilities. I find the walkthrough tool very cumbersome.

Yep, makes sense.

For visibility, I think this depends on your Creation Options settings, but yeah, that makes sense for attributes.

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.

I think @Tom Klaber & @Rob Books are stating the real crux of the situation. I setup a master list of classes for our Workgroup in Standards.vwx, which is also pre-loaded in our templates, so rarely need to create new classes. When I do, I find the easiest way is to simply create a new class and carefully name it to appear where I want it in the classes list. Duplicating works too, but I find little advantage to that over starting new because I would have to right-click once to duplicate, and once again to go in and rename it. Creating new brings me straight to the naming portion without additional clicks.