Working with building models in real-world orientation and elevation

[Christiaan]

This is to keep a list of impediments to working with building models in real-world orientation and elevation. One, to assess whether we keep working in this way, and two, to use it to create/keep track of related enhancement requests and/or bug reports.

 

Working totally in rotated view, with building model placed at real-world orientation to North (and real-world elevation), is my preferred way of working because it means that once your files are initially set up there is no rotation or changing of z-height of anything copied and pasted or referenced across files (e.g. site mode file vs building model file). Elevation Benchmarks also work without needing to add offset figures. This reduces chances of errors, saves time for those working on the project, and is a more intuitive way of working (in terms of thinking about the building model).

 

There are, however, a few impediments:

1. Does it make it more difficult for other consultants using AutoCAD and Revit for example? I don't know. Somebody want to comment on this? Jeff seemed to think so.
2. The cmd/ctrl-5 short-cut unrotates the view. (fix coming in 29.0.4)
3. Editing a site modifier polyline unrotates the view.
4. Editing a Space object boundary unrotates view. Fixed at some point, not sure when.
5. Interior Elevations are spread far and wide beyond page boundaries when generated from a rotated view.
6. Primary views (left, right, front, back) ignore rotation. This is resolved by Working Plane Views mode.
7. Can’t use numeric keypad for front side views when editing 3D symbols 2D components. Putting this here temporarily. I need to retest this one using Working Plane Views mode. 
8. Working with building models at real-world elevation can cause issues with Working Planes, in that objects can end up being drawn at z=0 instead of at the height of your building model. Feel free to elaborate on this one and explain how this can/should be avoided.
9. When you draw something in a front/side view + haven't set a working plane: then the object can end up hundreds of miles away from the internal origin with all the problems that creates i.e. it is drawn at 0 on the X or Y axis as determined by your georeferenced user origin.

If there are any other problems you encounter please post them here.

[Christiaan]

Useful related comment on rotated setup:

https://forum.vectorworks.net/index.php?/topic/109100-user-origin-marker/#comment-475503

 

[Christiaan]

On 7/11/2023 at 8:33 PM, shorter said:

3. The coordinate defined at the internal origin should accurate to the nearest site unit and not rounded ie the nearest metre but ideally to the nearest 10m. eg

 

531240m

185720m

I'm in the habit of using a station point or a physical element on or near the site that I know is not going to change. So therefore never ends up being a nice round number like this. Why am I in the habit of doing this? It doesn't really matter to the builder what coordinates I use to define the internal origin does it.

 

 

[line-weight]

I don't do this, because the nature of my projects is such that I don't generally use referenced files, and any elevation heights are always relative to a local datum.

 

The various issues you mention, mainly to do with rotated views, mean it's not worth it.

 

However if there were a frictionless way to have the model's orientation and elevation in a correct relation to the outside world, I would certainly use it. Could make things like heliodons and north points automatically correct, and presumably also make life easier if I started using georeferenced imagery more.

[Tom W.]

1 hour ago, Christiaan said:

Working with building models at real-world elevation can cause issues with Working Planes, in that objects can end up being drawn at z=0 instead of at the height of your building model. Feel free to elaborate on this one and explain how this can/should be avoided.

 

I'm not sure how this would ever be an issue because you're generally using the Layer Elevation to set the Z height for where you want objects to be drawn/placed...? You'd normally give your building model layers real world elevations + where the layer elev is 0 it's because you want the objects on that layer to have a real world Z height e.g. the site model or they are annotations or whatever + it's fine for them to be at 0.

 

What can be an issue however is when you draw something in a front/side view + haven't set a working plane: then the object can end up hundreds of miles away from the internal origin with all the problems that creates i.e. it is drawn at 0 on the X or Y axis as determined by your georeferenced user origin.

 

With the exception of item 1. which I can't comment on I think the impediments you identify are fairly minor + far outweighed by the benefits. In my experience at least.

[Christiaan]

 

51 minutes ago, Tom W. said:

You'd normally give your building model layers real world elevations + where the layer elev is 0 it's because you want the objects on that layer to have a real world Z height e.g. the site model or they are annotations or whatever + it's fine for them to be at 0.

This is where I remember having an issue. 3D views of a site model with objects also at zero are not easy to navigate.

[Christiaan]

54 minutes ago, Tom W. said:

What can be an issue however is when you draw something in a front/side view + haven't set a working plane: then the object can end up hundreds of miles away from the internal origin with all the problems that creates i.e. it is drawn at 0 on the X or Y axis as determined by your georeferenced user origin.

Added to list.

[Tom W.]

2 minutes ago, Christiaan said:

 

This is where I remember having an issue. 3D views of a site model with objects also at zero are not easy to navigate.

 

I draw underground services for example as 2D annotations at Z=0 (but above everything else in stacking order) but they are on layer/s which are never visible in 3D views

[Christiaan]

Yeah, okay, separate layer is a good solutionmostly, but, for instance, add some car parks with the Park Spaces Tool and they will be located at z=0.

[Tom W.]

I draw them as 2D annotations too I have never looked at Parking Spaces Tool! But isn't it the same thing: use Saved Views + make sure any 2D classes/layers are turned off in 3D views?

