shorter

How do you replace en-masse one rooflight with another? It is a symbol after all and one should be able to select out all rooflight symbols placed in roofs or roof faces, and replace with a different symbol but it does not even look like you can replace a single rooflight. Custom Selection and Modification 'see' the symbol but cannot act upon it. Do you really have to delete them and start again? What am I missing? (FYI, These are called 'skylights' in Vectorworks.)

Going back to the OP by @Christiaan it is an interesting conundrum; whether to model true north or not. Received wisdom suggests that because revit 'recommends' modelling 'building-centric' so should we. However, we have been finding that increasingly revit surveys are being issued true north and therefore the revit team are modelling true north and using 'scope boxes' to rotate the model view as we would with 'rotate plan', since rotating or moving a model in revit can cause irreparable damage to the model. But, and here is the rub, what if it is a new building, and the building moves on the site? What if you have a greenfield site and want to model a new build house, and the location of the house is not fixed? We often find that we have to move a building right up until setting out on site after the contractor's surveyor comes back with a revised site survey and we find we are too close to a site boundary or easement. Because we can move a model in Vectorworks without major upset (although some objects complain and we tend to recommend not doing this) it is fairly easy to make adjustments to the building position on the site. In Revit this would be disastrous. Therefore, due to software limitations Revit users will prefer to leave the model where it is and rotate and move the site using the site plan as a background. However, it is not just due to the model breaking if you move it. It is also due to the views taken that generate the drawings. Once these are set up, moving the model can have catastrophic impact on the sheets. So, one can see the logic and appeal of making the whole process building centric. As a consequence of this duality, and unlike Vectorworks, Revit has the ability to issue data in either building-centric coordinates and orientation (project coordinates and project north) or site coordinates and orientation (shared coordinates and true north) and this creates a conundrum for many Vectorworks practices; do we model as per the revit model, or to site coordinates? If you are working closely with an architect who uses revit, we recommend adopting their native revit model location and orientation and sharing IFC and DWG in 'project coordinates'. If you are the architect then we would recommend adopting true north and reference your internal origin to a sensible OS coordinate and coordinate that with the design team bearing in mind that if the building moves...bang goes your weekend.

Check the IFC export settings prior to export, in particular the site data entries. Leaving a model with the default WGS84 setting does not enter data in the IFC settings, whereas setting an EPSG code does. Not sure if that's just me or WAD. Check also that you have no peculiar data manager settings in the file particularly for IfcSite.

So the best way is to place the data tag (the 'tagger') in the design layer or associated design layer with the object being tagged (the 'taggee') so that the tagger can acquire the layer name from the taggee. We have similar issues with spaces inside symbols of unit types.

Beat me to it. Very few plugins work as expected/desired inside a symbol when they are looking for something outside the symbol. This is a huge wishlist item.

oh and did you know that the internal origin can actually move in revit, or possibly the model is moving relative to the origin. We found a huge bug.

Good job you know what you are doing... Most don't. We do exactly what you do. In fact we simply issue a DWG with an 'X marks the spot' at 0,0, with the project origin noted in Eastings and Northings (it's an exploded stake object placed with a cross because if you use the one with the circle that does not work), and they still fail to get it right because they 'centre' the DWG despite us continually saying 'Align to Internal Origin'. There is no way this works when you send them a DWG in OS coordinates already since to establish the shared coordinate system in Revit BEFORE linking the DWG is clearly beyond them. We have resorted to issuing a revit coordination file for them to use, to acquire coordinates from. This is the only thing that works seamlessly from our experience. We offer a service now to help vectorworks offices set up their coordination with revit correctly and test it as well as writing their BEPs, helping them with BIM accreditation, and providing the IM role. So many 'BIM washers' out there masquerading as IM it's a big problem. My comment re: geo-referenced DWG was not that we issue a geo-referenced DWG. We don't. But, and you may not realise this, but if a VW file has the geo-referencing settings set to anything other than WGS84, whether it's geo-referenced or not, Revit does not like it. At least that's what we have found. Nothing surprises me anymore when sharing data with revit.

This is, however, correct. There was a document issued that tried and largely failed to explain how origins work between different softwares when exchanging IFC with Vectorworks and the ONLY thing that works is a coordinated INTERNAL ORIGIN. Forget shared coordinates, etc, as these are applied coordinate systems as I keep saying. The project base point only really exists in Revit to align misaligned models, i.e. in revit it is possible and generally the case that models have disparate internal origins. 'Shared Coordinates' allows each model to be linked correctly to another, but only within Revit. I was reading another post and have to say some people are really making hard work of all this. We could set up a project and confirm alignment in about 5 mins if it were for some consultants not knowing where their internal origins are.

