Main headline wish list for v2014 archive

Wikis > Main headline wish list for v2014 archive
Note: if anything is not clear please contact us and we will clarify.
See also: supplementary wish list (items added after 1 November 2012).

Overarching theme for v2014

1. Speed up development. Things are going in the right direction but not nearly fast enough. We need to be at least two years ahead of where we are now. For example we have all this power sitting on our desktops now but still no full 64-bit support.

2. First class traditional 2D output. Vectorworks has a reputation for great 2D output. However when it comes to 2D output from a 3D model it’s one of the worst. In practice the first step toward BIM for Vectorworks users is to model their projects in 3D and output traditional 2D documents. Many of us still have no need whatsoever to output 3D information and it feels to many of us that 2D output from a 3D model has been neglected.

3. Architectural knowledge. Too often in Vectorworks we come up against problems resulting from a lack of architectural knowledge at Nemetschek. Development along the BIM path must be guided by experienced practising architects, either employed by NV, seconded for a year at a time from private practice, or on a consultancy basis.

4. Integration. Vectorworks has become a collection of scripts and buttons piled on top of one another. Nemetschek needs to reappraise the whole thing and stop shipping tools that aren’t integrated. Nemetschek need to think about what’s best for the user, not what can shipped the quickest. There needs to be a Steve Jobs figure looking at the big picture and asking “how would the user expect this to work?” “How would I want this to work?” “Does this need to be here? If not, get rid of it.” Why are Auto Hybrids a new object, why couldn’t these features be added to  Symbols? Text Styles should be a Class attribute. There should only be one type of Viewport. Window and door tools could be merged. Wall joins and component joins should be modes, not separate tools. Same with the curved walls. Same with dimension types. Stair tools should be merged. Handrails. etc. etc.

Priority 1

1.1. Vector-based elevations/sections and 3D hatches

Reason: There are three important reasons. One is the need to generate clean accurate 2D output (including black and white line-based elevations for construction documents) in the form of PDF/DWG/Prints without the need to render. Another is to be able to view an accurate representation of the model within Vectorworks, again, without needing to render. Finally, we need to be able to export DWG files with all information in vector format (fills and images are of little use to other disciplines other than for presentations).

1.1.1. Vector elevations should be hidden line, hatched, with no lines between storeys and no diagonal lines across polygon faces.
1.1.2. There should also be an Open GL shaded option and a vector shadows option. This should be the default view when you look at the face of your model.
1.1.3. 3D hatches need to have sensible real-world scales and have attribute mapping level of control for the origin and orientation.
1.1.4. All VW objects should support 3D hatches; we should not have to resort to extracting 3D surfaces. Ever.
1.1.5. We need the ability to control line thicknesses on elevation drawings, based on their distance from the front of the elevation. In traditional 2D drafting the convention is to show closer elements with a thicker line.
1.1.6. Sections should show the material’s section-hatch property (see 1.3.1.)

1.2. Greatly enhanced Workgroup Referencing for working in teams

Reason: If Vectorworks teamwork is going to be based on this workflow we need to have full control and maximum usability over referenced files from within the host file.

1.2.1. Ability to sign design layers in and out, so two or more people can be working on the model at the same time.
1.2.2. Delta updating of workgroup references (i.e. only update changes, not the entire file).
1.2.3. Ability to edit workgroup referenced files and push the changes back to the model.
1.2.4. ArchiCAD has a system called ‘hot-linking’ where it is possible to create wall joins in the active file with walls in the referenced file. Similarly, wall healing occurs automatically in the reference file when hiding certain walls.

1.3. Building materials

Reason: to simplify the application of all related attributes and reduce conflicting settings in PIOs, Classes, Layers and Viewports.

1.3.1. You define a material once, with a face hatch, a section hatch, a shade colour, a render texture, line weight and fill. “It just works” in 2D, 3D vector, 3D render (additional scale-sensitivity/alternatives would be a welcome addition).
1.3.2. Example (video).

1.4. Support for vector-based window elevation schedules and associative dimensioning.

