Jump to content
  • 1

What is wrong with those story levels?!


Dieter @ DWorks

Question

It's been some time that I actually had to draw much in VW, but the 'new' way story levels work is driving me crazy? How could someone get away with this? He who designed this should be fired! It is way to restrictive and you end up with lots of stuff you don't want. Let me explain in more detail some points of this:

- Why have the default levels in a drawing the same height offset? It's nice to have an initial default offset so that you can go with that at first, but not all building will have the same height offset for some type of level. Now when you edit the level, you end up with two levels of the same type but with different offset Heights. This is crazy, I just want to use that default level type, but have it at a different height offset.

- The same counts for the layer you can add to the default level. This should only serve as an initial setup when you add that type of layer, but if you don't want it, then let us remove it for that story.

- Let us bind existing level types to existing layers. Why can't we? It's crazy. Do I really have to create a new layer through a level type and then move all objects to that new layer and delete the old one?

- And the list goes on....

I thought that they had all this story stuff worked out after the previous disaster, but it's just got worse. So please revision this so that it just works and is user friendly!

Link to comment

Recommended Posts

  • 0
My take away from this thread is that VW needs an visual interface designer. Ironically most wishes on this list centre around this.

This is so true. Also needed are some person-off-the-street-non-engineer-simple-instructions. The software industry generally needs to get away from VCR instructions and make instructions for real users. If you are old enough to get the metaphor, you will remember that EVERY VCR had a clock, and that clock always blinked 12:00 because no one could be bothered to figure out how to set the darn clock!

The reason VW & CAD software in general gets away with such poor interface, documentation and instruction is we users tend to be a little bit on the geek side and like to monkey around with this junk, so we accept second rate design. Odd since we are in the design business!

A better interface on the Service Select would also be very helpful. Were it not for Benson Shaw's helpful link on another post to Wes Gardener's tutorial pdf I'd not have found some of the help I need on this issue.

However, when the instructions for LEVELS includes this gem:

"EDITING

The method and steps for editing levels may appear a bit confusing at first."

We are all DOOMED!

Link to comment
  • 0

Good analysis Benson.

I can see how storeys could benefit a user when working on larger multi-storey projects. The benefit of having layers "linked" together (which essentially is what the storey feature does) comes into play when making adjustments to floor or ceiling heights on those types of projects.

But I mainly work on small alterations and additions, where I'd rarely go over 2 storey in heights. So storeys aren't that important to me.

Levels, on the other hand, has my interest. I have VW 2012 so I'm not familiar with the VW level concept within storeys (levels introduced in VW 2015).

One of the first things I do on a project (like everyone else) is to resolve floor and ceiling heights. I draw a series of horizontal lines on paper, give them an RL, then away I go.

VW 2015 would give me the ability to create a level and bind objects to them but there is no visual reference to the levels within any of the drawing's views.

FWIW, I think if Nemetschek gave us the following:

1) ability to create levels

2) bind objects to levels and layers

3) turn desired levels or layers into benchmark elevations viewable in sections and elevations

4) link layers together

we would have all the functionality of stories without the storey container.

Personally, a renovation feature would be of more use to me than the storey feature

Edited by Kizza
Link to comment
  • 0

I agree with Benson on his last post. I'm only about 8 months now into vectorworks but there is plenty of stuff I'd like to know more about but find difficult to navigate thru. Stories has been one of them. I tried it at one point but gave up due to time constraints and stuck to layers which is much simpler, but...I have already had situations where the binding of components in wall styles would make updating a model very easy, hence the argument for stories. A good example would be changing for instance the size and type of floor joist for a given floor. Going from a 2x10 joist to an engineered 11.875" joist isn't just about a height difference but also a component(material) extension change like sheathing and siding that needs to cover the header joist whether its a 2x10 or an 11.875" joist. Bindings in stories help alleviate having to go back to the wall style and adjust for these minor differences in height.

I'd like to use the program better too and use what it's got, cause from what I read it does work.

Cheers.

I'm going to the Design Summit in Philadelphia at the end of the month and would be cool to meet up with any of you who are going too.

Link to comment
  • 0

The whole Storey Tool is far to complex. I think Kizza's idea of Layer Linking (not the old-school MiniCad version) is the closest to what's required.

While components need to be sorted vis-a-vis where it lives in a Layer/Storey this should be in the OIP. Right now there is too much mental gymnastics.

