Directing 3D Elements to a Story

[Anonymous]

Hi,
When drawing in 3D; is there a way of locating an element in a certain story? Every element that I draw in 3D automatically goes to 1st floor. Even slabs that have the option of CURRENT STORY are placed at 1st story when the plan window is at 2nd story. If this is the way it works, so how every one else draws in 3D?
Thanks,
Joseph Harouni

[Karl Ottenstein]

Another question on this tip since it might lead me to working more in the 3D window.

I want the beams that support the first story floor system to appear in the ground story plan (used for the first story framing plan). To get a quick click/double-click beam to appear at the right place in 3D, I have to set my user origin to the top of the ground story walls (for example). The beams then appear in the first story plan. What's the trick to being able to draw them where they belong but have them appear on the story that I want?

Thanks,
Karl

PS Also: am I the only one who would like the option of seeing the relative dimensions of things - say the beam - in the Info box when I'm in 3D (just like in plan) rather than their absolute heights? I have to subtract b from t in my head, or else open object settings to see how deep a beam is when working in 3D. Sometimes I want one (when editing other elements to match in height), sometimes the other (when I want to know or change the depth of a beam). Am I missing something, or should this be a wish?

[Anonymous]

You've got two wishes going here Karl.

Consistency in 3D; stop strange snapping to project zero.

Elevations in info palette relative to current/home story.

I look forward to voting for them

[Djordje]

Karl wrote:
Am I doing something wrong, or shouldn't R in the 3D window behave the same way that it does in 2D and recognize which direction you have gestured with the mouse? I behaves that way when you drag, but when you make an entry, it behaves as if it is an absolute value relative to project zero.

It is relative to project zero; take another look at your screen shot! You should change the Z relative to user origin if you want to work relative to it; or input absolute values relative to project zero.

[Djordje]

Matthew wrote:
You've got two wishes going here Karl.

Consistency in 3D; stop strange snapping to project zero.

Elevations in info palette relative to current/home story.

I look forward to voting for them

Hmmm ... Matthew ... that mocha was good, not you owe me another one:

The Z can be set to project OR user defined zero - see the little arrow pointing right below the Z coordinate box?

[Laszlo Nagy]

Djordje wrote:
As Laszlo suggested, using Gravity on placed slabs also helps ... Laci, could we have movies on ArchiGuide?

I will ask GS about this, it hasn't come up yet.
Laszlo

[Karl Ottenstein]

Djordje wrote:

Karl wrote:
Am I doing something wrong, or shouldn't R in the 3D window behave the same way that it does in 2D and recognize which direction you have gestured with the mouse? I behaves that way when you drag, but when you make an entry, it behaves as if it is an absolute value relative to project zero.

It is relative to project zero; take another look at your screen shot! You should change the Z relative to user origin if you want to work relative to it; or input absolute values relative to project zero.

You've only confused me more!

The screenshot shows relative to user origin, not project zero, and Z entries behave that way. The problem is R entries. In 2D, R has nothing to do with the origin or user orign - it is a relative distance from the first click (radius dimension). In 3D, I find nothing relative about it. Entering an R value is treated as if it was an absolute Z value. Isn't this inconsistent with 2D, or am I still missing something?

Thanks! 😉

Karl

[Anonymous]

The R value in the Z direction in numeric entry has been screwed up since editing in 3D first became available in AC6.0. As a result I have avoided using it ever since. It seems as if it's still a problem. This should be fixed.

[Djordje]

Karl wrote:
The screenshot shows relative to user origin, not project zero, and Z entries behave that way. The problem is R entries. In 2D, R has nothing to do with the origin or user orign - it is a relative distance from the first click (radius dimension). In 3D, I find nothing relative about it. Entering an R value is treated as if it was an absolute Z value. Isn't this inconsistent with 2D, or am I still missing something?

Oops, sorry! Misunderstood you!

Yes, the R is inconsistent, but IMHO only because of a different playing field. However, it depends on how you use it. If you are stretching a wall horizontally for example, it works just as in the plan window. Same for radiuses. I usually use it in 3D with locked angles, and in that case it works nicely. If I want to work on the Z distances, I use Z ...

[Anonymous]

Djordje wrote:
Yes, the R is inconsistent, but IMHO only because of a different playing field.

I honestly don't understand why this is necessary. If I am stretching something in the Z direction I would expect that the value of R would be measured from where I start and not from project zero; just as it does with X and Y in both plan & 3D.

It would also be nice, if I keep the cursor at my starting point, that R would be measured from the other end (top or bottom) as linear elements in X and Y do. Since stretching vertically is automatically constrained, it seems this would be easier to work out than the horizontal dimensions.

Djordje, like you, I stick to typing Z values; using the on screen calculator when the one in my head fails me.

[Djordje]

Matthew wrote:

Djordje wrote:
Yes, the R is inconsistent, but IMHO only because of a different playing field.

I honestly don't understand why this is necessary. If I am stretching something in the Z direction I would expect that the value of R would be measured from where I start and not from project zero; just as it does with X and Y in both plan & 3D.

If you noticed - the inconsistency is, AFAIK, in the fact that in vertical (Z) transfromations R is used from a USER origin (try to change the height of a wll by grabbing the bottom hotspot) and that the R is measured from the currently placed origin, not the grabbed point. Think about it - it is the same way as in 2D, only vertically. So, in a sense, it is consistent. In 2D you cannot work in the vertical plane. Therefore I would not expect the same rules to apply - but they do, in a different way.

Matthew wrote:
It would also be nice, if I keep the cursor at my starting point, that R would be measured from the other end (top or bottom) as linear elements in X and Y do. Since stretching vertically is automatically constrained, it seems this would be easier to work out than the horizontal dimensions.

Agreed that it would be exactly as in 2D; however, even in this case it is logical, and maybe too intelligent: if you grab the bottom node, the user origin appears at the top of the wall, and r100- yields a wall 100 units lower than the origin, while r100+ yields a wall 100 units higher. In both cases correct. If you do the horizontal (XY plane) transformation, it works just as in 2D.

Matthew wrote:
Djordje, like you, I stick to typing Z values; using the on screen calculator when the one in my head fails me.

The one in my head is on vacation; last couple of days I am too fuzzy to calculate anything. Maybe four deadlines looming early next week have to do something with that?