Amorphous - Julian

Hi @Tolu I'll send you the latest file, so you can test with the appropriate evidence. The save and commit changes were related to changes made in a 1-hour period. 3 of us were out for a meeting till 4pm. 1 person was working for the whole day. When the others returned they continued doing other bits of work, by 5pm, they had that issue. Our network is 10Gbe equipped and achieve real-life write/read speeds of 750MB/250MB (see screenshot). All our terminals have: - NVMe drives locally, and have write/read speeds exceeding 1250MB. - All terminals have either 48GB or 64GB RAM - All terminals have dual X5680 or dual X5690 CPU - All terminals have 10GBe network cards, achieve real-life write/read speeds of 750MB/250MB - The all terminals (server and workstations) are mac-based - Our server is Mac OS 10.11 running SMB file sharing Our equipment is reasonable for an office our size. Let us know what equipment you do your tests with. [IMPORTANT NOTE 1] The above 'slow save and commit issue', which I reported on on 28/10/2019, but are actually issues that happened on 24/10/2019, occurred after our upgrade to VW2019 SP5.3. As you know, we have had reasonable 'save and commit' up to this point (1-2 minutes). But it was never slow like this. We thought the issue might be related to SP5.3, so we then went up to V2020. Didn't resolve the slow save and commit. [IMPORTANT NOTE 2] In case our issue is 'not replicable' and faces dismissal (can be very distressing)- Kindly note the above point in my post: my other files are working as normal, and save and commit times are just a few seconds. It is the big file (which I have by now sent you the latest version). That has this problem.

perhaps it’s important to NOT miss the point here- either ‘save and commit’ or refresh is taking a ridiculously long time. Dismissing this important point doesn’t solve any issues on my end- the issue is the same

the video was only meant to demonstrate/prove that the save and commit profess was taking kore than 10+ minutes, it should have little influence over the reading of the my post. the original 260mb file won't upload due to forum file size restrictions. i have to use online converters to make screen recording video conversions just to prove my points this is very time consuming. save and commit (1).mp4

[UPDATE 28/10/2019] Hi @Tolu Around 6 hours prior to your above response- got that metadata error message again (5pm on 28/10/2019). The extremely slow save and commit times on this file, in combination with this meta file error, caused me to send everyone home early (See screen shot). To clarify the situation, for avoidance of confusion: (1) We had followed exactly the steps to clear metadata the first time around on Thursday (24/10/2019) (2) This metadata error occurred again on 28/10/2018, just two working days after the first error occurred (3) What is preventing the team from effectively executing the metadata clearing, is the 15+ minute ‘save and commit’ time required (for each person). There were 3 people in the office working on that file. That’s 45 minutes. We are rushing through documentation for this project. (4) After the 28/10/2019 incident (where i asked everyone to go home). our manager stayed back to perform 'save and commit ' on everyones terminal, and performed the metadata clearing. the save and commit on each terminal is 15+ minutes. (5) other files, still small in size (fee hundred MB) can still save and commit as normal We are rushing against deadlines to deliver this project. I beg you with all sincerity to give us a solution ASAP. Many thanks.

Hey guys, just wanted to share our experience with Project Sharing with others. See if any of these experiences help.

[UPDATE 28/10/2019] Project sharing issues has gone from moderate to SEVERE. To a point where project sharing is NOT FEASIBLE. I was out of my office on Wednesday and Thursday. And the following Message came up on one the workstations: We followed the instructions. Follow that. 'Save and Commit' Operation will not function properly. It took more than 10 minutes to complete the operation. Others cannot save and commit even with 1 hour operations. See enclosed video. (filesize reduced but I can share original) I told the office to quickly upgrade to version 2020 to resolve the issue. ----------- AFTER 2020 upgrade----------- On Thursday and Friday, we and some staff away. So we didn't test the save and commit operation. Only one person was using the file. On Friday, before we left the office, we opened a project file on another terminal and tested the save and commit operation. We left that running for the weekend. You can see screenshot below, it is now Monday, and we have ran the save and commit ran all weekend now. 'Beachballs' don't show up on screenshots. The beachball is still running, and the 'refresh' button still has the yellow hazard sign (it is not udpated) I honestly don't know what to do with this now. A project that I am meant to have 4 people working on now only has one person working on it. HELP!!!!!!! save and commit.mp4