I know this sounds like: Just-use-layers-and-forget-about-Storeys but that's not what I mean. I'm suggesting a hybrid; use the Layer Link as a way to stack a Storey, but allow each component to be dynamically linked to a Z within the Storey w/o all the clutter.

By allowing the Layer Link ability, it would allow one to much more easily to link Sets of Storeys. This is important in a multi building project where each connected building has a different Grade Entry ( see my post on Half Height Storeys).

Link to comment
  • 0
Guest Wes Gardner

Hi All,

This is a great discussion...

I cannot take responsibility for the "design" and implementation of the level/layer/story system.

I will and DO take responsibility for the tutorial - that was all me. If I wrote something inappropriate or incorrect, please let me know.

I will continue to attempt to explain how levels,layers,stories, wall styles and slab styles interact with one another. It IS something you need to get your head around.

BTW, I have created an "All Blank" template file that is just that - completely devoid of default level types. This sometimes helps me develop stuff...

Wes

Link to comment
  • 0

Thx for all these great views on this subject, but let's not forget simplicity/consistency here and get to the core of it. In essence, this is how it should work: (forget the DL linking to Level types! that's absurd, DL should be able to be at a level type like walls do, so we can have multiple DL at the same level type of that story!)

ubbthreads.php?ubb=download&Number=12088&filename=Story01.png

ubbthreads.php?ubb=download&Number=12089&filename=Story02.png

ubbthreads.php?ubb=download&Number=12090&filename=Story03.png

Edited by Dieter @ DWorks
Link to comment
  • 0

Currently :

When I duplicate a Layer that has a story assigned,

the new Layer will have no Story assigned.

I think that is wrong.

When I duplicate I want all settings of the previous layer.

Otherwise it is called "create new layer".

When I assign a Story to a Layer, it automatically sets a layer offset

negative to the new Story hight. I don't like that.

Link to comment
  • 0

@Kizza

Correct. Levels are a feature of the Story/Level/Layer "system".

To start it all off, In vwx versions with Story functions, open the Organization Palette>Story tab. If the Story list is blank, click the New button to create a new story which will contain a few levels.

-B

Edited by Benson Shaw
Link to comment
  • 0

@Deiter

Looks OK. I’m not quite understanding everything. If you have time, please add some notes.

1.A.

•Do your ideas require both Levels and Level Types?

•If yes, what are the separate functions of Levels and Types?

1B. (comparing and expanding my earlier musings)

•I think we do not need Types. We only need Levels, but they need unique names.

•Level “names” could have a text field and a z value field. eg Ceiling:3000mm.

•In any dialog box where the Level Name is displayed, user can edit the text and numeric fields to change the Level identifier and z value. The TEXT:z value will update in other dialogs and worksheets where it appears.

2.

•You suggest that a Level (Type) has a z value, but that the z can be adjusted separately in each Story.

•Current vwx Levels are same z in each story. This is one of the reasons for the Stories system - Change a level’s z value and that level updates to the new z in all Stories.

•Your idea could work if every Level has a “base” z value which is same in all Stories and an optional offset value which can amend the z in any single Story without affecting that Level in other Stories.

•But I would rather have a new level for the new value. I can ignore the new one in Stories where it does not apply.

3.

• You suggest that the name of a Design Layer bound to a Level will automatically receive a suffix indicating the Story “where” it is associated.

•Are there problems if the layer is duplicated or unbound? (probably not)

• Do these bound layers have properties which conflict with unbound layers? (probably not)

• Otherwise, Good! +1

4.

• You suggest that one or more Design Layers can be bound to any Level.

• Yes! +1

• Is this a likely example?:

Ceiling Level might need a DL for suspended ceiling and lighting components and another DL for fire detection and suppression equipment.

• Down side of this is that a drawing may end up with lots of DLs in every story. This would multiply the number of DLs in a multi story project. Not a huge problem.

-B

Edited by Benson Shaw
Link to comment
  • 0
@Kizza

Correct. Levels are a feature of the Story/Level/Layer "system".

-B

Thanks, not the answer I wanted though.

What if I don't want/need to use the storey feature?

Another half-baked feature from Nemetschek.

This is how it should work:

levels can be bound to layers (for most situations including alts and adds)

layers can be bound to storeys (for those requiring multi storey project management)

Why can't levels work program wide? Who on earth is making these decisions?

Link to comment
  • 0
