Mark Aceto

@SteveJ that's great news! Please keep us informed how VW 2020 runs using Rosetta 2 on an ARM Mac. EDIT: Also, I suspect the focus for now will be on compatibility vs performance because, as Craig Federighi put it, the A12Z is the chip "when Apple isn't even trying". BTW what's the GPU in that thing?

We're in the same boat. My eternal frustration with chasing the Mac dragon is that it's a neverending game of feature Whac-A-Mole. In fact, it's not "features", it's capabilities. It's like trying to buy a Toyota. If you want a sunroof, you have to buy package 5 but package 5 only comes in the color Baby Blue. So I bought a Jeep. The Jeep version of computers is a PC. I can throw an AMD Ryzen CPU and NVIDIA RTX GPU in a 2-year old machine today, and it will be supported (with a minimal amount of mods). Meanwhile, Apple won't license their OS but they also refuse to update their hardware or work with certain suppliers. Do I want a computer that's capable of 4k @ 60Hz? But do I want to have to unplug the USB-C cable/dongle throughout the day because my display is HDMI? Do I want an OS that supports NVIDIA cards? But that puts me in a Thunderbolt 2 machine unless... the 2017 iMac will install High Sierra. But would I rather have a "headless" Mac? Well that's the Mac Mini. But it doesn't have a discreet GPU, so I have to use an eGPU... And how about when Unreal releases UE 5, what will Twinmotion's GPU requirements be a year from now? They've already made it clear that the RTX 2080 is the card of choice today, so... I could build a Hackintosh but how long will that work after the ARM transition? And that's not to mention 32-bit app support, will 3Dconnexion take a year (and multiple updates) to fix a driver that Apple broke with the T2 chip, the POS Touch Bar, the imminent end of OpenGL (and which 3D apps will choose to support Metal), and myriad other features capabilities that Apple has killed off (and is about to kill off in the continued iOSification of the Mac). In the past 3 years, I've tried a 2012 cheesegrater, a 2017 iMac Pro, and a 2019 MBP. Today, I'm typing this on my old 2014 MBP because it just works with everything (and I'm not drafting anything this summer). Which is why I keep going back to the idea of using a MBP for your daily driver (and to take onsite), and then just build a Windows workstation for 3D work.

Check the link in my post. The 2019 iMac is the fastest single core clock speed machine right now. VW maxes out at 3 cores for most non-rendering tasks, and many operations will always be single core by their very nature (not a limitation of old code). Before that the 2017 iMac was king.

I'll let VW speak for VW but as someone who obsesses over this, and has learned from my Mac purchase mistakes in the past, these are the considerations I'm weighing right now: The last Macs that will allow me to install Mojave on them are in the past (in my case, the ones that I already one). The last Macs that will allow me to install Catalina will be released between now and September. There are some eGPU benefits to those machines over Mojave. However, eGPU's are a mixed bag, and will hopefully be rendered (pardon the pun) useless 2 years from now when the ARM transition is complete, so throwing down $2,000 for a Radeon Pro VII might not be the best ROI. Long story short, I'd be better of putting that $2,500 all-in eGPU investment into a 16" MBP for real world GPU gains with most 3D design apps (plus I wouldn't have to lug the eGPU onsite; assuming I'll be onsite before the ARM transition is complete). VW's annual upgrade cycle is generally in sync with Apple, so they're both buggy / stable at the same time as they move from .0 to .3+ updates (best case scenario that some users don't seem to understand for whatever reason). It's safe to assume that all developers will be playing catchup to varying degrees with Apple throughout the next 2+ years of transition. Jony Ive is long gone, so it's a safe assumption that we won't have another 2016 MBP calamity on our hands but still... "Third time is a charm". Apple has moved iPhones to a 3-year product cycle. Year 3 is always the most refined / stable version. It's safe to assume that the first ARM Mac's will be less refined /stable than their successors. Keep in mind that it looks like the iMac and some other Macs that haven't been updated in forever will also receive the "major" physical redesign which typically has a litany of kinks that needs to be ironed out ("You're holding it wrong!") Therefore, the sweet spot to me looks like a 2019/2020 Intel Mac until the transition is complete, and then buying a 2022/2023 ARM Mac. For me, that's tricky because my options are staying on this 2019 MBP Pro with a weak GPU (and possibly adding an eGPU), crap keyboard (and definitely adding a wireless keyboard)... Or ponying up for a 2020 MBP with a ridiculously overpriced GPU running Scatalina (during a recession with no work in sight). One other minor consideration that could save some $$$ is that Thunderbolt 3 is about to be replaced by USB-4 (same connection) on ARM Mac's, so we no longer have to pay the Mac/Intel tax for T3 devices. A new monitor just needs DP or USB-C. If you want T3 for now, that's great but just know that it's going to go the way of the Dodo just like FW800, FW400, and whatever came before that. Final thought, the 2015 MBP is a legend. The 2017 and 2019 iMac's are the fastest machines for running VW (including the new Mac Pro). So, while we may have ARM-envy during the transition, we also have perspective: buy the last version Apple release before they f*cked sh*t up for the next 2-3 years. Final final thought: I may be f*cking 50 before I finally have a Mac that runs like I've needed it to since 2004 (and I'm not even counting the ones I used in the 90's), so I'm asking myself some real career-changing questions during the pandemic... Therefore, what I want to know is will VW still be stuck on 3 cores because of some old library before I turn 50? Because that will be the tipping point for me in this waiting game.

@SteveJ and @JuanP by the end of summer, I'd like to know which Mac operating system Vectorworks 2020 will perform best on: 10.14.6 10.15.6 (currently in beta; expecting multiple Supplemental Updates with loads more bug fixes) 11.0+ (currently in beta; expecting the .0 release to be buggy, so realistically between 11.0.1 and 11.0.3) Reading between the lines, a lot of us are still on Mojave because it's stable (keep in mind that it wasn't until .5 or .6), so we're wondering if we should stay on the most stable release of Mojave, or upgrade to the forthcoming most stable release of Catalina (after they squash the remaining bugs in "The Third Act" of software maintenance on an annual release cycle 😉), or skip Catalina*, and jump to a predictably less stable version of Big Sur. Normally, I would never even entertain the thought of upgrading to a new Mac OS until the .6 release but it's hard to tell if the reason Catalina has been so problematic is because Apple hasn't gotten around to fixing the bugs until now, or if Apple was tired and bored of dealing with OS X, and put their energy and resources into OS XI. All things being relative, it's quite possible that the final version of Catalina will be just as stable as the final version of Mojave (I didn't mean for that to sound sarcastic but the irony is not lost on me). *by skipping Catalina, I don't mean literally. I learned from experience that even if I'm only on Catalina for 1 day, the best practice is not to skip a generation because Apple moves / adds / deletes... files and folders, so if you skip a generation, you might have a bunch of files orphaned where the OS doesn't talk to them anymore. Best to let the OS "touch" everything (same applies to a clean install).

No, they'll support Big Sur which will run on either Intel or ARM (so, in this context, Intel). @SteveJ how many Mac Mini A12Z Developer Transition Kits have you guys rented so far?

You mean like it used to (before they changed it in v2015 or whenever)?

Upvote.

What's the length of bridle L1 or L2? What's the depth of an X4 Bar 20? How long is the stage? In all seriousness, is there a standard for these measurements dim's in software development, industry design, or even in the real world? Seems like the architecture world would have solved this system... There are 2 types of people in this world: 6' long folding table (incorrect) 6' wide folding table (correct) I think it's safe to say "length" is the most ambiguous way of describing any measurement that could be H, D, or W. Sorry for the deep long reply.

That is specifically what I was referring to because of this issue: For clarification, never mess with Bracewurst classes. If we want to take the conversation of best practices a step further, I would suggest creating a blank template file, and adding your own classes. This would: Eliminate the classes created by PRG ATL that may be superfluous ("event" seems to mean "site") When importing symbols that add their own embedded classes, you can make a more intelligent choice about whether to keep them or not: Delete the superfluous lighting, ceiling, furniture classes Keep every class that a truss, hoist, rigging symbol auto-generates Creating your own template file, classes, libraries (of your own favorite custom/edited symbols)... will also help to create Saved Views in that template file. All of those things combined will reduce the incessant clicking, hunting, and pecking required to get the job done. Note: using the Tools > Purge command will allow you delete objects and classes that you definitely want to keep. Chief among them, anything related to rigging—particularly vulnerable are 2D and 3D horz and vert truss objects, hoist parts and classes... Honestly, it's a bug that should be reported to VW engineering.

Delete each class that you don't want. A dialog window will pop up asking if you'd like to delete the class entirely or move those objects to another class. Select the lighting class you'd like to move them to. I guess we all left out that step but we were all thinking it. That's how you thin the herd (of the class parade). Just to reiterate, there's no advantage to, or best practice of, keeping those autogenerated classes around unless you're an architect.

@James McConkey Rob answered the question of how to restore the class but to echo what Scott is addressing (pardon the pun), those subclasses are generated in the same way that adding a door or window will auto-generate the Ceiling-Main class. Same with furniture and a bunch of other symbols in what is affectionately known as turning on the "class parade". While device/instrument type is useful in Lightwright paperwork, I don't know any designers or electricians that organize their classes that way (vs the myriad other ways). Those sub-classes are artifacts that are about as useful as the vestigial arms on a T Rex, so most people just nuke 'em. Add to that the west coast vs east coast vs film nomenclature, and you've either got an incandescent or a conventional or a practical fixture... but a Mac is always a Martin, so purge away!

@zoomer sounds like DirectX for Windows, and Metal for Mac but he also used the words “low level” for Metal, so that doesn’t inspire much confidence.

@JuanP would be great if Vectorworks also had a product board portal broken out as: Under Consideration In Progress Released Love how the Submit New Idea section has the option to tag as: Nice to have Important Critical Seems like some of the new features in 2021 are nice to have while we’ve been begging and pleading for critical features and fixes for years.

No baking required: A first look at Unreal Engine 5