Reason: it’s 2012, we just shouldn’t be manually drafting window schedules.

1.4.1. Ability to render vector-based hidden line elevations of windows/doors so we can dimension them, with associative dimensions.
1.4.2. In the short term this could simply be an update to the new support for images in Worksheets but in the longer run we like to be able to layout window schedules in the traditional way, horizontally for each floor level.
1.4.3. Talk to architects, see how they present their window schedules.

1.5. Multiple Model Windows

Reason: the idea of only having a single model view on screen is archaic.

1.5.1. Two is the absolute minimum for 3D work, so you can see your plan and a 3D view at the same time. Selections in one view also need to highlight in the other.

1.6. 3D Reference Planes

Reason: It’s almost impossible to work accurately in 3D without reference planes.

1.6.1. You draw a ‘guide’ line on plan: it shows up in section or elevation. You put your building grid on plan: that too shows up in section and elevation. You set your storey heights in the Organisation window: the elevation benchmarks show up in section and elevation. How can you coordinate a building without this?

1.7. Automatic Views

Reason: VW currently has Saved Views – entirely manual, and some very basic Preset Views such as Top, Front, Back, Right etc. This is not good enough for efficient BIM working. Compare this to Revit where if you add a storey, you automatically get a floor plan and ceiling plan view for that storey. VW has the structure to achieve this – it has storeys which have sub-layers, so it’s entirely possible to generate Automatic Views for storeys.
1.7.1. These Auto Views should self-populate the Views tab of the Navigation Palette, much like they appear in the Project Browser in Revit. Defaults could be set to include floor plan, ceiling plan, finishes plan for each storey. The preset Front, Back, Left, Right elevation views should also now appear in this tab.

1.8. User Friendly Worksheets

Reason: Worksheets/Databases are a cornerstone of BIM in architecture!

1.8.1. We need 2-way access to all data fields and parameters, this greatly increases the power of  worksheets (among others, it creates the possibility to quickly change settings in a large number of objects throughout a file/project in one action).
1.8.2. Two-way access needs to include workgroup referenced files.
1.8.3. We need to be able to rotate all types of cell information including images, or see item 1.8.4.
1.8.4. Database functionality for columns (as opposed to only having Database rows) this would solve the above issue and open up for extended presentation possibilities where alternative Worksheet orientation is important or necessary.
1.8.5. We need clearer and simpler, understandable commands, functions and dialogs, this enables inexperienced users to quickly utilise the power of worksheets.
1.8.6. We need extended enhancement in presentation options e.g.. it isn’t possible to simply rotate a worksheets on a Design Layer or Sheet Layer.

1.9. Multiple Units

Reason: We need the ability to use multiple units at the same time, e.g. metres AND millimetres in the same document. Site Plans are an example of where this is required – with elevation levels and coordinate points drawn in metres (with trailing zeros and three decimal places), but normal drafting (and  dimensions) done in millimetres.

1.9.1. Not just multiple dimensions, but units which can be used within PIOs likes the Stake Object, that have their own rounding settings and their own trailing zero settings.

1.10. Stake Object Improvements

Reason: The stake object needs correcting and improving to follow architectural convention.

1.10.1. E above N (Eastings written above Northings)
1.10.2. Z elevation level at the bottom, without an ID (currently only possible if using X,Y)
1.10.3. Z value suffix option to be “AOD” by default or user string input
1.10.4. Stake marker point option of a circle with a cross (unfilled)
1.10.5. Dual metric unit support to allow metre values, to three decimal places, with trailing zeros in a document set to millimetres.
1.10.5 Auto-sequential numbering.

1.11. Roof components

1.11.1. We need roof components in the same way that we have wall components and floor components. To be compatible with Materials (Item 1.3).

1.12. Window and Door Tool improvements

1.12.1. Window Tool improvements.
1.12.2. Door Tool improvements.

