SteveJ

We are always energized by the forum. And we find motivation and incentive from all the feedback we see. But every now and then... we do enjoy a gust of wind like above... it can help fill our sails. We are here listening and trying to serve you and your design as best we can. Thanks to the entire community!

There are reasons. Many reasons. Vectorworks is a very complicated piece of software and we are always looking for ways to accelerate these updates. That is why we just increased the update (SP) frequency. In a sense there are no "minor" bug fixes. We need to take time to build confidence that any particular fix does not introduce a step backwards.

Has anyone here been disappointed with Apple Silicon? (16GB limit not withstanding)

Recall the single M1Max is quite fast - some might chime in here. We will get our hands on ultra asap - and share what we find! I would not expect it to be slower than M1Max. and you have the 128GB option. If you currently use 128GB for your projects, this is very nice news!

Hello all interested in Native Apple silicon! The publish command is certainly a lower bound for performance improvements. The multi-core and GPU/Metal/DirectX performance wins for Vectorworks currently occur with the everyday, every minute, every second workflows of changing views and navigating your complex design. Switching and redrawing in Top/Plan, switching to and navigating 3D views, working with large files with large number of classes and more. I think/hope those using Apple silicon already can remind us of the these wins. Concerning 16GB and the frustrations updating multiple viewports in batch, that is one of the biggest offerings of ultra. Updating multiple viewports with complicated section cuts does push beyond 16GB. With 32, 64, and now 128GB, that limit is lifted. So four points to add at this point: The memory limitation of 16GB has a new upper bound! The real multi-core and GPU benefits of native Apple silicon are not well celebrated with the publish command - those of you already using Apple silicon might remind us of the experience you see. (16GB batch update limit not withstanding) This discussion thread will collect more benchmarks as we and others get hold of a shipping Mac Studio. We will be able to report on workflows other than the publish command. Apple silicon is great technology. And, don’t forget, much of what we do is cross platform. Ultra and UltraFusion are quite compelling. Here at VW, we are constantly working to improve Vectorworks to take advantage of all this new technology. We hear and understand your concerns and are laser focused to continue to improve your workflows and experiences.

Thanks to this Forum and the entire VW organization as well! It does take a community!

Thanks for the insight Maarten. We can look at CallDefaultTool mechanism if this turns out to be the issue. @Stefan Bender We may need to get hold of the Window and the info that lets us run in debug mode. Perhaps this info and attachments are attached to a previous build? Anyway, thanks for digging in on this.

A great example of a shortfall in user experience. I would think this should not be a job for the Window tool. I would expect this be a fix in for the main application/SDK to make. I will look for a way to get hold of the CW Window tool. Or, @Vlado, Perhaps we can find a sample tool that shows the same behavior

Is this a regression?

Got it. Understand. I will ask @Vlado about the Insertion tool code path you are using.

@Stefan Bender Are you asking about the "Full Screen Cursor" when you mention horizontal and vertical guidelines? Perhaps a quick movie to confirm?

Most likely the next version.

The advantages are difficult to compare Mac to Win. That said, Direct X and Metal will improve VGM performance on each platform. Continued move to more multi-threaded processing, as with 2022 hidden line, will bring performance gains to each. What is different in 2022 is the gains provided by Apple Silicon. The performance gains from this technology obviously favor the Mac

They are not. A high quality release of this feature was not in the cards for this release. We will continue to work to deliver this solution in the next appropriate release. Please follow the roadmap and contribute to the discussions as we move forward.

Hello Willofmaine. Hello others following this topic. I would not classify the current behavior as preferring unrestricted snapping as much as preferring to NOT to force working plane snap. As noted, VW even goes so far as to turn off the Snap to Working Plane automatically as tools are changed. I think VW is “afraid” to “leave the working plane snapping ON”. That is not to suggest that VW is behaving as it should. This is just a quick attempt at an explanation for why you have seen inaction here. Let me apologize for being timid in this area. I think Vectorworks can consider being bold and working to improve this. To do what you seem to suggest. Can we explore ideas together and see what VW might be able to do to improve here? To get this started… What would we call the view that we are talking about? The workflow context? Can we call this Orthogonal With Working Plane Perpendicular to View? OWWPPV (we could rename this) …Following Will's comment about being "backwards" , what if VW automatically turned ON the snap to working plane when entering OWWPPV? You could simulate this now by constantly pressing the keyboard shortcut while working in OWWPPV. This might provide behavior Will describes as "RESTRICTED to the screen plane". Could something like this help? Thanks in advance. Steve