@Tom Klaber totally agree with all the above. As it is, none of the cabinet tools give us visually how cabinets should show in plan. So the 2D-3D workflow is not smooth. Take this laundry with base cabinet, overhead cabinet, and two full-height cabinet on either sides. I look at this drawing and think to myself: this doesn't communicate anything remotely like what it should. I can't control: - door swing to show - overhead cabinet to show dotted - full height cabinets to show sides and back (in thicker lines) - base cabinet to dot in carcass - in 3D, the basin doesn't cut into the cabinet or countertop - I cant show one continuous counter to cover the joints in base unit. Would love to see this tool improved

A number of forum users have DM'd me on this topic. And I thank everyone for their input and guidance. In the end, it seems everyone's struggle boils down to one question: TO BIM, OR NOT TO BIM? Now, as far as I'm concerned, BIM means BIM. There is no half-way point. A hybrid 2D/3D drafting process, where information of BIM objects cannot be 'called out' in any part of the documentation (because drawings are flattened) IS NOT BIM. A process where 3D modelling doesn't live-update the 2D drawings (including section etc), IS NOT BIM. If I can draw a consensus, it's that we would love to implement FULL BIM, but the inefficiencies of the Vectorworks package in terms of speedy 3D workflow is preventing us from doing so. In recognition of that, our office is going to roll back our implementation of FULL BIM, and revert back to a 2D-drafting process. WE WILL 'BLOW-UP' ALL OF OUR 3D VIEWPORTS But wait- there currently is no efficient way to do this in Vectorworks! While viewports can be converted into 'groups' or 'polygons', they are converted in the wrong scale (on sheet), and are not placed inside the Viewport's Annotation Space for further editing. Fear not! Enter a script that @Julian Carr developed for us to resolve this Problem. Julian's script does the following: (1) - Auto-updates the selected viewport (2) - Makes a copy of the updated geometries, including hatches (3) - Places the geometries, at the correct sale, inside the annotation space of the viewport (4) - Turns off all design layers so there is no overlap (user can choose) [Note this script only works for Sections and Elevations, not Plan] I took the liberty to share this amazing Script here. You can all thank @Julian Carr for it. This script is an absolute time-saver, and right now a life-saver for us. We think the functions contained in this script should be included with Vectorworks as a standard. ...Meanwhile, goodbye to the dream of full BIM in 2019. we are full swing into 2D drafting. Back to 'year 2010' we go.... CopyVPContent2Annotation.vss.zip

+1

We checked on our User Origin, and they are all identical. So there is no reason why one person has the correct location and the other three do not.

I investigated this problem further... and it is quite peculiar. We have the shifted references on ALL terminal except for ONE. NB: This is not the first time we have noticed this problem. But we didn't have the time to report it before. But we need to finish up our documentation soon and must resolve it now. @Tolu I will send you both files

Hi @Tolu I have experienced the said problem a number of times in the last few months, but never had the time to report it. When we reference to another Vectorworks file, once we 'refresh' the Project File- the alignment is off. This is despite the origin point aligned with the model plan at initial referencing (I have a printed hardcopy of the attached screen shot I can show you). There doesn't seem to be a lot we can do about this. And the shifting always goes in the same direction. Sorry to say, but this is really disruptive to work. I'll send you the files in DM.

Yes, would be great to have groups (like the drop-down with classes and layers) or folders tor put these saved views in

[UPDATE 18/10/2019] The crazy crash plus disappearing viewport issue happened again today. Then suddenly all four of us couldn't get a file we can work with, and have to revert to 3 hours ago. Then manually copy and paste model/viewport things we did for the past few hours. This equals to 4 hours x 4 poeple's work day. 16 hours.

@bcd @Simon Allan you may find it a shock (and I did today) that Revit hidden line renders are INSTANT No wait times!

Hi @ericjhberg I was so ultimately discouraged today when I vented my frustrations with to friend, who is a Revit architect. Amongst many things, I told him Vectorworks HLVP rendering times is really slowing down my office. He told me this process is instant in Revit I researched and found he’s right. It broke my heart. See post below.

