Amorphous - Julian

March 4, 2019

@Zeno are suggesting we should downgrade to VW2015 because it is a more stable version of VW?

March 4, 2019

Is it just me? Or is this speed quite frustrating for others too. We need a snappy program.

March 4, 2019

Everything is slow! Simple things like:

Editing a dimension is slow.

Moving objects around is slow.

Navigating between sheets is slow

Save and commit is slow (yes it has improved, but lets face it, still slow)

There's a 2-3 second delay in everything I do....

Is anyone at Vectorworks doing anything about this??? I don't want to be frustrated anymore.

March 4, 2019

Lately, Vectorworks suddenly shows a blue background across multiples of our Mac terminals running both Mac OS 10.13 and Mac OS 10.14.

We can't get rid of this problem and can't work this way. Does anyone have the same problem or a fix?

We use RX580 (8GB) as our graphics card, and have tried to set Display Performance as both 'Best Performance' and 'Good Performance and Compatibility'

March 3, 2019

Would be great if VW can also work out the innermost section line of a space, while retaining the section hatch of the objects you cut through.

Currently you have to choose one or the other- merge the whole section and get one thick outline (but lose the class-based hatched for cut objects), or get the correct hatches (but not get this thick section line around the outmost merged object).

As @Kevin McAllister says, this is currently a manual, 2D process we do in viewport annotation for our office.

March 3, 2019

On 12/18/2018 at 4:50 PM, Christiaan said:

Yup, I've been banging on about getting the window and door tools finished for years. They still haven't reached maturity after all these years.

The Australian distributor actually has a far superior window and door modelling tool called Windoor.

Nemetschek should buy it from them and put it into the standard VW version.

We concur with this post, and personally would prefer the following simple things fixed over giving us any new features (my list is all about productivity and workflow):

