shorter

You would struggle is you are building a model. Creating an Axo is one of those peculiarly difficult things to do from a 3D model. You can get close but it is not technically an 'axo' by using the rotate 3D view command, but otherwise the only standard views available are isometric, which TBH, I always found far more appealing than axos which we always found clunky in comparison. Perhaps that's because my generation were more Peter Wilson, than Jim Stirling. But @Jeff Prince is spot on! Tough assignment!

Currently we can save DWG export settings; a great tool and a massive time saver. However, sometimes, the export settings very depending on the view or file we are exporting from, and therefore it would make sense for the settings to be file specific, like ifc export settings. Also, while we can save DWG export settings they need to be distributed to staff since they do not get picked up via the workgroup folder settings. This can be quite a challenge to maintain in a large office (or in my case many large offices).

Ditto. We remove the default storey levels file completely from the standard install and set up our own. It's useful to have a default set since they are then automatically applied to the storey when you set them up from scratch or when using our 'BIM Setup' command.

Who else thinks that the default storey levels should update all storeys when changed? If we set our default 'Structural Slab Level' to -100mm, for example, at the start of the project and then change our mind when the floor buildup becomes a bit more resolved, it would seem logical that the 'default' structural slab storey level should control all instances of that storey level in all storeys of the building, no? It seems to me that when we set storey levels we need a button like in styles, to make this 'styled' or 'instance', i.e. default or user editable.

We are in the process of moving 100s of projects from one server to another so it would be desirable at the moment because without it we have hours of work reattaching references. Relative referencing is inflexible, admittedly, but it is very reliable and great when archiving or moving a project. Tip: When planning such an undertaking (moving data from one server to another) make sure everything is discussed, agreed and most importantly, tested with your IT support, before moving the data. We have done this many times over the last 20 years or so, and there are options, but ensuring all referencing is relative path from the outset would alleviate any long term problem. You simply cannot rely on staff to remember to do it.

I wish, like Microstation, that we could configure Vectorworks to always reference with relative path. It is currently down to user selection, and with all due respect to busy architects and designers everywhere, you have better things on your mind than to remember to click 'Relative Path; when you reference two files together.

The problem we have is that we get involved in projects that require non-standard details, and tends to mean we cannot use standard PIOs. It is why we never use the stair tool, for example. Even doors have to be placed inside symbols to provide the required 2D representation at the jambs, etc, or when combined with windows or none standard openings. Other than the joy of 'thinking through modelling' this way, we get exactly what we want. The coping options would need to be far greater than the frankly embarrassing array of window cill options currently available.

As do we. However, in this instance, I wanted to test the idea of associating a coping, which would not normally be converted to a symbol, to a storey level.

A couple of tests you can do. Make sure the titlesheet border does not contain any text fields defined by text styles, including by class. We found this was one of the main reasons the sheet moved in 2022. If you are using the 'Architect.sta' templates by Vectorworks, stop and create your own templates. We found that when files are linked via referencing, 'old' invisible VW titlesheet record formats were conflicting with our new titlesheet library with it's ISO19650 compliant fields, and the titlesheet would move, or data would be deleted. And finally, right click on sheet border style, and locate in resource manager. Right-click and check plugin options. Check the default class used.

Despite some inherent limitations in the way storeys and storey levels work, it would be really useful to be able to associate any object to a storey level, not just symbols or certain PIOs. For example, rather than add an edge beam as an extrusion or extrude along path to a slab, the extrusion could exist separately but be associated to the same 'SSL' storey level as the slab itself. Of course, if objects could 'see' storey levels outside a 'container' like a solid addition or subtraction, or symbol this would be the sugary white substance on the proverbial flour and egg based confection.

I'm stil intrigued to know what workflows in vectorworks cannot be made to work? revit cannot and should not be seen as the benchmark. we know it is deficient in many areas where other softwares are superior, but it's now the lowest common denominator, and like starbucks becomes the dumb-down metric against which all other software must be measured.

I am talking about the workflow in vectorworks.

This is a regression. There was an option to ignore them when converting. Where has this option gone? Also, it would be great to include folders where we define keywords like 'Superseded'... and any folder containing the keyword are also ignored.

Two things we have successfully avoided in large teams: Sharepoint and Project Sharing.

Sounds like a workflow issue, rather than Vectorworks, TBH.

More than likely. It was a student using 2019 whilst the office uses 2024...

And geo-referencing!

I have been sent a file that is 'fingerprinted' not 'watermarked'. I know that there are files that are 'finger-printed' amongst the resources, but it would be odd to have a document fingerprinted unless they did a save as of a resource file. I thought that it was content causing the issue but from you are saying they would have had to have created a file from an already fingerprinted file. Does that mean if they create a new blank file, and copy data from the old file to the new, it will fix it?

... how do you find out which objects have caused it to become finger-printed?

Use Fit Walls to Objects instead?

I will back-track on the point clouds we have been sent and recheck. We received a load of point clouds of trees on one project for a TPO and planning application and am pretty sure they arrived in the right place, aligned to the UO, but that was VW2019, and when I tested again in 2024, the model aligned itself correctly.

Ok. Needs testing! In which versions have you had these issues?

ps. I have different issues with point clouds but they are not related to the above.

This is not my experience with point clouds. They have previously responded well to import into a file in which a controlled user origin has been explictly set. This after all is what 'centre on import' is doing, except with no control!

Prego! FFR, ALWAYS request a naming convention for storeys (levels) in all models to be included in the BEP. The storey is another form of container, and thus should adopt similar the fields to the file name, if you are following ISO19650 or similar. So, for example, if you are using ISO19650 your file name could be something like ABCD-EFG-A-ZZ-M-A-020000-ArchitecturalModel, the architect's model for building A, containing all levels (ZZ) or as we prefer ABCD-EFG-001-000-M-A-020000-ArchitecturalModel, where using numbers not letters results in files listing correctly in a standard OS finder... 😉 You do not need to use all these fields in a storey name, but the author code, or discipline, building (functional breakdown), location (spatial breakdown) and level description certainly help. EFG-A-00-FFL for example, could be the ground floor storey for company 'EFG', for building 'A', related to finished floor level. This could equally be written A-001-100-FFL Architecture - Building 001 - Ground Floor - Finished Floor Level The question though, is whether the federated model needs to adopt the same level naming for quantity take-off, for example. It would be similar to having a single grid for the project. Something for the IM to confirm which is why it so important this is defined in the BEP. It would cause havoc in vectorworks though unless you adopt one startegy for layer and storey naming, and export with a different name, which is always possible.