Setting Layer Z vs setting object's Z via OIP

[TomG]

On 1/11/07 5:40 AM, "Pam Hays" <phays@EGBERSLANDDESIGN.COM> wrote:

> I figured out I was assigning wall elevations in BOTH places

> OIP and Design layer dialog.

And why shouldn't you do this, as natural as it seemed? And yet it is a

trap. After having thought about this issue for some time, I'd like to

expand a little. Certain processes within VW support one type of project and

one type of personality more fully than another. As an example, a multi

story building where all stories stack, where the civil engineer has just

delivered the elevation of the sub-basement, and where a CAD Master has just

determined the elevations of all floors based on previously know structural

member depths--this type of project is well suited to the Setup tools and

for placing Z information onto the Edit Design Layers palette. The term

"engineered" fits this type of project fairly well.

At the other end of the spectrum are those projects for which only the

elevation of the top-of-subfloor of the first story is known. Other story

data won't be discovered for some time since zoning height and structural

depth and client preferences have yet to be revealed. Processing through

this information is non-linear and so suggests a different kind of

personality to the project and in fact, one will often find a different type

of personality doing this type of work, more artist than engineer.

Using the OIP rather than the Edit Design Layers (EDL) palette suits my

non-linear way of developing out a project. I WOULD like to mix and match

the Edit Design Layers with the OIP but, pending NNA adding a button that

turns off the automatic additive function, I just can't trust it. It would

seem a simple matter to begin with one, two or three layers (floors, for

instance) using the EDL palette and then switch to setting Z heights only on

the OIP for other nonstandard layers, but as we've seen, the EDL palette is

busy sending 3D elements on those layers out into space somewhere.

What would help would be direction within the program or within the NNA

teaching materials that recognized this difference in personalities but

alas, those resources are produced and managed by engineers. How else to

explain the years-long lapse in addressing this gap in the learning

materials produced by NNA and its contractors? Rather than recognize the

strength of VectorWorks being able to suit two kinds of projects and two

kinds of personalities, the learning materials and the Setup Tools only

successfully support one reality (although many have adapted to them,

certainly). It is the newer user who may feel the pinch of their square peg

being driven through a round hole.

I'm, not sure of the best way around this issue, at least as far as changes

to the EDL or the OIP go. I do feel that clear direction and logic of

reasoning should be provided to the user as aid in navigating through this

part of the program intelligently.

Tom Greggs

Seattle VW Users Group Leader

http://converttolines.blogspot.com

[CipesDesign]

Hello Tom, You make an interesting observation; the manner in which VW's defines "Z" space is indeed quite unique. One of the first things I teach VW's Users is how this works. As for me personally, I never use the setup assistant (in other programs either, if I can help it) because it does not allow me the type of control (w/ understanding) that I demand. I define "Z" space in both places (the Design Layer setup/edit window and in the OIP on an object-by-object basis) as well, but have a slightly different take on it: A design layer must have it's proper "Z" and "DELTA Z" set in order to stack properly with other design layers. I therefore keep a pad, pencil and calculator handy to determine correct "Z" values for design layers. This method allows me to go back later and change the "Z" value (or "DELTA Z) for any design layer(s) AND will move all objects in that layer (why would you EVER want to do this one object at a time?) en-masse. It also allows me to add/delete design layers as I go, and as needed. As for individual objects: since each exists on a design layer with a predetermined (by me) "z" height, I use can use the OIP to do things like place a porch beam at 8' . The beauty is that if I need to change the design layer's "Z" height, the beam (and everything else) will move accordingly. I agree that all of this could be covered better in the training and literature, but then, what would be left for us to teach?

[Petri]

The subject matter escapes me entirely... Maybe I'm not sufficiently artistic?

Nothing, absolutely nothing, prevents one from having the z-levels of all layers to be zero. It is not even compulsory to divide a project to layers. You don't even need to use classes - those dessspiccable remnants of 2D drafting. You have complete freedom to construct your 3D-model in the way that suits you.

[CipesDesign]

That's true Petri. But if you're not using these things (esp: classes) perhaps there are some untapped powers you have not yet discovered??? Sort of like superman before he figured out he was superhuman ;-D

[Petri]

Well, thank you VERY much, Peter! Have you ANY idea how difficult it was to find a phone booth in Helsinki, the home of Nokia?

Having now ripped off all my shirt buttons (no shirt-button-sewing -sight to fix'm back), I still can't figure out how an arbitrary coordinate system in an unstructured model would be superior to one where physical and logical components are clearly separated, indicated and editable en masse.

[P Retondo]

The problem with using layer-assigned z levels is that, although layer linking and Stack Layers recognizes these parameters and properly orients things, if you copy and paste something from one layer to another in order to focus in on a particular situation undistracted by the huge number of other objects in a building, the paste function does not recognize layer z setting. That is why I prefer to have absolute z values for every object (i.e., everything is referenced to the same assumed 0 elevation).

ArchiCAD has a better system. In layers, you can assign a "relative z" value, and by toggling look at and manipulate objects relative to the whole-project 0 level, or the secondary floor-level 0 (or whatever secondary reference you wish to choose).

[CipesDesign]

Pete, I agree. And that's why my ROOF layers ALWAYS have the exact same "Z" values as the PLAN layer on which the roof sits. That way I can cut/paste in place back and forth and not lose track of where my ROOFS, RAFTERS,etc are in "Z" space.

[Andrew Bell@NV]

It sounds like what VectorWorks could use is a paste command that adjusts for layer height, or an option to toggle between adjusting for layer height and not doing so. Which do you think would be more common? Do you tend to duplicate elements (in which case the height on the new layer should be the same as the old), or move elements between layers (in which case the height should be adjusted)? Or perhaps if you change the layer via the OI palette, the height should adjust, but not if you cut and paste?

[P Retondo]

Wow, Andrew, I'm impressed by the thoughtful response. I think for most users a paste operation that acknowledged the source object's layer z setting would be the exception rather than the rule, especially since this would be a departure from the previous operation of the tool. It would seem to warrant a "paste special" kind of treatment. A separate operation that could be mapped to a keyboard command would be ideal for me.

Changing layers via the OIP is something I rarely do, so I'm not prepared to give a perspective on that one.

One other related issue regarding layer z values - if the user could turn off the automatic augmentation of z values that takes place when a new layer is created, that would put to rest my other objection to using the feature.

[Petri]

Could the issue be resolved with or in conjunction with the planned (? - I hope so!) user coordinate system? I'm starting to see the light, thanks to Pete and Andrew.

Actually, I realised that I have to find the absolute z-coordinates of various objects quite often. Moreover, sometimes I need them from the "site zero level", the next time from "sea level" - and this in the same job, during the same day.

So, I think we need to be able to read coordinates and manipulate objects

- relative to layer level

- relative to project zero level

- relative to external reference zero level

I'd certainly give consideration to Andrew's idea of different behaviours with OI and copy & paste, but Pete's "paste special" (as a variant of paste in place) definitely has merit.

[jbrhwy]

Totally agree as I design roads & infrastructure in UTM coordinates & some extruded objects (sewers, storm drains & waterlines) are below the road & do not stack over top of each other.