Hi All,

I will and DO take responsibility for the tutorial - that was all me. If I wrote something inappropriate or incorrect, please let me know.

Wes

Wes,

Firstly, thanks for the tutorial on a complex subject!

Secondly, I don't think you said anything inappropriate.

Rather I should have used some kind of emoticon or used my Irony font when I said "we are all doomed". I was using your quote to help illustrate what has been said here: Storeys are needlessly complex, and have not been well road tested to date.

I think you're to be commended on attempting to make less complex the Storey Story.

Link to comment
  • 0
1.A.

•Do your ideas require both Levels and Level Types?

•If yes, what are the separate functions of Levels and Types?

No and Yes. To the user, you only have level types, like ceiling, top finish, etc... But actually, you have those level types, and for each story you have levels, which are one of those level types, but as the user always sees all level types that can be chosen, and a level is only created when activate it for that story, the user never experiences the difference. I think it's important that they are called level types, as a level type can be activated for each story and the bounding now works like level type [story/story above/story below], which gives a better understanding of where you do bound at. So it is a type, but the actual level in a certain story can be at any z-height.

1B. (comparing and expanding my earlier musings)

•I think we do not need Types. We only need Levels, but they need unique names.

•Level “names” could have a text field and a z value field. eg Ceiling:3000mm.

•In any dialog box where the Level Name is displayed, user can edit the text and numeric fields to change the Level identifier and z value. The TEXT:z value will update in other dialogs and worksheets where it appears.

This will only work if levels aren't bound to a particular story. You are actually making it more complex for the user. It's far easier in bounding to levels when you know it's the ceiling level type you bound to and of which story, hence the current bounding 'Ceiling [story above]' etc... The height will be set for each type differently in each story. Ok, it's more abstract, but less complex though.

IF levels weren't part of stories, than this would work very well, as you than have a system of levels, and nothing more, you can create a level with a unique name and z-value and you can bound to it. That would be very easy and simple, but due to the restrictions of VW, this will not happen. We draw the 2D plan first, not the 3D, that's why they restrict us to bounding only to levels at the story above or below. (And that's fine for me, only restricting for the further development of VW...) BUT it will be harder to set IFC data as VW still have to know at which story each object is....

2.

•You suggest that a Level (Type) has a z value, but that the z can be adjusted separately in each Story.

•Current vwx Levels are same z in each story. This is one of the reasons for the Stories system - Change a level’s z value and that level updates to the new z in all Stories.

•Your idea could work if every Level has a “base” z value which is same in all Stories and an optional offset value which can amend the z in any single Story without affecting that Level in other Stories.

•But I would rather have a new level for the new value. I can ignore the new one in Stories where it does not apply.

- A level type can have a z-value, which will act as the default. When you active a level type in a story, you can set the z-value of it for that story. Not each ceiling is at the same height for each story.

- Well, that decision is plain WRONG! Why would each ceiling (or any level type) be at the same height on each story?! Because of this you will get ceilingAt200, ceilingAt250, ... while you could just use one level type ceiling. This is very crazy now! I wonder why they did this.

- Why do you need to have a z-base-height that's the same for each story, I really don't get that. Even though a ceiling might be at the same height for each story, that's not the point of a level type.

- Why would you want this? A level type is just a name to identify the kind of level, and than you can just say that it's at a certain z height in a certain story, it can't be simpler. I have a ceiling level type, and I want to declare that in certain stories on different heights.

3.

• You suggest that the name of a Design Layer bound to a Level will automatically receive a suffix indicating the Story “where” it is associated.

•Are there problems if the layer is duplicated or unbound? (probably not)

• Do these bound layers have properties which conflict with unbound layers? (probably not)

• Otherwise, Good! +1

- Yes, then you will see much faster at which story a layer is situated. The prefix/suffix now is just to create the layer, it doesn't update after the creation on any changes now.

- No, as we wont be able to change that prefix ourselves, we can just give the layer a name, the prefix will be shown automatically based on the story it is bound to, or not.

- Why? The system is almost now as I propose, I just want it to be more clear and automatic.

4.

• You suggest that one or more Design Layers can be bound to any Level.

• Yes! +1

• Is this a likely example?:

Ceiling Level might need a DL for suspended ceiling and lighting components and another DL for fire detection and suppression equipment.

• Down side of this is that a drawing may end up with lots of DLs in every story. This would multiply the number of DLs in a multi story project. Not a huge problem.

- Yes, a layer should be able to bound to a level as any other object. It's basically saying, this layer should be at that level type of the story it is bound to. This way you can have multiple layers at the same level type, and this is only needed for all the objects that can't be bound to a level type at the moment, because when all objects can be bound to levels, this isn't needed anymore. So it's for backwards compatibility.

- Totally

- You can't see it that way, but you can say: I want a DL for a suspended ceiling and lighting components, and I want a DL for the fire detection and suppression equipment, both have to be at the ceiling level. DL are just containers you can use to draw and as long as there are objects that can't be bound to levels, you have to be able to say that the DL would be at that level instead.

- Not true, as the level binding isn't required for a DL! A DL should be able to be in a story, but the bounding to a level type in that story should be optional (it's just for setting the height of the DL, keep in mind that the ultimate future is that every object can be set to a level type). So you just create the DLs you need, nothing more, nothing less.

  • Like 1
