Jump to content

Mark Aceto

  • Content Count

  • Joined

  • Last visited

Posts posted by Mark Aceto

  1. Looking at this, I may stay on Mojave (or Catalina) until I move to Windows:


    A visual comparison of macOS Catalina and Big Sur


    Cartoonish transparency, less contrast, more iOS... Federighi claims that making all of the app icons the same size ands shape "reduces fatigue" but the more everything looks the same, the more energy it requires to tell it apart. The Mac has always been about the OS (certainly not the hardware performance) but that advantage is diminishing.


    So another option in this transition to ARM is to transition out of Mac as they continually dumb in down for consumers (over serving their professionals).


  2. 5 hours ago, herbieherb said:

    Not even on the paper, and it throttles because of the iMacs form-factor to about 80% of its potential performance. In single-core tasks this iMac is about as fast as a stock cooled Ryzen 7 3700x. And as always Apple wants me to pay the full price of the i9-9900 in addition to the price of the base configuration. But yes, in a Mac centred view you're absolutely right.


    For clarification, the fastest Mac right now (the OP is about "Mac Silicon OS", so I didn't think to clarify that).

    • Like 1

  3. On 7/3/2020 at 3:14 AM, SteveJ said:

    Mark, we look forward to our  Developer Kit arrival on July 7!


    @SteveJ that's great news! Please keep us informed how VW 2020 runs using Rosetta 2 on an ARM Mac.



  4. 2 hours ago, Don Seidel said:

    I'm 60. Been doing CAD on the Mac for some 35 years or more. VW since MiniCad 4 (I think).


    Speaking of Macs only, not PC's or Hackintoshes......Certainly some purchases are better timed (new machines always coming)  than others. Certainly some machines are better ROI than others. But it's an eternal moving target.


    Whenever it's time to upgrade, I buy the fastest machine I can reasonably afford. SO usually it's within 15-20% of the most extreme available. I've never bought the absolute top-of-the line because of this (except....) You pay a high premium. I sold my iMac Pro after 6  months because the performance was not near what I expected.


    My exception to max purchase is my 2018 MBPro, which replaced the iMac Pro. It was a much better setup for me to have a portable personal machine, a 34" monitor w/ eGPU. Sure it doesn't render as fast as the iMac Pro, but I spend perhaps less than 5% of my time rendering anything beyond OpenGL




    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.


    • Like 3

  5. 6 hours ago, herbieherb said:

    stop kidding 😄


    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.


  6. On 6/23/2020 at 6:17 PM, M5d said:

    @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?      


    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 own).
    • The last Macs that will allow me to install Catalina will be released until 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 (a truly best case scenario that some users don't seem to understand for whatever reason). It's safe to assume that all developers and manufacturers (think drivers) 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 SNAFU 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).


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




    • Like 2

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


    • Like 1

  8. On 6/23/2020 at 5:12 PM, designedAF said:

    Wait, you think you're going to be supporting ARM mac's this Fall?! That's incredibly awesome news.  


    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?


  9. 6 hours ago, Andy Broomell said:


    So I have a relatively important question regarding this, having played around quite a bit recently with current methods of getting a Vectorworks model into Unreal (via FBX).


    When this new integration debuts, how are we expected to work on UV maps? Unreal Engine, as fabulous as it is, doesn't let you edit UV maps, as it's expected that you finesse those beforehand in your DCC (digital content creation) software, which in our case is Vectorworks. There is currently no capability to edit UV maps in Vectorworks, so unless there's some additional UV functionality coming, I'm not sure how a link with Unreal will be usable?


    It's important to note that Unreal relies on well-constructed UV maps not only for texturing, but for lightmaps and shadowmaps as well. All UV-based.


    I want to make sure the folks working on this connection with Unreal are thinking through a complete workflow, not simply the file connectivity aspect which alone might not lead to usable results.


    That being said, I'm really looking forward to further progress in this direction. Thank you for opening up more avenues for us!







  10. 1 hour ago, Sam Jones said:

    Which dimension is the "length"?  The greatest?  What about height?  There are objects that have a greater height than length.


    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:

    1. 6' long folding table (incorrect)
    2. 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.


    • Like 1

  11. 3 hours ago, scottmoore said:

    Again, in my opinion, the “wash”, “incandescent”, “moving light” etc. classes are completely superfluous and serve no viable purpose, especially now that your profile lights and wash lights might very well utilize LED engines. 


    That is specifically what I was referring to because of this issue:


    21 hours ago, James McConkey said:

    This leaves me with having to have 3 different classes visible to render things properly(My class "FOH lights", the hidden class of "lighting-incandescent" and "None").


    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.


  12. On 5/20/2020 at 1:10 PM, James McConkey said:

    This leaves me with having to have 3 different classes visible to render things properly(My class "FOH lights", the hidden class of "lighting-incandescent" and "None").



    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.

  13. @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!


    • Like 1

  14. At this point, it makes more sense to use a MacBook Pro for your daily driver (and to take onsite), a Windows workstation for drafting/design work, and Synergy to connect the two. Every year, we keep hoping praying for the Mac situation to improve but the carrot stick keeps moving further out of reach. There are no signs of Apple making peace with NVIDIA or offering an AMD CPU in any of their "pro" models, and they're about to kill support for OpenGL while Vectorworks has not confirmed support for Metal.


    • Like 1

  15. @trashcan although living outside VW, you may want to check out: https://www.mappingmatter.com


    Oftentimes, I'll be working with a designer that's working in Mapping Matter, and I'll take that info into VW for prepro, rigging, plotting, paperwork... 


    Ultimately, it would be amazing to have the functionality of all three tools built into VW, and the guys to do it are in this thread, so fingers crossed... 


    • Like 1

  16. 10 hours ago, trashcan said:

    Is there an option to remove the screen and project on to walls or other surfaces? I see there are a bunch of workarounds to achieve this but wondering if there have been any improvements in VW2020 (the excellent plugin ProjectionViz solves this)


    See attached screenshot for OIP settings (works with blends too):



    • Like 1


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