2022-02-18 05:58 AM
I prefer using real RL's for floor levels (as recommended by Graphisoft) and am modelling a house on a steeply sloping site with ground level about 180m above sea level. External 3D models therefore default with 180m high columns of earth under the ground floor. Just as well I am not building on top of Mt Everest!
I can avoid this by modelling with nominal levels - say ground floor at 5m (to allow for the slope). Archicad examples conveniently model their examples on flat, or nearly flat, sites floating near sea level which entirely avoids this issue. Is there a way to use real RL's on high sites without generating this problem?
2022-03-07 04:07 AM
Hi Barry
I've tried everybody's suggestions and none of them work if one works with true floor levels (as recommended by David Shorter) instead of assumed floor levels. That is, I think, a fundamental shortcoming of Archicad.
2022-03-07 10:32 AM
So even when you type a negative value in the skirt height it does not change?
Barry.
2022-03-10 01:49 AM
I've since had a discussion with David Shorter and your solution works provided Altitude is set to 0, top of mesh is set close to the base of the building (and this value is not changed) and contours or spot levels to Mesh are set to Project Zero. Using a -ve value for the skirt will raise the base of the column and hides it.
David had a much clearer description and might write a description for this forum.
2022-03-10 02:45 AM
Skirt Height is independent of Altitude.
"your solution works provided Altitude is set to 0"
"Using a -ve value for the skirt will raise the base of the column and hides it."
Altitude 0 means it is equal to Project 0. Was this not your setup, though it should not matter what your altitude is in regards to skirt height? Is this not what you were wanting?
"One can't have a separate cut plane for elevations/sections and perspectives - or can one?"
Or going back to David's post and your response, you want the column, just to not see it in the 3D window? Cut Planes are View specific if that was an acceptable solution to removing the excess.
Ling.
AC22-23 AUS 7000 | Help Those Help You - Add a Signature |
Self-taught, bend it till it breaks | Creating a Thread |
Win11 | i9 10850K | 64GB | RX6600 | Win10 | R5 2600 | 16GB | GTX1660 |
2022-03-16 01:32 PM - edited 2022-03-16 01:37 PM
No idea if this helps with Australian standards, but we use one of the two 'reference levels' for our equivalent of 'sea level' (NAP, Normaal Amsterdams Peil). You can even rename these so you know what you are using in your project (NAP again in our case) and you can change the text in level dimensions to show dimension to project zero and to this custom level.
They do work in your working units, but then again so do floorplan levels?
It is not uncommon for the preferred 'level' of the project to change when we get closer to construction and it is just a matter of adjusting one field in project preferences and all dimensions are automatically correct, except for ussually the foundations, but those would have to change (logically).
Sea Level would work much the same, but we can't rename this field. In case it matters for IFC export, we do fill out Sea Level the same way though.
The settings.
Example of level dimensions.
Example of being able to set elements in relation to level.
2022-03-16 01:39 PM - edited 2022-03-16 01:43 PM
One more addition, sometimes we need to show this value in meters, instead of milimeters. For this we've made a custom property with the following script:
STR ( STRTONUM ( STRCALCUNIT ( {Property:General Parameters/Elevation to NAP} ) ) / 1000; 2 )
Edit: this returns a string (text) value so it stays the way we want in schedules and such (doesn't change formatting based on other numeric rules in the project).
Here's a sample text we place on layout that shows the project level in meters and the level in meters for the pile foundation parts.
If we change the level in project preferences, these values will update automattically.
2022-03-17 12:22 AM
Thank you Erwin.
2022-03-22 06:46 AM