Jump to content
  • 1

What is wrong with those story levels?!

Dieter @ DWorks


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

  • 1

what is lacking is a graphical representation of the levels created within a storey to be visible in all sectional and elevational views.

i.e. 3D reference levels/lines

I've used the storeys feature - it's way to abstract IMO in it's current form and construct. back to using just plain old layers.

Maybe a feature enabling you to be able to link layers together (think layer linking in photoshop) is all we need?

Link to comment
  • 1

I'm sure we need Levels and Stories.

And you can set as many Levels as you want.

Your way with connected Layers will work if you change your Story heights.

But it will not work when you want to change f.e. all bottoms of your Windows,

Handrails, etc. from 90 cm to 100 cm for the higher Stories.

You would have to change them manually one by one (or groups of it).

Agreed, the capabilities of Levels and Stories are needed. Objects often need adjustment en masse, often over several stories, or throughout an entire building.

Lots of solutions for the window sill alignment are possible within this suggested scheme. It depends on adding binding functionality to standard vwx layers, and enhanced binding features to objects. Here are a few ideas:

•Create windows on layer Story1 which is bound to layer above and layer below. Windows are bound at sills to layer Story1 z + offset. Other stories have similar window binding heights. Select similar or select all windows in the building or on a layer(s) or in a class(es) and change the binding offsets for sill of the selection. Or if the window header height is the important parameter, bind the window headers to layer above with a negative offset.

•Engineer some new kinds of resources, eg Window styles and Door styles - resources with top/bot binding & offset parameters and datum points. Edit the style to adjust the binding layer and binding offset values.

