Jump to content
  • 1
Sign in to follow this  
Dieter @ DWorks

What is wrong with those story levels?!

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!

Share this post


Link to post

Recommended Posts

  • 1

This What’s Wrong with Story/Level/Layer question really bothers me.

I want this to be another great feature of Vectorworks.

It needs further work, refinement, simplification, deconstruction, unparseing.

Please challenge or improve my analysis and ideas offered below.

I believe our community board can influence future development of Stories.

Discussion:

Stories,Levels,Layers is fantastic functionality and it actually works. What’s wrong is the unnecessary complexity for the user. It’s inelegant.

Levels are imaginary planes for binding level aware objects. Every level has a name and a z value relative to the story. Current implementation includes:

A. Default Levels - these are “default” because they automatically appear in the level list of every story in the drawing. Vectorworks provides a few “built in” Default levels (Top of Structure, Ceiling, etc). These can be used, edited, ignored or deleted. New Default levels can be created by the user. But why have default and non default levels? No good reason is offered while complexity builds.

B. “Regular” levels (my name) can be created by the user - these are only available in the Story where they are created. User can create as many of these as desired in any Story. But strangely, only the z values can be edited, not the level names. These levels cannot be deleted. ??? Why not just offer one variety of Level?

C. Level Types - These are not actually levels, but rather a way to refer to one or several Levels with same name (but different z) appearing in the list of available levels for a Story. For instance, the Default level list could contain Ceiling (z=8’) and Ceiling (z=9’). The Level Type is Ceiling. Both Ceiling levels would appear in the list of available levels for every Story, but only one of these Ceiling levels could be enabled in any Story. Note: User can still access multiple “ceiling” levels by creating additional levels with slightly different name eg CeilingA or Ceiling_8’2”, etc. In my opinion, Level Type is an unnecessary construct. It defies the Vectorworks conventions related to naming conflicts. It could be eliminated by requiring normal vwx naming practices for all Levels.

D. There is a separate creation dialog and a separate Edit dialog for each of these three things.

General wish:

Stories/Levels should be structured similar to Sheet Layer Viewports/Classes. Eg every Class is available to every Viewport. User can enable any or all classes in any Viewport. No need for Default Classes, Class Types, or deeply nested dialogs to enable classes in the VP.

Implementation wishes:

1. Make all Levels function as Default Levels and just call them Levels. Abandon the “default” concept for Levels. It’s not a problem for every level to be available in every story. User opts to not enable the unneeded ones. This eliminates some dialogs and vaguely defined terminology. eg Vectorworks does not need Default and Non Default classes for Viewports. All classes are the same variety.

2.A Eliminate the Level Type construct and the associated dialogs for Type creation. “Types” is a redundant system - same function really as Default Levels. eg Vectorworks does not need Class Types to manage classes common to several Viewports. See 2B

2B. Instead, require Level names to be unique. eg Ceiling1 or Ceiling_9’2”, etc

3.A Creating new levels should be in one dialog. No need for Level Types or their separate creation/edit dialogs. No need for a special Default Level or related create/edit dialogs.

3.B Story Edit dialog should offer easy to find and easy to manage edits and controls. See example.

-B

ubbthreads.php?ubb=download&Number=12084&filename=Story:Level%20DialogBox.png

Edited by Benson Shaw

Share this post


Link to post
  • 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

Share this post


Link to post
  • 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.

Share this post


Link to post
  • 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).

Share this post


Link to post
  • 0

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

Share this post


Link to post
  • 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

Share this post


Link to post
  • 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.

Share this post


Link to post
  • 0

So I've partially read through Wes' storey guide.

Am I right in concluding that levels are only available within the storey feature i.e. if you don't create a storey then you can't create levels?

Share this post


Link to post
  • 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

Share this post


Link to post
  • 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

Share this post


Link to post
  • 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?

Share this post


Link to post
  • 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.

Share this post


Link to post
  • 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

Share this post


Link to post
  • 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.

Share this post


Link to post
  • 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

Share this post


Link to post
  • 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.

Share this post


Link to post
  • 0

Anyway thanks again for detailing all your good ideas.

no problem. It's by having a discussion around this that this feature can be cleared out for the devs.

Share this post


Link to post
  • 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....

Share this post


Link to post
  • 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

Share this post


Link to post
  • 0

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.

Share this post


Link to post
  • 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?

Share this post


Link to post
  • 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?

Share this post


Link to post
  • 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?

Share this post


Link to post
  • 0

@ 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

Share this post


Link to post

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.

Sign in to follow this  

 

7150 Riverwood Drive, Columbia, Maryland 21046, USA   |   Contact Us:   410-290-5114

 

© 2018 Vectorworks, Inc. All Rights Reserved. Vectorworks, Inc. is part of the Nemetschek Group.

×
×
  • Create New...