Link to comment
  • 0

"

- A level type can have a z-value, which will act as the default. When you active a level type in a story, you can set the z-value of it for that story. Not each ceiling is at the same height for each story.

- Well, that decision is plain WRONG! Why would each ceiling (or any level type) be at the same height on each story?! Because of this you will get ceilingAt200, ceilingAt250, ... while you could just use one level type ceiling. This is very crazy now! I wonder why they did this.

"

I think it is important to have Levels bound to Stories in general.

In 99,9% the ceiling is at the same level in all stories.

Standard :

There is the need is to be able to change those Ceiling Level at one time

by changing the parent level type, and all ceilings on all Stories will follow.

So it is kind of a Master Story with Master Levels.

Special Case :

And then there needs the ability to split that link from Master Level for some

special cases where the ceiling will be different.

And that has to be visualized that the link is broken. f.e. by a color.

With an option to re-link to Master again.

Standards in between Special Cases :

Also all those levels should be able to be parented in hierarchy trees.

F.e. all Ceilings have to stay 50 cm under the Slabs, so they have to be

parented to the Slabs and not hard coded to the Story.

Even there is a special slab that has a different height and is no more linked

to the Master Ceiling Level.

Stories :

There also should be Story Types with a Master Story and a few special Stories

Types that you can link to your Stories and finally Layers.

Usability :

And all that LevelStory setting should be graphically visualized. So just a like

section viewport with all dimensions in distance and height.

(Similar to the components of the Stairs Tool)

And all editable from there. Checkboxes to link/unlink Levels to Master Levels,

input absolut heights or Delta Z, drop Levels into other Levels to parent them,

name Levels, create or delete Levels ...

Ability to view the whole Story/Level Model complete and a detail view of the

Master Story/Levels or Special Story.

So all Parts Z heights will be linked to Levels.

All Layers will be linked to Stories.

This way you can work some kind of 2D, copy all Parts between Stories

and it will automatically adjust Z-heights according to Levels.

Link to comment
  • 0

Wow, Dieter - Many thanks for the detailed discussion!

Many users may prefer the current process that the z for any level is same in every story so that editing the level(type) z moves that level by same amount in every story. Ceilings at several story z would require several levels. This is great for projects with many stories. Probably doesn't matter much for 2 or 3 stories.

Your suggestion for user defined z of a level in different stories may also appeal to many users. It is very flexible and not difficult to manage in projects with only a few stories. But individually managing the z of every level in every story of a project with many stories could be a problem if global change is desired. That's why I suggest base value (moves up or down with z of level type) plus option for offset in any story - adjust the base z and they all move by that amount. Offsets remain relative to the base value.

The levels I envision function as combo Level+Type. Create a level and it becomes available in every story, similar to a Type. In my suggested Create/Edit dialog a level becomes available in all or selected stories. Enable a level or not in any story via the checkmark. This keeps the functionality of the Types (an instance in every Story) but removes the user from differentiating between level and level type, and removes the confusion of whether/when to create a level or a type (user can currently create a level without a type).

Layers. yes, We want the same thing. User may bind as many layers as desired to any level. These “Story Layers” z values adjust if the binding level z is adjusted, and they have special names because VWX automatically adds a Story identifier suffix to the layer name.

Not sure if this is a good idea, but we could wish that a layer created by the Story system is automatically duplicated/populated in every story and automatically bound to the appropriate level in every story. Sort of a Layer Type?

