Stories v. Non-Stories (Residential Design)

[Ryan Russell]

All,

 

I'm currently working within the Architectural Template (2023), and I have encountered a stumbling block.

Everything has been fine thus far, until I try to resize my walls. It seems they are tied to constraints.

 

What is best practice or industry standard?

Am I be better suited to rebuilding the model in a non-story bound environment?

 

Also, if using "Stories" is the ideal way to proceed, what is the proper setup for multiple ceiling heights in Story-1?

How best to treat ceiling heights that span into Story-2?

 

Confused, trying, learning! Hoping to never ask the same question twice! Grateful for this community and its support.

 

- Ryan Russell

(p.s. - If I need to post images or VW file, just let me know.)

 

[line-weight]

Probably best to post a file and explain specifically what you want to do and why.

 

The tops and bottoms of walls can be bound to story levels, plus or minus an offset. Or they can be unbound. The usefulness of stories depends on quite a few things including how many floors the building has and how likely you are to want to change things like floor-floor heights in the future.

 

There is seldom a clear "best practice" with Vectorworks... this is one of its strengths and one of its weaknesses and I can understand must be immensely frustrating when you are new to it.

[shorter]

Out of the box, the template and default content provided by Vectorworks expects certain conditions in the model.  They are trying to be helpful by giving you content that to some extent 'works' out of the box.

 

However, very few projects are 'out of the box' so you are recommended to develop your own content to suit how you delivery your architecture and stop letting software dictate how you design, which it so often does.

 

The discussions surround layer elevation and wall height versus storeys will surface again I fear, but I will say this.  Sometimes you use storeys, sometimes you don't.  There are no rules nor industry standards governing how you use software; only protocols to define how you name things.

 

Some will erroneously state you need storeys to deliver IFC.

 

Some will say you have to bind layers to storey levels.

 

These are all 'out of the box' mandates that should be ignored.

[E|FA]

When I was transitioning from 2D to 3D workflows, I built test projects with Stories and without Stories.  I decided to use a No Story workflow because it seemed easier to manage, dealt with split levels better, and seems more suited to the single family projects that are the bulk of my work.  

 

This post by was very useful:

 

 

[shorter]

We use a mixture depending on the file and the project.

 

A simple assignment of storey to a layer is good for minute adjustment of levels across the model, without using a plethora of storey levels, i.e. letting the storey define simply the FFL of each floor.

 

In reality once floor levels are set, they don't vary much and if you are dealing with large scale rwsidential, there are only a few different floor to floors we use whcih are dependant on brick dims.  The ground floor level though often needs adjustment and this of course changes the entire model.  You can avoid this though by going back to the old drawing board approach of modelling at 0m, but issue drawings stating that Ground Floor FFL = 0m = 35m AOD, etc, so if the ground floor FFL changes, the model remains where it is.  You simply adjust the reference elevation and coordinate this with your consultants.

 

The inability to change all storey levels in all storeys, though, is an absolute pain on larger projects and more time consuming that adjusting layer elevation!

 

Creating a content library that simply sets walls to anticipate layer elevation and layer wall height is a very quick and reliable solution and avoids the issue @Ryan Russell mentions, I think, where the OOTB walls are looking for specific storey levels, particularly inside components and if they don't exist cause the wall to remain 2D, and this causes much confusion (we have had lots of supprt queries related to this one despite us saying 'don't use the OOTB content!').

Edited March 16, 2023 by shorter

[shorter]

Further to the storey levels comment...  Just tested in 2023 and one would 'logically' expect any storey level set by 'default storey level' to be editable when changing the 'default storey levels', or is that too obvious?

 

I have a 10 storey template model.

 

I have storeys.

 

I have storey levels set by our default ISO19650 compliant UK Residential project template, which annoyingly we still cannot import from another file... grrrrr

 

The storeys are for FFL, SSL, etc.

 

I want to change the SSL level for each floor.

 

The steps should be...

 

1 Select all storeys.

2 Click 'Default Storey Levels'

3 Edit Default Storey Level, e.g. SSL

4 VW edits the SSL level in all storeys selected.

Edited March 16, 2023 by shorter

[line-weight]

1 hour ago, shorter said:

Further to the storey levels comment...  Just tested in 2023 and one would 'logically' expect any storey level set by 'default storey level' to be editable when changing the 'default storey levels', or is that too obvious?

 

I have a 10 storey template model.

 

I have storeys.

 

I have storey levels set by our default ISO19650 compliant UK Residential project template, which annoyingly we still cannot import from another file... grrrrr

 

The storeys are for FFL, SSL, etc.

 

I want to change the SSL level for each floor.

 

The steps should be...

 

1 Select all storeys.

2 Click 'Default Storey Levels'

3 Edit Default Storey Level, e.g. SSL

4 VW edits the SSL level in all storeys selected.

 

Storeys is one of the areas where the terminology that the VW designers have chosen makes everything ultra-confusing.

 

I have to go back and read my own notes each time I deal with storeys.

 

What I want there to be is an absolutely clear distinction between:

- Storeys

- Storey level types (a level type, for example FFL) that might occur in any storey

- Storey level type instances (an individual instance of a level type, for example 2nd floor FFL)

 

