Level Dimension doesn't like Reference levels?

[Thomas Holm]

I'm not sure about this, but I thought I'd be able to place Level Dimensions on the floor plan displaying relative to the Reference levels I've set using the Working Units and References Preference setting.

Placing them on the surface of meshes and slabs works fine using gravity, but they display relative to the Project Zero all the time, despite my setting efforts.

To get it right i have to edit every level dimension using the Custom Text option. Annoying.

Can anyone confirm this is a bug in AC11 -1114 ?

[James Murray]

Place the level using gravity. Select the dim text, not the dim itself. On the Info Box, where it says Measured Value, switch it to AutoText. Then choose the autotexts from the flyout.

[Thomas Holm]

Thank you very much, James, that works!

But it's still a workaround, isn't it, I am/was convinced that you should get that result immediately with the setting as attached?

Now I find that i can use your method and then drag-copies of the resulting level dimension, and it works at once everywhere! Jump for joy!

[James Murray]

I see your point, that definitely should work.

Thomas wrote:
drag-copies of the resulting level dimension

Yep that's nice.

[Thomas Holm]

Well, not THAT happy anymore. i discovered that the drag-copy works within the area covered by one item (a mesh or a roof) but when you delve out of that, for example over another roof, it wont work. It displays the level as it would be had the first roof extended to the current place, instead of using gravity at the new position.

What happens is that the Autotext (when copied) somehow reads the first level and recalculates for the new position using the extended plane/slope of the first roof and the distance from the first position

So if you use drag a copy on a level dimension, be careful. Check and double-check! When above another roof, you have to place a new dimension using gravity, and then edit like James described it.

[James Murray]

Thomas wrote:
What happens is that the Autotext (when copied) somehow reads the first level and recalculates for the new position using the extended plane/slope of the first roof and the distance from the first position .

Well that's intuitive, not. I've only used that technique for meshes so I haven't been bitten by the roof thing.

I think level dims are due for a do-over. I've always thought it strange you had to turn on gravity to get them to behave like a dimension rather than an object. After all you don't have to instruct linear dimensions to really dimension something. It's also awkward to place a level dim on the slab (e.g.) you want. I believe the only way to be sure is to hide the layers of the stuff you don't want.

It might be better to select the element you want to dimension and say 'Place Level Dim', similar to 'Label Elements'. Then if you dragged the dim too far it would warn you.

I'm sure there's more to it but gravity should be about model elements, not annotations.

[Thomas Holm]

Can't agree more!

I was using roofs to model a sloping road in this case. Not my usual method, but convenient here. Guess I found this problem by chance. Thanks for your help!

[Anonymous]

It's totally natural that level would behave like this, because it is connected to the roof that you place it on. If you don't make the software behave like this you could get enormous problems later, lets say you have alot of roofsobject on each other that represent inner roof, outer roof and so on, which roof should level object act with if you turn the other roof on??

Levels and dimensions should NEVER be copied, only inserted as new one. Or else you are in a danger zone where you have faked static information on your modell and not interactive.

Thomas wrote:
Well, not THAT happy anymore. i discovered that the drag-copy works within the area covered by one item (a mesh or a roof) but when you delve out of that, for example over another roof, it wont work. It displays the level as it would be had the first roof extended to the current place, instead of using gravity at the new position.

What happens is that the Autotext (when copied) somehow reads the first level and recalculates for the new position using the extended plane/slope of the first roof and the distance from the first position

So if you use drag a copy on a level dimension, be careful. Check and double-check! When above another roof, you have to place a new dimension using gravity, and then edit like James described it.

[Thomas Holm]

TurboGlider wrote:
It's totally natural that level would behave like this, because it is connected to the roof that you place it on. If you don't make the software behave like this you could get enormous problems later, lets say you have alot of roofsobject on each other that represent inner roof, outer roof and so on, which roof should level object act with if you turn the other roof on??

I believe you're right, programmer-logic-wise. The problem with this surfaces when I copied a level dimension in the floor plan to a spot outside the "current" roof's polygon - there I got a displayed non-existent "virtual" reading to a non-existent "virtual" extension of the same roof's projected surface plane. Not very useful.

For ease of use, the level dimension on the floor plan should behave differently: If I have gravity on, and a certain reference level active, it should display the distance to the reference level from the surface point below the spot where I place it, like if I dropped a ball there. And this should work the same wether placed or copied (unless the original was static, that should trigger a warning).

[Anonymous]

A level object maybe should be prompted with an !* or something else that tells you that it's not it's original place and therefor could give you wrong height? (like if you drag it off from original plane and over another one)