•Place the windows in a new WindowSill layer and bind windows or rails to it (similar to adding a non default level or Zoomer's sub levels). To change the window positions, adjust the WindowSill layer z or change the binding offsets.

-Or other ways not yet imagined.

The first two ideas allow height adjustment for every window in the building in one action. Changes to z or h of any layer or layers will not dislocate the consistent window sill offsets.

3rd idea only changes window positions on one layer at a time.

What I have described is a vague wish for Story capabilities through enhancements to existing vwx layers and objects: layer binding and more robust object binding options. It is a wish for an alternate development path to the Story system because that system (my opinion) is too cumbersome.

Meanwhile I will try to get better at using the existing system.


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


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.



Edited by Benson Shaw
Link to comment
  • 0
- 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?

+1 Thanks for confirming this Dieter. I should be able to easily convert elements of a drawing started without the Stories structure into the Stories structure. Binding an existing Non Story layer into the Story system seems a reasonable request.

So please revision this so that it just works and is user friendly!


Apparently the Stories/Levels/Layers has advantage in automatically assigning ifc data, and in the ability to move or change Story positions and heights while tracking data as Stories above or below change position to accommodate. Are there other advantages?

For me, those advantages are offset by the rule loaded process that is based on nested dialogs, is difficult to learn and remember, and is nearly impossible to troubleshoot.

OK, exaggerated a bit, and focused on my own limitations.

Stories/Levels/Layers gets in the way of realizing my vision, rather than helping me along the way. Others on this forum note that the entire functionality of the Story system can be accomplished through management of Vectorworks "regular" layer & class structure, but without the tedious complexity of the Story system.


Link to comment
  • 0





- 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?

I did this.

i think it was in the stories tab where you could select your layers and their settings

plus checkboxes which levels will be assigned.

Link to comment
  • 0
  • Vectorworks, Inc Employee

Adding this thread to the appropriate cases now.

Any other feedback on the Story/Level system and it's needed improvements are welcome below. Even if its just links to other already existing writeups of possible changes. Specific scenarios and use cases where its causing pain are sought after as well.

Link to comment
  • 0

Thinking in a different direction:

Do we really need the Story? and the Default Levels?

Layers are often assigned same function as story - ie has z value and a height and stuff assigned to it. Stories are kind of special layers. Maybe we don't need special ones. The ability to move everything above/below if Z or Height changes could be accomplished by binding layers to each other or to levels. Unbound layers work as we know them - containers!

Could levels be assigned to the usual Vectorworks layers? Or do they even need to be layer specific? If associated with a layer, Level elevation designation could be Layer Elev +/_ some amount. Binding layers to levels could be same process. Why bother with the Defaults. If I need a level for binding, let me create it name it and assign it to a particular layer.

Dieter wrote good ideas in 2013. Only he kept stories and dissociated levels and layers.


The Default Levels and special (not default levels) and the process of adding new or deleting unneeded so that only the relevant ones show up in every layer seems arcane. How ‘bout a Create Level tool or command. Dialog asks for the height and maybe presents a list of items bound to it. Level aware items have the OIP options for binding.

Sorry, not a fully developed concept, but just thinking about why the existing system is not working for me.


Link to comment
  • 0
How ‘bout a Create Level tool or command. Dialog asks for the height and maybe presents a list of items bound to it. Level aware items have the OIP options for binding.


Or even more simpler - layer binding with option to display layer as a level (i.e. reference level graphically displayed in all elevational and sectional views)

Link to comment
  • 0
Hi All,

Please read attached...


Thx for that, but to be honest, if the system really needs such a long help file, then it's way too complicated. this should be simple for users to use. I really don't know why they are making it so complicated. The way I see it:

- Design layers are just containers to draw, nothing less, nothing more. There is no reason to bind a level type to it, unless you want objects that can't be bound to a level type at that z height, though this can be solved by making sure each objects can be bound to a level type....

- Design layers can be 'bound' to a story, so that the objects in it know to which story they belong, but that's just saying to the layer that it belong to that story and setting a specified z offset relative to that story.

- Level types, which belong to a story should not be bound to design layers. No reason for this. We just want to use them to have objects be bound to them so that they are at the correct z height and overall height etc...

It seems to me that VW is tying too much together. This can also be seen with wall styles. Wall styles should be just defining what kind of wall it is with which wall components in which class etc... There are settings that should be based on the wall instance, like the offset of the components. For example the wall on the ground level can have an offset due to the connection with the foundation, but the levels above will have not... But that's for a different wish list item....

Edited by Dieter @ DWorks
Link to comment
  • 0

I may not understand all what you posted. (lost in translation)

I want to add just a few points.

Stories and Levels are important.

Giving a Layer simply a Z height works for simpler buildings only !

Just ignore stories and levels, you can work this way just before, if you like.

Stories and Levels by fake Layers in 2014 was terrible !

Having a Story model and assigning Stories to Layers is great !

Especially if you have more than one Layer assigned to a story. Just change

the Story height to change all those Layer heights PLUS (!) all Layer heights of

the stories above. (Or not if you wish)

Levels are great also !

You can assign many elements heights to those levels and change them at once.

And you can assign heights of Levels of Stories above and below !

For the next VW Release :

Of course Default Levels, when changed, must change all bound Levels on all Stories.

As long as they are check boxed to Default Levels and not overwritten manually !

Of course those Level heights have to be used by ALL (!) elements, like Windows,

Doors, Stairs and even things like simple Extrudes, Generic Solids etc.

And yes, the current Wall System by Wall Styles is a pain !

There have to be 2 "Styles" for Walls.

A Wall Style

(Components/Classes/Graphic Attributes)


a Wall Height Style

(Height Level assignment, maybe per Component 1-2, 3, 4-7, 8, ...)

Maybe even extracting the Wall (Components) Thickness from Wall Style to a

Wall Thickness Style.

Link to comment
  • 0
  • Vectorworks, Inc Employee

Hi All,

Yes, getting your head around this is a bit confusing...what I like about the system is that you can (and should) use the Level-bound method for creating wall styles AS WELL AS the Edge-offset method and the Offset method, all within the same model.

The material provided is intended to be a step-by-step tutorial covering setting up levels, layers and stories as well as creating a wall style from scratch and does involve several steps.

You can still build a perfectly acceptable model WITHOUT levels ans stories, just use Wall Height (it equates to the old Delta Z). You can then place offsets on your components and off you go.

The new system ++MAY++ reduce the number of wall styles required...

Link to comment
  • 0

Totally agree.

The new system ++MAY++ reduce the number of wall styles required...

I see the problem with wall styles pretty independent from Stories and Levels.

If you work on existing (older) buildings,

You will have many of similar styles just for the widths of the same wall type.

F.e. simple concrete single walls in 12, 15, 18, 25, ... cm thickness,

the same happens for different wall materials like masonry, ...

Plus some Walls with more than one components.

And at the end there will multiply the styles by copies of it because of different

heights. F.e. because of varying slab thicknesses or you need the same wall

just as a handrail etc.

For me it would be much easier to save 5 wall types + 5 wall widths + 5 wall heigts

instead of, in the worst case, 5x5x5 = 125 wall styles.

Also it would be much easier if a wall would run in height automatically just to the

next slab or a max value.

(F.e. the Wall core runs until the slab, the outer component runs further until the

max height of f.e. the next Story)

Link to comment
  • 0


I looked into it, could it be that "Bottom of Structure" etc. is just a hard coded

Height defined by a level ?

I thought you mean that there is a flexible vertical position value that depends

on f.e. slabs and would work still if the slabs change in thickness.

I mean it is nice to have that Level, as it will control all related Walls.

But nothing that will save from duplicate Wall Styles.

Link to comment
  • 0
  • Vectorworks, Inc Employee

If you bind to "Bottom of Structure", that can be something different at grade where maybe it's just a slab with a thickness of 4" (sorry about the crazy feet/inch thing - we almost made it to the metric system but it was much too logical) as opposed to an elevated slab/floor system where "Bottom of Structure" is 24". One wall style could accommodate this.

Link to comment
  • 0

Yes, getting your head around this is a bit confusing...

I spend more time setting up/editing the storey structure than I would if I ignored it and simply just created the layers.

Give the layer three attributes:

1) the ability to be displayed as a level in elevations and sections (think elevation benchmark). For example, adjust the height of the elevation benchmark in a section and the layer's height is automatically adjusted to match.