Not entirely true. A DWG from Vectorworks does not contain the information Revit needs to be able to acquire coordinates. Also, if you use any geo-referencing system other than WGS84, the DWG will not align correctly in Revit.

If a layer is set to invisible, it should be invisible when initially referenced, like classes. This way if we set resource layers to invisible in the source file, we don't have to turn them off after referencing them. We do this with 'non-plot' classes.

According to the help system in each... 2021 will import SKP 4 to 2019. 2022 will import SKP 4 to 2020. 2023 will import SKP4 to 2022. 2023 will import SKP4 to 2022.

Does anyone have a list of SketchUp versions compatible with which version of Vectorworks? We are increasingly having problems importing 3D Warehouse objects on older versions of Vectorworks such as 2021. Thanks.

Furthermore... If I untick the GIS settings in the layer after referencing and update, it comes back again. If I untick the GIS settings in the document settings altogether in both documents, it comes back again. I cannot get rid of GIS settings. Is this a machine/session setting not a file setting?

Under what circumstances would a file with no geo-referencing, no user origin and no layer geo-referencing suddenly acquire geo-referencing? File 'A' contains a layer 'A' containing a plan. It is referenced to File 'B', layer import referencing. Layer A is not geo-referenced. Reference it to file B and it acquires geo-referencing!? Why?

It is a huge shame that the search field in the navigation and organisation palettes for classes and layers was not followed through in other layer and class lists, particularly when searching for a new class, or layers when layer referencing, for example.

i will add that the above is why you must NEVER use the 'centre on import' DWG option in vectorworks 'recommended' or not, or in any software, for that matter!

How do you communicate the coordinate to your design team precisely if you do not define an exact coordinate? Setting out is different. Contractor will be setting out to the nearest 5mm if you are lucky so giving them a rounded coordinate of 531240000.123456789mm will only be greeted with derision, like brick dims to the nearest .5mm. If you do not set out the model to the nearest whole unit it is impossible to communicate and record precisely the coordinate at the project origin because the display value itself is rounded. To avoid errors when setting out a model, set the project origin in all models to a coordinate that is easy to write down and easy to remember.

you have a search active and it is looking 'everywhere' which includes files in multiple locations. turn off 'premium' libraries and 'vectorworks' libraries and see what's left. ideally you should create your own content library either in the 'user libraries' or if you work in a practice, 'workgroup libraries'., and download required content from the premium and vectorworks libraries and store it in the user or workgroup libraries. i would also consider renaming all content, or adding meta data to identify it as yours or practice 'approved' content.

how are the files being shared? are you simply opening the file or are you using project sharing, or referencing, or both? we have 10s of 1000s of shared files in 100s of offices, and never have any issues like this. that said, not many in the scenario you describe, i.e. different windows OS.

Without modelling separate wall finishes 'walls' how are you exporting wall finish data for COBie from a Vectorworks model? Seems to me that there are a few things that do not export via IFC that will soon be necessary (some of which we are not sure if it's just 'BIM-flation' or not, i.e. BIM for BIM's sake. 1 Materials All materials and classification of materials need to export via IFC. We will need to be able to issue an IFC and have the OFC contain the data that someone else can quantify for embodied carbon, etc. 2 Wall Finishes Wall finishes are often requested as part of COBie output because they are considered 'maintainable assets'. Has anyone seen a painted wall that wasn't? 3 Studwork We are now being told that due to current fire regulations and the impending and increasing use of the controversial 'FIREie' output, we, or someone, will have to model studwork. Given studwork is currently a zone within the wall object and not something intrinsic to it, this is going to be a bit of an overhead. You have the AIA BIM Forum documentation and the imaginary LOD350 nonsense to blame for this. #bimflation

All I know is that very large companies in the U.K. use Newforma because no one else can afford them!

Use fundamentals! 😂

make sure all classes are visible. As a test… In top/plan, create four normal walls using the rectangle mode 10m x 10m and then use the fillet radius tool set to 1m radius to create a curved wall on one of the corners. Does that work?

Well, I will look forward to your solution in 2035. For now, we set up saved views, and create a plugin that we give the short cut 'option cmd 5'. We then use 'cmd 5' for top/plan. #fedupwaiting

Oh and ps we consider it bad practice in larger offices to change pre-existing shortcuts because we have enough to do training staff how to use the software properly in large teams and stop bad habits that re-training them to use new shortcuts causes a huge amount of confusion and is frankly a waste of time, hence we think certain shortcuts should be changed to be more logical out of the box. we only apply an overlay of short(er) cuts to the existing set. We do admit though that it would not be easy agreeing which default shortcuts to use!