We all know by now, the amount of time required to render hidden line sections in Vectorworks can be soul-destroying. So I asked my friends who uses Revit how long their ‘hidden line’ elevations and sections take. And they said ‘INSTANTLY- just like in sketchup’ I googled some Revit videos and, alas, it is true. Revit equivalent to VW hidden line rendering is INSTANT, (with all the surface hatches appearing) and works just like in sketchup. I figured when creating a drawing for 4 interior elevations of a room, Vectorworks is at minimum 80 times slower than Revit. This is the Calcs: each elevation viewports takes 20 seconds to render in Vectorworks, and I have 4 elevation viewports, Vectorworks would have made my workflow 80 (20s x 4) times slower than my Revit counterpart, who gets this instantly. This is not even taking that most of our sections take a few minutes to render, not just 20 seconds. Nor does this take into account each time we make a change, we need to re-render these viewports. Further, if you want ‘surface hatches’ to appear, that is many more multiples of times longer. See below a video of hidden line rendering in Revit (note in Revit hidden line means ‘dashed hidden line). I have also included a link to a post, where I posted videos showing elevation viewports ‘with’ surface hatches takes 20 times longer to render than ‘without’ (6 min vs 20 seconds) DEAR FRIENDS AT VECTORWORKS: IF REVIT CAN DO INSTANT HIDDEN LINE- WHATS STOPPING US FROM HAVING THAT TOO? WHY SHOULD MY WORKFLOW BE TENS OR HUNDREDS OF TIMES SLOWER THAN MY REVIT COUNTERPARTS?? I’d respectfully asked to be spared on what is ‘possible or not’ ‘in terms of engineering’. From where I’m standing, Revit has achieved it, so in terms of engineering it is possible. Hidden line rendering speed improvement must be a priority! And we are not talking about a v2021 or v2022 priority, it is a priority NOW! We need to see it within v2020. I’m imminently going to lose staff and lose projects due to Vectorworks inadequacy to help us efficiently produce documentation. @Julian Carr @Matt Panzer @Tolu @JuanP this issue of Hidden Line improvement can’t wait any longer. I posted about this issue in August 2018, with many others on the forum agreeing. If this doesn’t get improved in v2020, please let me know in advance, so I can have more time to reconsider my position on VSS renewal for 2021 and beyond. If improvements can’t be seen in the next few months, I would rather invest my time and money to convert to Revit. The efficiency recovered in Hidden Line renders alone could be worth extra time and money. Please understand I am not being adversarial or unreasonably demanding here. My office has invested so much time and money into Vectorworks because we loved working with it. It will be a shame to throw away all the systems we built up with it. But I am talking about the realities of project pressures and business needs I must confront here, and I need to see Vectorworks recognising that and resolving it with us (and not take years). This important hidden line improvement will not be just for me - but everyone using 3D Vectorworks workflow.

@ericjhberg Sadly, the more we try to forge ahead with a Vectorworks BIM process, the less attractive it seems as an alternative to AutoCAD + BIM process. The lack of a good Hybrid object for 2D-3D, is just one of the many examples. And I’ll sure you discovered this the hard way (wasting hours of your time), like we had. Perhaps I’m just deflated with the whole thing at the moment. But it truly feels all the time I’ve invested into Vectorworks has been futile. I fee quite ready and prepared to just go back to doing everything in 2D. I can no longer think that things may improve in another two years.

We had some viewports linked to a certain sheet. Then we had to change the destination sheet number (changed the sheet number via 'organisation') The following happened: (1) _ The link broke _ The link colour didn't change from Green to Red _ The old link number still showed (see 'A') (2) So, we had to manually re-link (see 'B') Would be good if: - the Section-Elevation Marker tool traces changes in Sheet Numbers, and, - anything with 'None' as the linked viewport shows 'Red' as colour.

[EXAMPLE 3] Floor Objects Suddenly have 'no fill'. We have to 'double click' into it, change the fill to 'solid', then back to 'fill by class', and exit the floor object for it to be normal again.

[EXAMPLE 2] These Ghosted Objects are not selectable, non-existent, and affect the appearance of our drawings (We have to draw things over them to 'block' them, and redraw everything that should appear) HELP!

[EXAMPLE 1] See videos, the floor objects do not physically align to where they are supposed to be on-screen. crazy floors.vwx error_2.mp4 error_1.mp4

We get all kinds of strange reaction in floor objects. I find that performing an 'ungroup' operation on a floor option generally triggers this strange reaction. At other times even without the ungroup operation, the floor object will either change appearance. I am going to create three separate posts below to demonstrate what happens.

Sent to you via DM. Thanks.

Hi @Nikolay Zhelyazkov, would you be able to tell me where to find the crash logs?