- Section Viewports rendering time (snappy renders please, even with 'surface hatches)

- 2D DWG export from 3D models (Usable files, smaller size)

- Titleblock Object (Let multiple users modify different title blocks in Project Share. Any operations on TB is sooooo slow!)

- Stair tool (SO INCREDIBLY SLOW)

- Visibility tool (wait five seconds us to load the tool)

- Slab tool (try reshaping it, SO VERY SLOW)

- Floor tool (in 2019 totally broken, corrupt objects, wrong class appearance, disappearing fills)

- Grid Tool (appear in 3D, line thickness control!)

- Space Tool (try reshaping it!)

- Detail callout Tool (leader line goes crazy when line settings changed. Difficult to reshape geometry but maintain rounded corners)

- Undo Operations (Really should be so slow it crashes a computer)

March 2, 2019

@Jim Wilson thanks for your response.

I did some experiment, and found that in some instances, the extreme slowless is caused by 'surface hatches'.

Please see enclosed simple example, sided by side, where one takes 8 seconds (with no surface hatch), and the one with surface hatch takes many many times that amount of time (with surface hatch on). Should I post this 'surface hatch' issue as a separate troubleshooting case?

You mentioned that sectioning speeds is slated for improvement. Can you indicate if is an improvement that can be expected in VW2019 SP3?

Thanks again.

STRUCTURAL MEMBER BUG(s) · February 26, 2019

This tool has wasted so much of our office hours.

- it doesn’t merge with other structural objects in section

- class overrides in viewport do not work (eg we want dotted lines showing beams above in plan)

- the solid fill in the beam object disappears out-of-nowhere, leaving our renders and elevations looking sh*t

In the end a VW forum member offered a solution: that I should use ‘beam’ object in ‘framing member’ in lieu of the use of structural object. That worked.

For one project, we went from (1) starting with ‘beam structural object’ then (2) abandoning this and remodelling them as ‘walls overhead’ (problematic) and then (3) in the end remodeling all those beams as ‘framing member- beam’.

All in all, inclusive of the trial and error in generating 3D renders and incomplete elevations/section, multiple attempts at remodeling, discusssing this issue internally and with others, it was in total about 20+ hours office time down the drain.

I say the following in the most sincere way: Please stop wasting my office time, the good people at Vectorworks. When you put out faulty tools like this, businesses (like mine) that rely on your products suffer a loss of billable hours from the abortive work incurred. That results in a loss of money. Kindly take note.

February 24, 2019

I'm happy to report that since moving from VW2018 to VW2019, the 'Save and Commit' times have dramatically reduced.

On our 1.2GB file (600MB as project file, 1.2GB as working file), the 'save and commit' time is now 60 seconds or less.

However, a very important part of what this thread is about, namely 'Section Viewport render times', remain a big headache for our productivity with VW.

For some simple viewports, we now get up to 10min rendering time for hidden line. For complex viewports, we get up to 30min.

@Jim Wilson since this thread was started on 30 August last year, I would like to ask if you are able update us on what has been done, or what the plan is, to improve Hidden Line Render times? When can we expect a change?

PS. There should be an easy way for users to 'Convert hidden line render to lines and polygons within Viewport', so we can continue to work, at 1-1 scale, with what has been rendered inside a viewport (I'll start a new feature request on this).

February 24, 2019

We have a few page-based symbols we created in previous version (VW2018) and have since converted to VW2019.

The symbols don't appear in 'Sheet Layer' view, nor can we see it inside 'viewport annotation'.

But they appear when we print the sheet. Frustrating.

February 24, 2019

Link to 'feature request' for 'item 2' per my post above.

February 24, 2019

Documenting in 3D with VW will get you pages and pages of Sections/Elevations (good!).

However, if the viewport caches are not properly saved, then you end up with pages upon pages of blank pages with empty red rectangle frames (no good!).

The problem here is not that we do not render our viewports often enough, it is that updated viewports are not synced properly across the various machines in Project Sharing. The end result after a few rounds of 'save and comment' is that we end up with blank viewports again across all the terminals.

So, if a staff was expecting to 'fix up' something in an elevation we printed out, he would finds himself having to re-render that section/elevation in his machine, because there is no viewport cache. Unfortunately rendering a hidden-line viewport is not a quick process (will post a separate feature request for fixing this).

VW has to better log which VP is the most recently rendered, regardless of when a particular terminal performs the 'save and commit' function.

As an office that needs to produce drawings for issuance. This fix can't come soon enough. This fix really needs to happen NOW.

(and if you were going to ask whether 'save viewport cache' is checked across all terminals. Well, obviously, yes)

February 24, 2019

I have previously posted about our project sharing experience in this thread- and at that time we had terrible wait times for 'save and commit', taking up to 4-5minutes per save. That was based on version 2018.

So having updated to VW2019, here are some new insights I'd like to share, @JMR @Tom Klaber

FASTER SAVE AND COMMIT TIMES IN 2019
In 2019, 'save and commit' has dramatically improved (it is now around 1/4 of the speed compared to what we had in VW2018).
VIEWPORTS RENDERED DO NOT SYNC BETWEEN MACHINES
While 'Save and Commit' is no longer a problem in terms of Project Sharing, the main issue of using VW in PS we experience now is that the Viewports rendered on one machine doesn't get updated into the other shared project terminals.
VW doesn't seem to keep a very good timelog of which viewport on which 'Working File' is the most udpated.
This is frustrating because we constantly open a file with pages upon pages of blank viewports, and have to render them again.
SLOW AS F**K RENDER TIMES FOR HIDDEN LINE VIEWPORTS
Having to re-render viewports wouldn't be so much of an issue if it wasn't so very very very very very very very very very very very slow. Simple viewports of an interior can take up to 10-20 minutes to render.
And it is difficult to ascertain what could be faster or slower. Four internal elevation of the same room can vary between 1-10 minutes, without different degrees of complexity.
I don't know if this problem is unique to Project Sharing, but certainly is very frustrating. It is so frustrating I often wonder why we use Vectorworks in 3D at all.
(I have reported this in another thread, also in a previous post in this thread, and hope it will get some attention).

If you're interested. Enclosed is my network read/write speed to the server (500-600MBs), and also my server read/write speeds (1300-2000+ MBs). We have invested a lot of time and money into getting our hardware to this point. We also have the highest-spec Macs out there, so it does disappoint us that the render times for elevations can take so long. (I have previously posted my computer and network specs in this thread, so I won't go through that again)

I will post 'item 2' and 'item 3' above as feature requests and share those links in this thread later, hope you can vote them up.

@herbieherb I'm pleased to hear about the successes you are having with PS. I'm interested to know about your Project Sharing experience. Are you part of an architecture office, or do you provide VW support? What type of project size do you work on?

February 19, 2019

12 minutes ago, Boh said:

Note that these are two different objects:

One is a "Section - Elevation Marker" the other is a "Section Line". I'm not really using 2019 but in 2018 a Section Line is directly linked to a section viewport and is typically created via the "Section Lines..." option at the bottom of the OIP when a Section VP is selected.

I haven't tried it in 2019 but when I ungroup a Section Line in 2018 it changes to a Section-Elevation Marker which you can then link to a viewport.

i just posted a response to a related question here:

Fantastic! Thanks @Boh for the tip and the solution!

February 19, 2019

An important feature we use a lot in our documentation process has been removed in VW2019.

In VW 2018, when you place a Section Marker, you can choose where this is linked to. This is useful when you have multiple instance linking to the same detail.

In VW2019, this can still happen before you place a Section Marker. But once place, it cannot be changed in 'Object Info' palette.

See screen shots below.

Can this be brought back to the 'Object Info Palette' VW2019 SP3 ??? The removal of selectable viewport affects our workflow severely.

February 19, 2019

On 2/6/2019 at 12:16 AM, Andrew Mac said:

I often get requests to export my elevation sheet to a dwg format. I do a lot in the annotations on the sheet- thus I am not sure how it translates to the dwg user. Any tips or best practice to achieve this?

Hi @Andrew Mac we always have to do the same thing too- to export elevations generated from our Vectorworks model to DWG. However, with VW2019, our consultants are simply unable to use the DWGs we export to them (file too large, unable to zoom in and out, crashes upon opening).

Have you had any success on this?

You may be interested in the following post too, where users are discussing this issue:

February 19, 2019

On 2/5/2019 at 10:08 PM, drelARCH said:

Hi guys,

I want to ask you what would be your preferred settings in order to export 3D stuff like walls, slabs, roof, windows/doors etc. into 2D AutoCAD - dwg format?

My typical task is to design building - architecture side of a project and then send its 2D set of drawings (plans, sections, elevations...) to specialist to incorporate their part.

In my country Vectorworks is absolutely unknown and not used at all, offices uses predominantly AutoCAD software for drafting so I am trying to get as accurate as possible 2D results for them.

I know there is option to tick 'Export as flatten 2D graphics' ... but still I only recently move from 2D environment to 3D and would like to know instructions from more experienced users among us.

Any help welcome and thanks!

Pavol

Hi @drelARCH we also use Vectorworks in 3D and have problems getting our exported DWGs to our consultants.

You may wan to share your experience in this post, which is relevant to the issue of exporting to DWG from vectorworks:

February 16, 2019

On 2/13/2019 at 2:55 AM, Art V said:

One thing to keep in mind is that VW 3D objects and DWG 3D objects can be quite different and it could get converted in ways that will keep the appearance of the object but not necessarily the editability. E.g. some solids may get converted to meshed/triangulated surfaces etc. It can happen the other way around too as solid hatches can turn up as a bunch of filled triangulated areas in 2D at times. The ODA DWG libraries have become better in the past few years for 3D conversions but there will still be things that won't translate smoothly from one to the other. So it really depends on your 3D objects/models how usable the export will be. The more complex it is the more likely you will have issues.

2D exports are mostly fine, except from some things like text styles etc. that VW has not yet fully implemented even though it is in the ODA libraries. 3D is something I rarely bother to export to DWG unless it is simple stuff or if I really have to at the client's request.

You could try exporting to Rhino3D format first and then from Rhino to DWG, but that requires having Rhino available. It can make things a bit better at the DWG end. It works th the other way too, if you have a messy 3D DWG file (i.e. lots of meshed/triangulate surfaces) then importing it into Rhino first, save it as a Rhino3D version that VW supports and then import the Rhino3D fill may give a (sometimes much) more usable 3D import than directly importing the DWG file.

Thanks for the suggestion @erminio @Art V, they are indeed good ‘workarounds’ for this severe Vectorworks shortcoming. I will try them out.

But the important issue here is that exporting from Vectorworks to our consultants/ contractors in DWG format is a frequently-occurring process in our industry. To reiterate: it is something that EVERY architect needs to do regularly in their workflow.

SO WHY IS THIS SIMPLE PROCESS MADE SO DIFFICULT IN VECTORWORKS?

Vectorworks should- ‘out-of-the-box’ - be able to export to these industry-standard documents (ie DWG) without users wasting valuable time and multiple steps to find work-arounds. If we tally the wasted charge-out time we all put into to ‘trial and error’ to find a workaround, we’d probably be a lot more profitable.

I have put a senior VW architect onto the case of finding a solution to this problem and he spent two days on various combinations of settings and methods. We have nothing replicable, easy and efficient. It is up to Vectorworks to give us a solution.

@Jim Wilson to recap- we cannot export our 3D Vectorworks model to usable 2D DWG files (by usable, we mean DWG files of a reasonable size that doesn’t crash upon opening). In any given project, there are multiple sheets we need to export, so the best way to achieve them is with the ‘publish’ tool and select DWG. This is broken and needs urgent attention.

February 12, 2019

What a great solution @Jim Smith and @Kevin McAllister.

But then again, I agree with @Patrick Fritsch - tools released in a program needs to be considered, tested and works. Some VW tools do not reflect how users would use them in real life.

We waste a lot of time as VW users finding 'workarounds' to the lack of consideration/limitations of VW tools.

Enclosed is a screen shot of how we end up doing our 3D grids, by rotating them in 3D. But as with all the 'workaround' solutions presented, the limitation of this solution is that the 'section depth' of a viewport limits the display of this grid.

If anyone in Vectorworks is listening, this 3D grid issue cannot linger for another few years to eventually get a solution.

February 12, 2019

Thanks @erminio for raising this important issue and thanks @Art V for offering a possible solution.

Fact is, this process should just be a simple, straightforward process and does not require VW users to come up with 'workarounds' to make it work.

We use Vectorworks in 3D, and there is NO POSSIBLE WAY to get our models into a usable DWG file to our consultants, collaborators and consultants.

We have spend many hours in our office trying to resolve this issue, and in the end the only possible way to create a usable, small-sized DWG file from our 3D model is to 'save as' a PDF, reimport the PDF to VW, and explode the PDF just to get the lines.

Not ideal at all but no other options we have found so far.

February 12, 2019

Over dinner with industry friends last night, I was reliably informed by a senior partner of an international firm that if our firms don't 'adopt the new ways of generating fast high-quality renders for our clients', we'd be left behind.

The packages that are widely used now are ENScape, Twinmotion, Lumion and Vray.

For a VW company like ours, who uses Vectorworks on Mac, these are the limitations:

(1) ENScape >> Works with ArchiCAD, Revit and Sketchup, but NOT Vectorworks
(2) Twinmotion >> Works with Vectorworks, but NO direct synchronisation like it does for Revit and ArchiCAD

(3) Lumion >> Does not support Mac

(4) Vray >> Works with Revit, ArchiCAD and Sketchup, but not work Vectorworks.

(5) Vectorworks (Renderworks): Quality of render simply is nowhere like the packages above

In conclusion, if I was to apply the conversation about being 'left behind by the industry' based on speed and quality of visualisations, Vectorworks (and to a lesser degree, Mac) is becoming a hinderance for us to compete against the companies that uses Revit, ArchiCAD or even the basic sketchup program.

Our industry is quickly evolving, and as operators, we don't have time to wait for Vectorworks to take years to implement integrations (when others have working integrations already).

Swift action is required from Vectorworks to help Vectorworks-based companies, and the Vectorworks package itself, to stay competitive.

Following is a link from August last year, and I wonder if anyone can provide some update on conversations with Chaosgroup? Or if the engineering department has made progresses and inroads for integration with other rendering packages? When can VW get direct Synchronisation with TwinMotion? Would Vectorworks get integration with ENScape? How quickly can all this happen?

October 16, 2018

As busy Architects/Designers, we spend a lot of non-billable hours doing the following for Vectorworks:

- Identify Bugs

- Making suggestions for features

- Posting on this forum for above issue and respond to further requests for information

- Creating 'example projects' for bug identification

We don't ask for payment. We are simply doing this to improve the Vectorworks product.

I think it would be nice if there was a bit more gratitude for our contribution, and have this gratitude shown when staff engages with us.

And I'm putting this in the Wishlist as a feature request.

October 16, 2018

@Tolu for completeness, this post wasn't only about Tom Klaber's use of Google Drive.

For completeness, read every post.

For completeness, everyone on this post already agreed and established Google Drive (Google Backup and Sync/Google File Stream) doesn't work for VW PS.

The various posts here demonstrates that various people are having problems with project sharing, and these problems should not be overlooked.

Also for completeness, I have spoken to other users on this forum, and the feedback is that you ( @Tolu ) tend to dismiss issues raised by users.

As a final point on completeness. Have you worked a day in an Architectural Firm? How often to you actually use Project Sharing in real-life situations creating models and drawings that output to actual clients and construction sites?

People with daily encounters and experience here are offering a complete view of this project sharing issue, and deserve to be listened to.

October 15, 2018

I actually wonder whether VW should be updated every two years, and not annually.

It seems crazy that we spend one year to reach SP4 or SP5 for each version, which admittedly is stable but still not ‘complete and perfect’.

Then we abandon this ‘last stable’ version as quickly as we reach it, and jump into a world of chaos and insanity because of ‘new features’ in the next version.

If SP4 and SP5 are genrally stable, then shouldn’t we extend its use for an extra year, and continue to improve productivity and fix all the remaining bugs well into, say, SP10?

I image once we reach stability at SP4, we can focus on productivity improvements in the subsequent SPs. Productivity improvements currently seem lower on the VW list than new features. Perhaps productivity is not sexy for marketing purposes, but new features are?

Of course VW needs annual income to balance its sheets, and this is how I think it can work.

Currently:

If current VSS is, say, US$1000 per licence (for designer series), then it is $2000 over two years.

Alternatively:

VSS is split into

(a) SP releases for the next two years (US$1000 for two years’ worth of SP releases)

(b) Upgrade to the next SP0 version (US$1000 paid every two years)

VW will end up with the same subscription amount, but have more time for much better feature release and product improvements (broader in scope, better in quality)

But that means if one buy the next SP0 version without the upgrade options, that person will end up with a buggy software.

This bi-annual cycle would only be feasible if VW does indeed commit to releasing software every two years that looks and feel like there was two years worth of thinking and development in it- not just giving us the same thing we used to get on a yearly basis. Hard to quantify and qualify I know.

Perhaps one way to quantify and qualify it is to say, every two year, 200 items in Wishlist feature request is granted (compared to say 20 in annual releases).

May not work for everyone. But this would work for my office.

October 15, 2018

@Tolu please also check out this troubleshoot post for other users with PS issues:

Profiles

Forums

Events

Articles

Marionette

Store

Posts posted by Amorphous - Julian