shorter
-
Posts
3,098 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Articles
Marionette
Store
Posts posted by shorter
-
-
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.
-
1
-
-
17 hours ago, zoomer said:
Any Elements Z value in OIP should have a dropdown to select
if it applies to its Layer height or as an offset to a Story Level (?)
(At least to those Story Levels that relate to its Layer ....
when bound to a Story that contains Levels ?)
Oh wait, then when every Element belongs to a Story and Level ....
why do we still need Layers ?
It gets complicated for me here.
At least all PIOs should have a general Level binding
(As most do, like Walls or Stairs, but so far e.g. Doors and Windows don't)
AND PIOs should have Component bindings.
(As most do, like Walls or Stairs)
E.g. Windows should derive their overall height from Sill and top Level.
Standard non-PIO Elements or Symbols may only need a general overall Level binding.
Or do we need e.g. Extrudes defined by top and bottom Levels (?)
I am not sure if a coping could/should be already part of a Wall Style
(Like a control over a Wall End appearance when not connected ?
controlled by Wall Closure Settings ??)
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.
-
2
-
-
16 hours ago, zoomer said:
That sounds like a solution ...
we just pack everything we want to control by a story Level - into a Symbol
😉
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.
-
9 hours ago, frv said:
Thanks Zoomer, for the tip checking out German forums.
@shorter, maybe a workflow issue but only someone with good Archicad knowledge would know. I have 35 years experience with VW and at the office there are some who have a workflow going that is hard to beat but still frustrating. Too many BIM related maintenance and work-arounds in the workflow compared to Revit (which we work with as well) and Archicad ( as we assume) .
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.
-
On 2/16/2024 at 5:28 PM, JW_OO said:
Hi all,
Sorry if I have missed anything but we are in the midst of setting up a design studio and with that comes the choice of software and server/cloud etc. The choice has been Vectorworks and Sharepoint (before I began). I am now looking at efficient ways for us to utilise the Project Sharing option within Vectorworks.
Am I right in saying that as we have Sharepoint and Vectorworks, that is not possible? It just seems a huge pain to download the file every-time and risky to say the least given we will shortly grow to around 15 people and need to have the ability to share/work/sync...
Any advise would be great!!
Thanks
O
Two things we have successfully avoided in large teams: Sharepoint and Project Sharing.
-
On 2/17/2024 at 9:01 PM, frv said:
Hi, I have a small office and work often for a larger architectural firm as well. I am looking into switching to Archicad. I need a smoother workflow to IFC and BIM related projects. I have plenty years experience with VW. We have reached the limits of what you can achieve with VW and IFC exchange. But still, unacceptable long refresh times (hours !) of viewports and a number of rather serious IFC problems.
Is there anybody out there who has done big projects with Archicad can give some advise. Is IFC exchange as cumbersome as VW. Does Archicad also take for ever to update a set of viewports. Does Archicad geometry also easily loose data and settings. Does Archicad also misses important geometry when exporting to IFC. In other words, are VW problems basically the way to is for all BIM CAD software or is VW really so far behind.
Sounds like a workflow issue, rather than Vectorworks, TBH.
-
More than likely. It was a student using 2019 whilst the office uses 2024...
-
-
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?
-
1
-
-
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.
-
1
-
-
Ok. Needs testing!
In which versions have you had these issues?
-
Just now, shorter said:
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!
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.
-
Then you need to establish the coordinate system in your file BEFORE importing the point cloud, or for that matter, any file like DWG or IFC, if the files received are located in true world coordinates, and by this I mean the X,Y coordinate system of the country, region or city in which the site is located.
We have a strict method for the process of setting up a project which DOES NOT align with the 'recommended' import settings within Vectorworks where you 'centre on import' thereby losing control of where the user origin, and therefore the coordinate system, is located.
And fortunately it is very simple and does not result in a thesis or diatribe on origins.
All you need to do is...
-
Do not use Geo-referencing unless you know why you are using Geo-referencing, and make sure all design layers are the same layer scale. That's all I can think of.
2D v 3D views might also affect the coordinate readout.
-
1
-
-
I would prefix each file with the author code at the beginning of the layer name on import, not at the end i.e. RVI-1e. etc.
-
1
-
Default Storey Levels
in Wishlist - Feature and Content Requests
Posted
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.