2) Link one layer to another, similar to how Photoshop handles layer linking. Move one layer up or down and the other moves with it.

3) Ability to bind all objects to layers, including top and bottom offsets

Then you don't need the storey feature.

Side note:

I had a quick look at how Revit handles storeys. Revit doesn't.

You create a plan view, say 01 Ground Floor. The 01 Ground Floor plan view has no 3D height assigned to it until you create a level and link/bind the level to the ground floor plan. Levels can be bound together by locking them and objects are hosted to the view they are created in. So no storey feature in Revit, the so-called software of choice for those working on large multi-storey projects.

It's simple and easy to grasp.

I was going to say that we have been requesting, for many versions now, 3D levels that propogate in all elevation and sectional views, but I won't :)



Edited by Kizza
Link to comment
  • 0

Kizza has it right.

This could all be done via layers and object binding with offsets. No need for stories or levels. Main feature change needed is option to bind layers to each other - top to layer above, bottom to layer below.

If layers could be bound to each other, then:

•Alter the z or the h of a layer, and all the bound layers above or below will adjust their z.

•Kizza's graphic controller/indicator object with z value text field and Show/Hide feature for each bound layer would be very helpful in any view. Click to show them all. Drag one (or several) up or down to adjust the model, and watch all the z data adjust in the markers. Click to Hide them all. Open the layer edit dialog to see the new values there, too. Or adjust in the layer edit dialog and see the values change in the marker objects.

•Binding an object to a layer and stipulating an offset will preserve its position relative to the layer z or h. Object binding to layers uses the existing options for top bind and bottom bind, both with offset values. Objects, eg walls or columns could span several layers eg BOW to layer 1, TOW to layer.