Priority 2

  1. Revision Notes improvements.
  2. Full 64-bit support.
  3. FASTER, RESPONSIVE, even on huge documents!
  4. Ability to offset the top and bottom of wall components of any section of wall without having to unstyle the wall. Accessed from the OIP.
  5. Support for multiple core (structural) components in walls. (required for cavity party walls for instance, where you have a separate structural slab stopping on each side of the wall)
  6. Ability to set textures of wall components to Use World Origin. And for this to be the default setting.
  7. Selecting objects in 3D should select the foremost visible objects, instead of everything else in the background.
  8. Ability for objects (PIOs) to have two corner attributes, so they can go from corner to corner in a wall. (e.g. windows with two corners.)
  9. Do something about the awful Window Wall tool and allow us to insert doors into it.
  10. Only one type of Viewport that encompass all of the present Viewport functionalities as well as the inclusion of associative dimensioning.
  11. Ability to lock position of Sheet Layer Viewports.
  12. Ability to save Door and Windows types, preferably as Resource Browser resources.
  13. Ability for PIOs to be sensed and represented on other Storeys than the one they are placed on/connected to (like the stair tool can).
  14. Ability to override classes in Sheet Layer Viewports from referenced design layer viewports.
  15. Four-wall joins.
  16. More flexible story system. Storeys that overlap, …
  17. Stair tool improvements.
  18. Custom selection improvements.

Priority 3

  1. UK localisation of building terminology.
  2. Better drawing organisation.
  3. Better automatisation and customisation.
  4. Ability to control the default view options when switching to a 3D view (e.g. perspective projection, uncropped perspective, render mode, etc.).
  5. Ability to fit 3D Space objects to roof/geometry.
  6. Now that we can auto-bind Spaces to walls we need the ability to add to and clip them like we can with Slabs (we need this in order to adjust area calcs around stairs and door openings for example).
  7. Ability to run scripts at key moments like program startup/shutdown, file open/close, printing/export.
  8. A better way to localise content. The current system with the plugin texts is too time consuming and must be done over and over.
  9. Ability to write plug-ins in other languages than the old C++.
  10. Ability to specify the standard Class for each type of object, even custom plug-ins.
  11. Ability to specify a list of possible standard Classes for each type of object.
  12. Ability to set if the user can override the standard Class.
  13. Ability to have one base set and multiple extra sets of Classes.
  14. Ability to save a visibility set of classes, to be used with Viewports.
  15. Ability to register changes in the Class list, so VW can update older classes to the new ones.
  16. When mapping hatches or tile fills, they still need to be by class. We need to be able to switch those fills and have the mapping stick!
  17. Ability to use hybrid symbols inside roofs, instead of 3d only now.
  18. Better push/pull like the ability to reshape circle holes with it.
  19. Ability to control smoothing angle of Auto Hybrid objects.
  20. Merge the Auto Hybrid into the symbols. Less is more, especially here.
  21. New worksheets! They are really outdated and time consuming!
  22. An updated Resource Browser, think folders for all resources, a search function, ordering on different properties.

Priority 4

  1. The default view of hierarchical Class menus should be collapsed rather than open. And when we close an upper level Class the subclasses should collapse as well (or at least have the option). The whole point of hierarchical navigation is to be able to easily spot and dig down through items based on their hierarchy. You can’t do this when they’re open already.
  2. Integrated plug-in store. Like Apple’s App Store but for third-party plug-ins within Vectorworks. With ability to rate and review plug-ins, pay for them, automatically install and update them, all within VW.
  3. Ability for CAD managers to restrict users in what they can do, for helping them and maintaining an office standard. For example:
    • Editing the workspace
    • Forcing the use of a certain workspace
    • The use of certain plug-ins
    • The use of the attributes palette (All must always be by class.)
    • The use of classes (Only being able to use those found in the standard files.)
    • The use of several VW settings, like the origin which they may not use here.

Comments

  1. Andrew Chambers says:

    Full 64 bit implementation! For way way way too long we’ve been bogged down by the 32bit bottleneck. Sections are a huge issue with this as are any drawings with large iterations of small and relatively complex objects. I’m really over waiting for minutes while viewports settle themselves down after a view change or attempt to move the viewport (even in wireframe!!!) Forget about render times….