Anyway thanks again for detailing all your good ideas.

-B

Link to comment
  • 0

Your suggestion for user defined z of a level in different stories may also appeal to many users. It is very flexible and not difficult to manage in projects with only a few stories. But individually managing the z of every level in every story of a project with many stories could be a problem if global change is desired. That's why I suggest base value (moves up or down with z of level type) plus option for offset in any story - adjust the base z and they all move by that amount. Offsets remain relative to the base value.

Not needed if they let us select the levels of different stories in a list and edit them together.

Link to comment
  • 0
(user can currently create a level without a type)

??? Is this true? I guess I have to play with it more, or I'm just seeing/feeling it differently. Because that would mean that level types currently are for having some kind of level in each story at the same height, and the normal level is for all those additional levels you make for certain stories that are at different heights, I will investigate this further....

Link to comment
  • 0
Guest Wes Gardner

So now that we've flogged the Story story to death, how about the non-story story or "The Or Not Scenario or the No Story story"

To create a completely blank file devoid of all default Level Types do this:

Scrub Level Types

Organization Palette > Stories > Default Story Layers > pick ‘em, Delete ‘em

Organization Palette > Design Layers > Level Types > pick ‘em, Delete ‘em

3-Layer Set-Up

• Slab-xx

• Floor-xx

• Ceiling-xx

Set up begins with naming the layer(s) and then determining its “extents” by inputting values for the top and bottom of the layer. Elevation represents the bottom of the layer and as the Edit Design Layer dialog suggests, the layer is relative to the ground plane. The Ground Plane or the “zero elevation point” in this case will be set at the top of the sub-floor of the first floor for residential projects and the top-of-slab of the first floor for commercial work. Layer Wall Height represents where the top of the layer will be – think of it as our old friend “Delta Z.” Consequently, Layer Wall Height will be the height that all components within a wall will be shown at, unless there is an offset placed on a component.

You can build a wall style that uses "Layer Elevation" and "Layer wall Height" and that uses offsets to control the components within.

Link to comment
  • 0
(user can currently create a level without a type)

??? Is this true? I guess I have to play with it more, or I'm just seeing/feeling it differently. Because that would mean that level types currently are for having some kind of level in each story at the same height, and the normal level is for all those additional levels you make for certain stories that are at different heights, I will investigate this further....

I really don't see this. You Always have to have a level type, though the level doesn't have to be a default level. I think there is a misunderstanding because of translations?

What I see in the NL version is that you level types, which a level Always haves. Besides this you have levels and default levels?

Link to comment
  • 0
I tested and managed to create a level with no type. I could bind objects to it and edit the level z and the objects followed as expected. Strange thing though, I could not delete this level. I will try again and post. Later, though, things are kinda busy right now.

-B

Aha! there's a bug in VW, which will remove the level type of a level if you remove it through layer organisation >> level types. But when editing the level, you will not be able to leave the dialog without setting a level type, so it is intended for levels to Always have a level type?

Link to comment
  • 0

A long thread! I have just upgraded from 2010 to 2015 and the story at first appeared as an attraction. Now that I am actually starting using it and reading this thread it appears far to complex.

I have a simple question [i can't find it in a search so forgive me if this has already been covered]. I am setting up a drawing template and would like to organise the drawing set up correctly as a template for future projects. Now I have set up sheets and layers and I have now moved onto stories. Bur when setting up stories it automatically creates a new layer. Now I have spent time setting up these layers based on floor levels.

Surely one can assign a storey level to a design level and visa versa? And then it automatically changes when the level of either changes?

Link to comment
  • 0
Guest Wes Gardner

@ Dieter - the intent is to ALWAYS have a level with a type. (in fact, in my version, I don't have the option to NOT have a type) For example, you can have as many "Ceiling" levels as you want (all with different elevations). You'll then be able to choose which one is appropriate when you create your stories. You can also create levels "on the fly" that will be associated with JUST THAT ONE STORY...

@ Michael - you CAN create a story with NO layers...I'm not sure why you'd want to do so...

Levels can have layers associated with them or not. If the elevation of the story is changed, you have the option of changing the elevation of the stories above, below, all or not at all. The layers within the story will move accordingly.

Don't forget, you can also elect to NOT use stories or levels at all - you'll just need to build your wall styles accordingly. This is outlined in the Levels, Layers and Stories Tutorial

Edited by Wes Gardner
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...