•No need for a suspended ceiling level (or any other level). Bind a ceiling to a layer z (preserves ceiling height if layer h is adjusted) or to the layer h (preserves suspension space is layer h is adjusted)

•Object binding could be developed further with user defined datum points, similar to slab datum point. Multiple points for an object might be useful, eg walls that span several layers - maybe a separate datum for peak of a gable wall bound to the top (h) of roof layer . . .

A drawing would not need a huge number of layers. Probably just one per "story" because object top/bot offsets take care of intermediate "levels".

OK enough from me.


Link to comment
  • 0

No need for stories or levels.


Architects need the ability to graphically represent levels. Not in the dumb way VW does now with static elevation benchmarks. We need intelligent 3D levels visible in elevation and sectional views. All the big boys have this capability. Levels in VW can be a graphical attribute of the layer, because the layer itself is capable of being assigned a Z height. Could be as simple as a checkbox - tick it and the layer will create an elevation benchmark in all elevation and sectional views automatically, which can be grabbed and moved interactively in these views by the user. When moved, the layer's Z height adjusts automatically.

•Kizza's graphic controller/indicator object with z value text field and Show/Hide feature for each bound layer would be very helpful in any view.


As shown in the pic in my previous post, Revit links levels together by a simple dimension. Dimensions in Revit can be locked. If VW could automatically generate elevation benchmarks as described above, we could use the existing constraint distance tool to lock the benchmarks, thereby locking the layers.

Link to comment
  • 0

Please leave stories. Revit does have them, but it's not really visible to the user though.

And the levels in VW are actually like Revit, the difference is that Revit does it graphically and VW through dialogs.

My main point and frustration on stories and levels is that it's too restrictive, though that's solved in v2015, but side things like defaults etc... still make it restrictive! They just need to clean it up and it's ok. For example, when you edit the z height of a default level, VW creates a new one, so you end up with two levels???? Defaults should not be about z heights, as that can differ on many occasions, it should just be about the name and basic settings. In general defaults are just for getting initial data when you create things.

I'll try to add real use cases in the next couple of days to show what I mean.

Edited by Dieter @ DWorks
Link to comment
  • 0

I did not understand all what you wrote Wes,

but that's just my translation problem :)


the meaning of Stories and Levels is that you can adjust them in one place,

and all Objects that have these level bindings wich be updated at one time.

I'm sure we need Levels and Stories.

And you can set as many Levels as you want.

Your way with connected Layers will work if you change your Story heights.

But it will not work when you want to change f.e. all bottoms of your Windows,

Handrails, etc. from 90 cm to 100 cm for the higher Stories.

You would have to change them manually one by one (or groups of it).

I have a new idea :

There should be kind of Sub Levels that are not locked to story Z but to

the Z of other levels.

So if you always want to end your windows 30 cm under the ceiling, it would

be better to bind that window top level to the ceiling level.

This way the windows will automatically adjust if you need to change the ceiling

height. Without the need to hard copy the 30 cm distance into any element.

There may be better examples but I think you can get the idea :)

I see still problems with walls not automatically bind to elements but levels only.

F.e. the split level thing or just varying slab thicknesses according to their Structural

needs in different areas of a story. Where you either have to set new Layers for

each area or split your walls (styles) everytime you run over a border.

Link to comment
  • 0

Not being a user of stories I don't really have a vested interest here. My take away from this thread is that VW needs an visual interface designer. Ironically most wishes on this list centre around this. Someone who replaces dialogs with intuitive interface features. Here's a very basic example -

A few versions ago we asked for a way to reorder layers. VW gave us a new numbered column (stacking order) to drag them around. It works but it adds yet another thing to clutter up the navigation palette. What we really wanted was to just drag them by the names like in Photoshop and other software where the numbered column may exist but its hidden away under the hood.

I'm not sure how we word this broad wish in a specific way so Jim can enter it into the database. Ultimately we spend too much time looking under the hood in VW....


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.

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...