I want to know exactly what I am editing or creating at any point, and the current UI and terminology makes this very confusing. For example, "default storey levels" are really default storey level types. I think. When I am editing a "storey level" I am actually editing a storey level instance. I think.

 

I think you're right, there's not a way to edit the elevation of all storey levels of a particular type, together, to be a set value relative to the story. "Default storey levels" are just a set of storey level names that VW gives you. Part of my routine is to delete them all, when I am setting up a new file.

 

I don't generally work on buildings with large numbers repeated storeys so I kind of dodge all this by just having one storey for the whole building, and then having a bunch of storey levels within it, so I might have several FFLs within that .

 

Reading all this is probably going to stress the OP @Ryan Russellout. Sorry @Ryan Russell.

Edited March 16, 2023 by line-weight

[shorter]

8 minutes ago, line-weight said:

Part of my routine is to delete them all, when I am setting up a new file.

 

Me too.

 

9 minutes ago, line-weight said:

What I want there to be is an absolutely clear distinction between:

- Storeys

- Storey level types (a level type, for example FFL) that might occur in any storey

- Storey level type instances (an individual instance of a level type, for example 2nd floor FFL)

 

Exactly.  There are 'omipotent' levels that are always the same on all repeating floors (Vectorworks, show me a building type where this is routinely NOT the case) and instances, where we need to edit a bespoke level.

[shorter]

All this is showing it that out of the box, software rarely works as we need it and some thought and preparation of content and having a strategy matters more.

 

Sadly we find this is rarely the case and users end up confused by what 'should work' but doesn't because they have used content out of the box.

 

In their defence, Vectorworks engineers cannot possibly know what we need.

 

We have just spent over 300 hours building 500 objects for a client because the out of the box content, along with content from other sources like BIM Object and the NBS BIM Library, does not do what they need, and more importantly is not ISO19650 or COBie compliant.

Edited March 16, 2023 by shorter

[line-weight]

2 minutes ago, shorter said:

In their defence, Vectorworks engineers cannot possibly know what we need.

 

The thing is, I'm pretty sure all these confusing aspects of storey levels have been raised before, several versions of VW ago, but no moves seem to have been made to address them and make the whole thing more user friendly.

 

I find this really frustrating where something could be made a bit less confusing simply by changing the terminology at least as a starting point. That doesn't need any change to the hard coding, it just needs a change to what things are called (or how they are presented) in the UI.

[line-weight]

11 minutes ago, shorter said:

 

Exactly.  There are 'omipotent' levels that are always the same on all repeating floors (Vectorworks, show me a building type where this is routinely NOT the case) and instances, where we need to edit a bespoke level.

 

And this could potentially be dealt with using an existing concept in VW: styles.

 

I could have a "FFL style" where the elevation relative to storey, name and prefix are all set by style

I could have a "window sill level style" where the name and prefix are set by style but the elevation relative to storey is set per instance (ie it's different in each storey)

And I could have unstyled levels that don't have anything set by style, so they have only one instance and everything is editable in it.

[shorter]

Styles are not ideal tbh because they often conflict when referencing.

 

A simple tick-box 'Make Default' in the 'New Storey' dialog, when creating a storey and associating the storey levels, would be sufficient.

 

 

[E|FA]

I understand the utility of Stories for dealing with multistory buildings.  For single family residential in our area, we are mostly working with a basement +2.  We also often have split levels, double height spaces or lowered floor areas.  I find that the management/confusion level of dealing with VW Stories offsets any potential gains, and controlling everything off Layer elevations and heights is relatively simple and quick to update if floor to floor heights change.  If the VW Story interface is simplified (or if I work on larger buildings) I'll take another look.

 

@Ryan Russell You might get better "best practice" (everyone has their own) guidance if you post the types of projects you work on. 

[Benson Shaw]

10 hours ago, line-weight said:

I find this really frustrating where something could be made a bit less confusing simply by changing the terminology at least as a starting point. That doesn't need any change to the hard coding, it just needs a change to what things are called (or how they are presented) in the UI.

Agree! Some terminology adjustment could really help in Stories.  The names are not always descriptive or well defined in introductory material - level vs default level(?), design layer vs story layer(?).  The Ledge???  Some of this sorts out with repeated use, but makes learning more difficult.

 

There is precedent for name change, although I'm not sure confusion was reduced:

The vwx site model has a robust name history - Digital Terrain Model, DTM, Terrain, Site Model. Descriptors also include TIN and Mesh.

The site model "sides" have also changed name, at least once - Hull to Skirt.

Some of the name changes are not system wide. Several popup notices and commands still use the older names. eg:

      DTM is an easily identifiable acronym oft used on the forum. Most can understand the meaning.

      Site Model creation starts by opening the Terrain menu choice.

 

My $.02

 

-B

[Ryan Russell]

All,

 

I figured out how to modify the height without breaking everything that has been completed so far.

 

Select the wall you wish to increase > click on the "Components..." button in the Object Info palette, and select Top, then "Edit..." button.

Change the 'Component Top' radio button from 'Relative to story --> Relative to wall.

 

And this will change the wall height(s) while maintaining story data.