Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

22 Great

About M5d

  • Rank

Personal Information

  • Location

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Something to check, which could be part of the problem, is that to make sure you have "Save viewport cache" selected in Document Preferences, under the File menu.
  2. That BricsCAD statement should probably be read, in part, as coming from their own situation. It would be preferable for NNA to provide their own detail, like the vendors below, for clarity at least, because I doubt the BricsCAD statement should be used to explain away some, if not many, of the apparent bottlenecks we experience in Vectorworks where multi-threading could alleviate the pain. For example, autosave is listed below, seems obvious, but if that was multi-threaded / backgrounded would we still have the perpetual 5 minute hiccup / beachball, particularly with large files, that we have now? https://helpcenter.graphisoft.com/knowledgebase/25850/ https://knowledge.autodesk.com/support/revit-products/learn-explore/caas/sfdcarticles/sfdcarticles/Which-function-in-Revit-will-take-use-of-multiple-processors.html
  3. Yeah, it seemed random to me too and, I guess, there's no guarantee this is the only thing causing Vectorworks to get "seriously" unresponsive, as you've described. But viewports, as a trigger, became predictable and reproducible, only because I was working a little differently to usual on an atypical project. The project is not remarkable, but it did create a hefty 1.2GB file by detailing the steelwork fully in the model, including the fastener tool. So this file as a precursor made it obvious, because after cutting a section and then creating a series of detail viewports, one after another, off of the sections, Vectorworks would consistently start its beach-balling and autosave apoplexy. I don't have InteriorCAD and I only have 16GB of RAM on board, which is probably a factor also, it just seems like there's a threshold with viewports, size, resolution and probably the model's detail, that pushes Vectorworks to a hard limit, then you need to manage it by frequently closing and reopening as described above. And, by contrast, it seems equally significant, that if I open the project and just work on the model, the behaviour doesn't arise.
  4. I've been running 2019 on High Sierra (10.13.6) for about 4 months now and I know the problem @Ride, so I don't believe this is a Mojave issue. Vectorworks also takes a very long time to close once this issue has started. My best theory is that it is, in part, to do with viewports and then Autosave and other processes getting bogged down with whatever is going awry. I find I can open and work for long periods on the model without this problem emerging, but as soon as I start creating and updating viewports, Vectorworks grinds into an unusable state with processes like the autosave having a prolonged stroke before the progress bar even starts moving. To keep working, I quarantine creating and updating viewports until necessary and then close and reopen Vectorworks after about every 3 or 4 of those operations.
  5. I think Julian means nested, or something like this: =IF((A1=1), 'Red', IF((A1=2), 'Blue', IF((A1=3), 'Green', IF((A1=4), 'Yellow', IF((A1=5), 'Orange', IF((A1=6), 'Purple', '?')))))) Though, I thought the limit was 7.
  6. That's a disappointment, I kinda thought 2020's new History-Based Modelling feature would have been built to address this. What's frustrating, is the PIO remains intact within the Subtraction, the data is there, worksheets just can't get to it.
  7. I haven't tested 2020 yet, I usually wait until SP3, but I questioned and wish-listed this last year. Hopefully, with this year being all about "data", it has been fixed!
  8. I think I know this bug, viewports appear to lose their class visibility / override settings after clicking through the 'Edit Design Layer' function from within an annotation space. Once you return to the viewport, things look pretty messed up. I suspect it's a graphics conflict, because the overrides don't respond after it happens, but the settings are still there. I stopped using it, but Martin is right, why have the function in the context menu if you're not supposed to use it? Fortunately, after panicking that my file had had a meltdown, I found a restart returned the override setting on screen.
  9. Yes, but this thread is even older.
  10. Nice to know. It is kind of clandestine however, I assume there’s a good reason for that? And that some caution should be exercised in reverting to older Service Packs?
  11. The graphic's 'glitches do seem to be getting worse, though many have been around for as long as I can remember; but this particular glitch, I find , only occurs once you've opened a second document and performed a few graphic's orientated actions in it.
  12. Coincidently, my renewal notice arrived this afternoon. From the FAQ's it links to, it looks like there will be a transitional arrangement for current MSA holders and the option to purchase an MSA for one last time. www.maxon.net/en/products/cinema-4d/new-in-release-21/faq/
  13. Yep, good teaser / feature. And since it has been mentioned, I would like know if there will be a coordinated approach from NV with Maxon on their licensing changes. I just contacted the distributor I purchase my Visualize MSA's from, and yep, Gerhard's right, the price is effectively double / year. *Edit (of course, you get the whole package, but that doesn't add any real value to what we used it for)
  14. Projects imported from 2018 are rendering differently in 2019, it appears the Environmental Reflection Saturation Level is stuck a 100% no matter how it is set.


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.

  • Create New...