[shorter]

On 11/23/2023 at 10:20 AM, Christiaan said:

I'm in the habit of using a station point or a physical element on or near the site that I know is not going to change. So therefore never ends up being a nice round number like this. Why am I in the habit of doing this? It doesn't really matter to the builder what coordinates I use to define the internal origin does it.

 

 

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.

[shorter]

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!

[Matt Overton]

This wouldn't work in Australia as we are too far from the co-ordinate origin to have workable hatches. 

[FranAJA]

Since the only drawing in real coordinates is the site plan, which makes up a minuscule 0.001% of the project documentation, we typically set the internal VW origin to a known reference point, such as a GPS station point from the survey. This allows us to rotate the survey north to our project north, eliminating the need to rotate the view for every individual drawing.

 

For the sake of providing the contractor with a site plan with real coordinate points, we reference the file into a new one using real coordinates. However, in most cases, simplicity is preferable, as real coordinates are not widely used in the UK except for road kerbs and foundation poles.

Real coordinates can introduce numerous issues, such as graphical glitches, erratic orbit behavior, and misaligned 3D views with the working plan. Based on my ten years of experience with Revit, I can assure you that any export from Revit imported into VW will be a model positioned at the Revit internal origin.

 

Revit employs three distinct origins: Project, Shared, and Internal. The best practice is to keep the Project origin coincident with the Internal origin and lock it in place. While 90% of UK companies lack proficiency in using Revit's shared origins, this doesn't hinder interoperability with VW. The crucial aspect is ensuring the model's position relative to the internal origin aligns precisely with its position in VW.

Providing Revit consultants with a DWG file containing your setting out grid can assist them in maintaining accuracy from the outset. Failing to do so could make it challenging to rectify any errors in the future.

 

Edited December 4, 2023 by FranAJA

[Christiaan]

21 hours ago, Matt Overton said:

This wouldn't work in Australia as we are too far from the co-ordinate origin to have workable hatches. 

Can you elaborate Matt?

[shorter]

On 12/4/2023 at 11:38 PM, FranAJA said:

Providing Revit consultants with a DWG file containing your setting out grid can assist them in maintaining accuracy from the outset. Failing to do so could make it challenging to rectify any errors in the future.

 

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.

[shorter]

On 12/4/2023 at 11:38 PM, FranAJA said:

I can assure you that any export from Revit imported into VW will be a model positioned at the Revit internal origin.

 

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.

[FranAJA]

9 hours ago, shorter said:

 

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.

 

I never mentioned a georeferenced DWG. In Vectorworks, simply create a grid in a local coordinate system centered on the internal origin (0,0,0 coincident with a known survey point on the site survey), then lay out the building grid and provide the DWG to the Revit team to use for their model. In Revit, they can use the shared origin between their revit consunsultant to set the coordinates they want. I've done this several times and it works seamlessly.

 

Edited December 6, 2023 by FranAJA

[shorter]

18 hours ago, FranAJA said:

 

I never mentioned a georeferenced DWG. In Vectorworks, simply create a grid in a local coordinate system centered on the internal origin (0,0,0 coincident with a known survey point on the site survey), then lay out the building grid and provide the DWG to the Revit team to use for their model. In Revit, they can use the shared origin between their revit consunsultant to set the coordinates they want. I've done this several times and it works seamlessly.

 

 

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.

[shorter]

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.

Edited December 7, 2023 by shorter

[shorter]

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.

 

 

[FranAJA]

Hi Shorter,

 

I previously created a tutorial for my office on how to coordinate files between Revit and VW. Please find it attached. RVT_VW Coordination.pdf

Before addressing your concerns:

 

In Revit, 3D surveys always adhere to true north and original coordinates. However, this may differ from what you require. The surveyor can duplicate the file and place the project in the coordinates necessary for your purposes upon request. It's manageable with clear instructions.

 

Moving the project within Revit is perfectly fine; sheets and sections remain unaffected unless the internal origin is also relocated. To achieve this, there's a "Relocate Project" command available. A Revit user can move both the internal and project origins to the new point you specify. Some coordination is necessary, but it's entirely achievable.
Of course if the building will be moved from the internal origin, will be an issue. In that case they should relocate the project at the new position and export IFC using project point.

Hence, ensuring the coincidence of the project and internal origins is crucial.

 

 

Edited December 15, 2023 by FranAJA

[shorter]

39 minutes ago, FranAJA said:

3D surveys always adhere to true north and original coordinates.

Not always.

[shorter]

42 minutes ago, FranAJA said:

 

Moving the project within Revit is perfectly fine; sheets and sections remain unaffected unless the internal origin is also relocated. To achieve this, there's a "Relocate Project" command available.

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

[Christiaan]

On 12/12/2023 at 12:08 AM, shorter said:

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.

 

 

This is excellent info, thanks Steven. I actually went through this process in Vectorworks once, when I changed a file from building-centric to site-centric. It was indeed a pain in the ass and screwed up all my viewports. As always in VW there was a number of ways to do it, and I found that a certain sequence of steps was a lot less painful than other sequences.