Happy Cyber Monday. I/we appreciate the excitement centered around this topic. I can report that the level of excitement is growing here at Vectorworks too. Last week we were finally able to install a MacBook Pro at the office and begin using it to run our acceptance tests. As you might imagine, a holiday break and Covid-19 provides quite a challenge. We hope to finish this initial testing this week. That said, perhaps the following anecdotal information will help to reveal where we are. I hope to get back to you all by the end of this week with more details. Reasonable Optimism: We have had a MacBook Air (MBA) since 11/18 at 5:45 PM. It arrived on the porch with all 8GB of memory - initial testing that evening and the next day provided a good reason to be excited. As hinted above, the MBA compared very well to my MacBook Pro i7+16G and then again last Monday when a colleague tested with his MBP i9 with 32G. So it is exciting how a consumer-level machine can drive Vectorworks. Pragmatic Caution: Vectorworks provides such a wide range of capabilities - any one of these could be a critical part of your business. It has so far been difficult to find issues, but we must assume that we will discover some. Please be patient. We are working on this as best we can. We returned from the holiday today, and we will continue to look for information to share. As an Apple customer like you: We can share that we’ve had to reboot our testing machine rather frequently and have had some connectivity problems. As of this morning, we are a quarter of the way through our testing. I can report the following issues: The Finder Icon View of a Vectorworks file does not show a preview Updating a sheet Layer Viewport with OpenGL and Ambient Occlusion will crash. Here you can find all official communications about M1 and Big Sur issues Regards, Steve. VP Product Development

Hello Toby. Apple Metal is a separate thing. These 2021 enhancements target the CPU. We are committed to providing a smooth transition to Apple’s Metal. In 2021 our focus is to maintain quality and stability as Apple transitions to its new Big Sur Mac OS 11. That said, please know that we are hard at work transitioning our VGM to use Metal and we plan to replace all OpenGL with Metal for the 2022 release. Speaking of Big Sur... It is very nice to report that we have been working with Apple and their Big Sur beta since its introduction in late June - ALL known issues have been resolved. We will be providing more updates about Big Sur compatibility in the near future.

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

Here at Vectorworks, we downloaded Big Sur beta as soon as it was available. Vectorworks launches and Runs! We will be evaluating Vectorworks and the new macOS 11 this week. We will be working hard to make sure Vectorworks runs well on Big Sur when it is released. And, we will also be preparing a Vectorworks that is ready to run natively on Apple's new "Silicon" when it hits the streets in late 2020. We will keep you posted about our progress. Cheers!

We would love to gain access to these files and workflows so we can find and resolve these issues. As Juan said, we are looking forward to receiving the info that will help us. R+D will be very happy to dig in and work on this! Thanks in advance. Please post files here: https://vectorworks.groupdropbox.com/upload/fa8538f52f8a236bb2a139a8eb4a8955 Steve Johnson

The Tape Measure Tool; First of all, I would like to make perfectly clear that we do not want you to waste all this time. SO? this discussion is sure to go a long way to resolving these issues as we work hard to move this software forward. Thanks, It is very helpful to focus on specifics. Current state of the Tape Measure Tool: This tool used to be limited to the screen plane and would only work when the screen/view was lined up with the objects being measured. Frustration and misbehavior: The tool currently requires a 3D plane. It should still support measuring if the Active Plane is set to Screen Plane. This is a BUG. Currently, measuring must occur with the object aligned to the current 3D plane. In Front view, the application will align a temporary 3D plane to the front view and the tool will measure as it would if the active plane was set to Screen Plane. Additional note: We recognize that this tool should not require a plane to measure objects. Again? We do not intend for you to waste time - please know that we will incorporate this feedback into our process so we can resolve this issue. Thanks!!

Jim, Consider this Crickets Chirping :-) We regret that you have lost so much time with these issues. Let's see if we can figure out how we can best address the concerns being expressed. For the purpose of this discussion, let's assume that we want our workflow to match those in 2009 and earlier - we want 2D objects to be attached to the Screen and not attached to a 3D location. This is a perfectly good workflow - it was all there was for so many years. It is a workflow that we tried very hard to continue to support. To remain competitive and viable we must continue to move forward. Please know that we place an extreme high priority on existing workflows as we consider the changes we make to the application. So? We want to set the active plane to be Screen Plane while using the Selection Tool or any tool that creates 2D objects. If the Active plane is set to Screen, then it should remain set to screen plane whenever the Selection Tool or 2D tool is active. This will cause all 2D objects created to be assigned to the screen plane. It will also cause the Selection tool to operate in the screen plane - this also provides the behavior for the 2D Selection tool of 2009. So we should have Active Plane = Screen Plane whenever we use a 2D tool - Just like 2009 and before. If a 3D or Hybrid tool is activated then the Active Plane can't be the screen plane - it still shows the active plane and this plane must be a 3D plane - usually the Layer plane. If you return to a 2D tool or the Selection tool the Active plane will show "Screen Plane" Once a 2D object is created, the Shape pane in the OIP has a Plane popup showing the plane it is assigned to. Let's consider this a start to the conversation. We certainly will get into more detail as this conversation continues. Steve Johnson Nemetschek Vectorworks