shorter

Image Prop? Otherwise, create the logo in Illustrator and export outlines as DWG. Import and extrude in VW.

Trouble is there seems to be quite a bit if disagreement as to what the best 'set up' is. 😉

Not really.

If anyone has experience of ArchiCAD and would be interested to do a little test, I would be interested to hear from you. The triangulation, and duplication of objects, not to mention the plethora of fills, it is far worse than anything I have seen from Revit or Vectorworks. I can only put it down to the 'operator' hence the request to do some tests with someone more experienced in the software. Thanks in advance.

Unless it's me, the class and layer mapping command should not move objects to the new class but simply rename existing classes thereby retaining any attributes set in the existing classes. Also, the command should also not need to have the new classes loaded into the file when you 'load' and existing class mapping file, or be intelligent enough to know to create any missing that are listed in the mapping file. It is very frustrating when you map a load of old classes and find all the objects are now in the new classes which no longer have the same attributes as the old classes.

The Internal Origin marker should be Red when there is a User Origin or Geo-referencing affecting the file. Discuss. Not every one wants to see the rulers, but arguably should know where there origin is. Yellow warning sign is often overlooked, ignored, not understood. Blue Internal Origin = good. Red = bad, or rather you need to find out why it is Red.

As predicted, suddenly the great autodesk ignorati has woken up to openBIM and are claiming it as their own. I have seen a number of posts on linkedin recently where self-styled bim-washers are proclaiming openBIM as the new black, like it's only just been invented, despite the UK government and most of Europe mandating open file exchange formats since at least 2016. So, OpenBIM is "The future of Collaboration'? Really? If the content of this post is to be believed just look at what we have all been missing out on! Who wouldn't want to open their BIM after reading this? https://www.linkedin.com/posts/thebimengineers_openbim-bim-bimmodeling-activity-7139969603593564160-XNR2?utm_source=share&utm_medium=member_desktop Still, I suppose if we let them think it's new and that they are at the vanguard they might actually engage with it as we have for the last decade or so.

Sorry to rain on this particular parade but this is not correct. The step to 'centre on import' the DWG will not result in the origin in the location you have shown it and will result in a user origin being applied to the file, that is not controlled. Perhaps we have missed a step where you have copied the data into a new file and trashed the import file in order to locate the data close to the internal origin in Vectorworks that following your example would not be still at 0,0 unless you had reset the user origin back to the internal origin? This is once again quite a lot of steps that could be acheived in one page of text.

These seems to be as invisible to the common or garden Revit user as knowing where the internal origin is in the first place.

Not always.

That's a bit destructive if you are still using the symbols elsewhere, but yes, that is one option albeit slightly perverse.

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?