Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by M5d

  1. M5d

    Worksheet bug?

    Thanks Pat. Submitted the bug form.
  2. There's a bit of info on when Twinmotion will officially support the M1s at the bottom of this page: twinmotionhelp.epicgames.com/s/article/Path-Tracer-Requirements? Could mean officially supported under rosetta though, unless the unreal engine also happens in the same timeframe.
  3. M5d

    Worksheet bug?

    This is not new, but I assume it is a bug. When you try to call cell contents from latter rows, to perform a function or not, nothing returns. When you call cell contents from an earlier row, the result is as expected. Example attached. Cell Order + Bug.vwx
  4. If I'm understanding the HIP article correctly, AMD is providing the means for ending the proprietary, CUDA, divide between the platforms. Which, presumably, will solve this problem for developers, like Redshift, from a single code base into the future?
  5. I don’t expect Maxon will include the M1s in the Vultures chart until they have the block size optimised in the benchmark for these chips. Unfortunately there are software optimisation caveats, particularly with the graphics in the M1s, for most types of testing available at the moment. Less officially, a video posted in another thread suggested that increasing the bucket size yielded an improvement of about 25% in an alternate render. If that’s real and consistent, the M1 Max would be positioned at about 7.30 on the Vultures chart above. Treat that with caution however, it’s a single result mentioned at around the ninth minute in the video below.
  6. You'd expect Apple's assistance with supporting AMD cards on macOS would aid somewhat in supporting AMD on the PC. @trashcan, I've been watching in the Redshift forum for M1 Max results, as noted in the link above, Redshift "isn't as mature" on mac / metal yet and there appears to be a couple secondary issues with the way their Vultures Benchmark works on the new chips, nonetheless there's an M1 Max result posted for Vultures; currently it measures about 5% better than a single MPX W5700X in the Mac Pro. Whether that's objectively good or bad in a laptop, I don't know . . . Maxon's comments . . .
  7. I think this is a very old problem that moving to 64 bit did a lot to lessen, but wasn't completely resolved. I also find section and detail viewports to be the main cause. Something interesting about those viewports is, if their crops are stretched or deleted after they're established, the Hidden Line line-work for the rest of the model is already there, calculated and available without updating.
  8. In a week or two there should be a flood of information and benchmarks evaluating the new machines and their chips. Of interest though, Vectorworks and Redshift (Cinema 4d) both make an appearance in Apple's marketing, so we may see NV do their own write-up on the performance of these new machines. The 4x performance of the Apple M1 Max, compared to the Radeon Pro 5600M, in Redshift is particularly interesting . . .
  9. The problem with switching from WinDoor to NV's tools @Matt Panzer, is you cannot do it in a progressive way. As soon as you replace the tools at the front end of the building model, the entire BIM workflow structured behind it also needs updating. NV should appreciate what that can entail, because supporting custom BIM workflows has been a key aspect of the "Vectorworks Paradigm". All we really need is for the plugins to overlap by at least a year, or two (because it's preferable to remain behind the current release), so that all the "required" parallels between WinDoor's plugin information and NV's plugin information can be adopted and tested for demonstrating various window and door related compliances in our Building Code. We pull a lot of data from WinDoor, along with data we embed in WinDoor symbols, into calculations, which, as stated above, Julian has generously tested and tuned WinDoor's output for since the introduction of DTS Energy Efficiency into our Code. The benefit we gained from building DTS calculators inside of Vectorworks, was quick, efficient, feedback from the model. Ripping a root element, one of the most involved elements in this case, from the base of the Building Information Model, tossing it and replacing it with a "foreign" entity doesn't represent a minor tweak, but a considerable rework of established custom BIM workflows. NV has acquired OzCad's IP, but some allowance and accomodation of practice based tools developed downstream is needed, to make a transition possible and for feedback, if necessary.
  10. Not sure that explains why things are the way they are Pat. NV confined / quarantined WinDoor to the Australian and NZ markets a long time ago, so it has essentially become a localised customisation / plugin, which is why what's potentially happening is somewhat problematic. As for the features, types and aspects of the fixtures / hardware WinDoor has accommodated over the years, features which Vectorworks' default tools may still lack, Julian's WinDoor plugin cannot hold IP over any of them; they are generic, operational, industry wide attributes of the fixtures / architectural hardware themselves. NV's failure to address commonplace architectural elements, or failure to faithfully represent aspects in their own plugins, can only lead to conclusions about NV's priorities really, not the incentive, or disincentive, of Julian's plugin.
  11. Might have missed it in your answers @Matt Panzer, but I was looking for an indication on NV's intentions with the WinDoor plugin. Is WinDoor effectively counting down to being made a legacy plugin? Remaking the default tools with, I would hope, "all" of WinDoor's features is in no way negative; but I'm inquiring about WinDoor because of how extensively it is built into my workflows, and likely the workflows of many Australian and NZ based practices. It has been, very much, our default and trying to exorcise it from templates, many types of worksheets and crucially DTS energy efficiency worksheets, not to mention the loss of custom library and style workflows, is massive. Over the last couple decades Julian has been fantastic at building and tweaking user requested features, addressing bugs on a dime, and making WinDoor a key asset of customised, efficient, BIM here. A dynamic I'm sure you'd understand @Matt Panzer, but a dynamic NV could not emulate, even if it wanted. Put simple, many of us grew into our BIM workflows with WinDoor, and WinDoor, aka Julian, was prepared to grow it with us! It will be a tragedy in one respect and a calamity in another if NV's intention is to junk the WinDoor plugin for scraped features any time soon.
  12. I assume NV was well aware of this prior to the acquisition @Matt Panzer? The Vectorworks blog gave this move a positive spin, and making WinDoor more widely available also implied a future . . , but from your 'Vectorscript' comment, it sounds as though WinDoor is effectively counting down to being made a legacy plugin? (Apologies for posting in two places, was following another thread where this came up.)
  13. Thanks @E|FA. I assume NV was well aware of this prior to the acquisition @Matt Panzer? The Vectorworks blog gave this move a positive spin, and making WinDoor more widely available also implied a future . . , but from your 'Vectorscript' comment, it sounds as though WinDoor is effectively counting down to being made a legacy plugin? https://forum.vectorworks.net/index.php?/topic/77920-can-we-have-a-statement-on-the-windowdoor-tools/
  14. I haven't seen this stated or implied anywhere, but having used OzCad's plugins for so long, I'm curious what the plan is?
  15. I'm hopeful for greater stability / gentler progress now that they've shifted to their own silicon. It seems much of the OS's changes over the last decade was about prepping for this.
  16. https://www.vectorworks.net/support/bugsubmit For future reference.
  17. Umm yeah, where has it gone?
  18. You managed to solicit these replies in the original Roadmap thread:
  19. This video covers general RAM testing on the two M1 options, his testing is pretty helpful, but it's not CAD specific is the only caution . . . P.S. His conclusions are indexed in the timeline. Other M1 videos / comparisons by the same guys: www.youtube.com/playlist?list=PLo11Rczpzuj2XcB5VdnAbbMyB3m57teOD
  20. And a little more to back up the above: architosh.com/2021/04/apples-new-m1-imacs-are-they-fast-for-cad-3d-users The rubber will hit the road, and NV, once we see the next tier of Apple's line up, hopefully with a preview at WWDC in six weeks. This would be consistent with the way Apple has introduced their Pro level machines over recent years. And with the iMac Pro already discontinued, it seems even more likely they'll do it again this year.
  21. Maybe Mac Catalyst will evolve now, so that bringing mac OS Apps (once they're A/S native) to the iPad, is as efficient as porting iPad Apps to Apple Silicon Macs. It appears they're heading that way, with the iPad Pro being made to appear, more or less, as capable as a desktop.
  22. Interview with Maxon & Lunar: www.youtube.com/watch?v=MCqdm_5Tayc
  23. Almost forgot, there is another factor in the mix that @JuanP may have overlooked?; that's additional performance boosts Vectorworks will receive when it supports Metal and shifts to natively supporting Apple Silicon. A quick cut n' paste of that info: From the Planet Vectorworks review of the M1: For Vectorworks users, M1 chips are anticipated to speed up performance of everyday design tasks, such as rendering, drawing regeneration, and section updates. As more testing and reviews roll out to vet Macs with M1 chips and the design community moves toward greater adoption of the new technology, Johnson said he expects that next fall’s release of Vectorworks 2022, with Apple’s Metal technology fully supported, will shine on M1 chips. “The Apple silicon technology performance promises are also aligned with rendering solutions that will find their way to our customers in the near future,” said Johnson. Johnson frames it for Vectorworks this way. “For Vectorworks customers, the 2021 software is compiled for Intel-based Macs. Apple engineering has quite impressively delivered performance improvements that are immediately evident using Vectorworks 2020 and 2021, thanks to the Rosetta 2 emulation mode. We expect another performance boost with the upcoming release of a Universal Binary solution for Vectorworks. And future versions of Vectorworks will be compiled natively for M1 and will see even greater performance gains. When the Apple Silicon version is coming isn't clear, estimates have varied from: To: “[Steve] Johnson sums it up by forecasting that continued development of a Universal Binary solution, which should be available long before Apple’s five-year projection for continuing to sell Intel machines, will ensure even greater performance for users because it will support both Apple and Intel architectures.” - Dec. 10th 3:18pm 2020 But it is worth noting, the Roadmap V1 - V4 lists “Apple Silicon Support” as Scheduled, i.e. “a fair assumption” for the next release: “Supporting Universal Binary for Apple's new M1 processors is a top priority.” Based on the second quote by Steve Johnson above however, support in the initial release of 2022 seems unlikely, but with metal done at that point, I'm guessing from the conviction listed in the Roadmap, that attention will be squarely on addressing the A/Silicon version.
  24. This is not advice, but coincidently this comparison between the two platforms, focusing on the current value proposition around your budget, was just posted. As to the M1 not being listed on the system requirements, read this - Mac Arm - M1 Processor. Currently it states all issues are resolved. @JuanP?
  25. @JuanP could you better explain what NV's "official" position on Vectorworks under Rosetta is now? The M1 statement appears to exist in lieu of official support; while it states approximately nine months of ongoing testing has occurred and that the outstanding issues found under Rosetta have been resolved with the latest Big Sur release, it still concludes, "Our QA team is continuing to test Vectorworks and Vision, and we will keep updating this information on a regular basis. It's not clear how the entirety of the M1 statement is meant to be read now, it's not clear when some items, like the Big Sur note, were added, and it's not clear what is meant as "official" when the following note appears midway through the statement: Note: Please be advised, that if you plan to use any of the new Macs, we as of this date do not have official testing results to share with you. We recommend you follow this thread and check back for our official updates on testing results. The current situation seems deliberately confused and inconclusive; on the one hand you appear to give quasi support for Apple Silicon, by stating that the best part of an annual cycle has now gone into QA testing with no remaining issues, while on the other hand providing no "official" confirmation of that support. This, I assume, is meant to be read as a "buyer beware" caution. Presumably your QA team, or legal, have good reason for preventing a statement of "official" support? Given the duration, could we know what that reason is?
  • Create New...