M5d

I haven't seen anything mentioned on RAM for the M2, but it has already leaked / been suggested that when the M2 Mac Mini arrives, there will be an M2 Pro option. That should mean a BTO with at least 32GB available beneath the Mac Studio models.

Reposted. As per moderator's advice. It would be useful, if the "Section . . :" dropdown in the callout tool could have an "All Sections" option, for database wide searches.

Moved, as per moderator's advice.

Not a perfect solution: Right Click>Decompose (This breaks the poly at the corners only). Then I Group the result >Command Key+G.

There's good news on the Enscape front, it's coming to the Mac in 2022: enscape3d.com/enscape-for-mac/ and they have merged with Chaos. An interesting side note to the merger, Sean Flaherty, former CEO of Vectorworks, will become Chairman of the Chaos Board.

Thanks Pat. Submitted the bug form.

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.

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

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?

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.

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

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.

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

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.

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.

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.

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

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/

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?

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.

https://www.vectorworks.net/support/bugsubmit For future reference.

Umm yeah, where has it gone?

You managed to solicit these replies in the original Roadmap thread:

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

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.