Jump to content

M5d

Member
  • Content Count

    360
  • Joined

  • Last visited

Community Reputation

31 Great

About M5d

  • Rank
    Journeyman

Personal Information

  • Location
    Australia

Recent Profile Visitors

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

  1. www.macrumors.com/2020/08/24/apple-epic-court-battle-august-28-removal Looks like this dispute will be kept in check for the short term.
  2. The Epic versus Apple (and then Google) dispute has been in the mainstream media here in Australia. The dispute 'was' confined to the App store arrangements, but that was last week, now Architosh has added comment . . . architosh.com/2020/08/apples-threat-to-epic-will-hurt-mac-pros-in-aec This analysis is a little alarmist, right? Everything is going to be cool on the imminent Direct Link to TM . . . right?
  3. Yeah, it's a weird bug. We couldn't replicate it on two different computers with the same OS and VW versions, so it may be specific to certain graphics setups or something similar. Could be why you're not seeing it in SP6 Boh and Jens is.
  4. I had this issue in SP3, Julian couldn't trigger the bug on his own computer so it never got properly identified. After a lot of messing around, I found the issue went away if I undocked the snapping palette, it's worth a try! When SP4 was released, I could dock the snapping palette again without causing the bug, SP5.1 is working ok also.
  5. Information on the transition, particularly information that helps with navigating near term hardware purchases is what I'm hoping for here. Apple always makes timing a bit tricky, plus it appears the whole GPU rendering thing is finally coming to fruition on both the hardware and software sides of the equation. There are some interesting general discussions around ( GPU Rendering Thread), but they tend to go off on tangents. So I'm keen, which I think was the OP's intent, for any info / discussion, particularly from NV, that helps inform our mac orientated decisions.
  6. @SteveJ That is promising. I know it's to early for definitive answers about this transition, but a slightly different question; how long did VW support universal binaries after the last transition, and would that period likely be longer this time? I ask because, from the general commentary so far, it's assumed the more powerful machines will likely be the very last to switch over to Apple's own Silicon. That's going to leave the intel macs as the primary / better option for those needing to upgrade over the next 18 months or so. The length of the "universal" period would make the difference between whether to grab a regular iMac as a stopgap, or whether to purchase as planned?
  7. I like the approach they're taking for gauging user support / interest in new features.
  8. Ok, the problem is definitely new in 2020 then, 2019 is still working as expected.
  9. I'm still waiting for SP3 to make the move, but could it be you've hit the order button in the top bar without noticing?
  10. I wonder if this thread, https://forum.vectorworks.net/index.php?/articles.html/articles/vectorworks-operating-system-compatibility-list-r533/, is definitive, or more a statement of intent about compatibility when it comes to the current editions, 2019 and 2020.
  11. The content in this thread really needs a dedicated home! Something more, possibly of interest; while trying to find some use based info on the graphics options Apple's offering, I came across this AMD guy instead; Brian Savery, who's starting a series on Pro-Render. Twinmotion Unreal gets a mention in the opening video, which possibly explains why the next version is still pending. When TM 2020 does arrive however, the videos he's promising could be handy for in-depth tips on the renderer underneath.
  12. 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.
  13. 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
  14. 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.
  15. 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.

 

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...