Story Vs Layer Height

[Dieter @ DWorks]

What's missing is a graphical link between project levels (which propagate in all views) and the Storey's feature.

Another thing that's missing is the ability to define levels without having a design layer for it. Plus I don't get the thing where you only can bound an object to the own story or the story above/below. They do this only for the reason that in VW, we draw for example a wall in pieces, each piece on it's story/layer. That's also why stories can't overlap. This is very bad. Just let us define levels for stories as we want, even if they overlap, it will be better understandable and flexible. Then let us bound each object to each of these levels, even if that means that they doesn't show up on some levels though they are going through it, this can be solved in a later version. The whole story system is made unnecessary complicated because of NVW is scared that it's users won't get it otherwise and because of backwards compatibility. Just make it work simple and good and just make sure that old drawings aren't broke in what's in there already, backwards compatibility doesn't mean that we must need to draw like we did before, just don't brake the existing objects, but once the user want's to edit them, let them be only editable in the new way. I'm really getting scared for the future of VW if they keep adding badly integrated stuff onto the heap of bits and pieces. VW needs to be redefined in what it is and take all the bits and pieces, resort them and build it again with a solid base.

[Kizza]

Another thing that's missing is the ability to define levels without having a design layer for it.

Yes, the ability to define multiple levels, even if it has to be within a design layer, is what is needed. And the ability to hide/show each level as not all levels need to be shown on the drawings.

It is the lack of graphical levels that makes the storeys feature so abstract IMO.

The potential is there but it needs to be implemented...fast.

P.S.

Maybe make the storey levels the key project levels and have the ability to add additional design levels with the DL, with the ability to hide/show them?

Edited March 14, 2013 by Kizza

[VincentCuclair]

I don't really know how they propose to make this simpler, basically the issue is not with DLs/Storys, its in the PIOs, they need the capability of being shown/hidden on more than one DL in Top/Plan view (e.g. we need to be able to choose on which DLs we want a certain wall to show instead of needing to chop them up into several vertical pieces and placing them on these respective DLs)........but for this to work properly you need rigid, predefined elevations that don't overlap to do it.....thus the introduction of Storys.

Edited March 14, 2013 by Vincent C

[Dieter @ DWorks]

but for this to work properly you need rigid, predefined elevations that don't overlap to do it.....thus the introduction of Storys.

Why can't they overlap? There is no problem with stories overlapping each other. We now can't overlap them because someone decided we can only bound to the level types one story above or below. But if they decide we can bound to any level type of any story, then they just can overlap. Of course, what you then will get with the current implementation of VW, is that when you bound your wall two stories above, it won't show up at some layers, and I think this is the reason behind the chosen solution now. This should be easily corrected with the implementation of the auto-hybrid feature into symbols and pios: place your symbol/pio with this feature enabled (users can choose to enable it), and let it appear on all layers that go through it. I think this will be the simplest solution for VW as for other solutions, the whole layers system needs to be redone. Also, with this implementation, we should also be able to just define any level type on any story without the need of design layers attached to them. It would be so much simpler.

Edited March 14, 2013 by DWorks

[VincentCuclair]

Why can't they overlap? There is no problem with stories overlapping each other. We now can't overlap them because someone decided we can only bound to the level types one story above or below.

I don't think it is that simple,

1/ if you have a stair that runs between Story 1 and 2 overlaps in these Storys will make automatic stair generation pretty complicated if not impossible for the program,

2/ the new automatic adjustment of the whole model if one Story height is changed, recalculating and adjusting other Storys would be pretty complicated if not possible.

3/ Automatic elevation marker generation (once it arrives) would be pretty complicated if not possible.

4/ Volume and Material take-off calculations would be pretty complicated if not possible.

etc. etc.

In all these cases how is the program to know where to calculate to if Storys overlap, the top of Story 1 or the bottom of Story 2 or somewhere in between?

Why not just continue using offsets in PIOs and introduce multi Story/Layer visual controls in them, just like in ArchiCAD and Revit (there is a reason why overlapping isn't possible in these apps either, however they have solved it through their PIOs)?!

In ArchiCAD/Revit if you need a wall that spans 3 Storys you draw one wall with the correct height bounding and it automatically shows on all these Layers, if you want to change its appearance on some of these Layers you can......so it is quite uninteresting in this regard that Storys can't overlap in ArchiCAD/Revit.

Edited March 14, 2013 by Vincent C

[Dieter @ DWorks]

1/ if you have a stair that runs between Story 1 and 2 overlaps in these Storys will make automatic stair generation pretty complicated if not impossible for the program

Why? The stair is being calculated just by its begin and end elevation height, so if we just can define level types and bound to any of them with the stair, all else can stay the same for the stair object.

2/ the new automatic adjustment of the whole model if one Story height is changed, recalculating and adjusting other Storys would be pretty complicated if not possible.

This can also stay the same like we have now: When changing a level, you would be able to choose to move up/down the levels above/below with it. A story is just a z-height, so it will be the same.

3/ Automatic elevation marker generation would be pretty complicated if not possible.

Do we have automatic elevation marker generation in VW? I have not seen it. And if it would have this, then it's just showing the levels, wich would not be a problem as you can define levels as you want. I really don't see the problem.

Why not just continue using offsets in PIOs and introduce multi Story/Layer visual controls in them, just like in ArchiCAD and Revit (there is a reason why overlapping isn't possible in these apps either, however they have solved it through their PIOs)?!

That's what I'm saying. Let us bound objects to any level type of any story. In Revit, you also just set levels how you want it. The stories there are separate from these levels.

[VincentCuclair]

I'm starting to get the idea you don't really understand Storys Dieter?!

The whole idea with Storys is exactly what you want when you say Elevations, the only problem is we can't show PIOs on several DLs at the same time......ie Storys is fine but DLs in combination with PIOs need to be better.....

In the stair example you're still stuck in the old way of doing it and VWs is in the middle of the old way and the new(correct) way, we shouldn't even have to consider upper and lower bounds when we place a stair (at the moment we still do partly) the default setting should be from the bottom of Story 1 to the bottom of Story 2 with the option of offsetting. Again it is a question of setting up your project templates correctly I have standard DLs connected to Storys and my Stair has a default to bound to from DL Floor 1 to DL Floor 2, this is almost the same as in ArchiCAD/Revit.

[VincentCuclair]

1/ if you have a stair that runs between Story 1 and 2 overlaps in these Storys will make automatic stair generation pretty complicated if not impossible for the program

Why? The stair is being calculated just by its begin and end elevation height, so if we just can define level types and bound to any of them with the stair, all else can stay the same for the stair object.

Yes, but they need to be manually set in the stair dialog, but we want automatization it should be a default setting.

2/ the new automatic adjustment of the whole model if one Story height is changed, recalculating and adjusting other Storys would be pretty complicated if not possible.

This can also stay the same like we have now: When changing a level, you would be able to choose to move up/down the levels above/below with it. A story is just a z-height, so it will be the same.

True, but it becomes much more complicated when you have Split levels etc. and it is already complicated

3/ Automatic elevation marker generation would be pretty complicated if not possible.

Do we have automatic elevation marker generation in VW? I have not seen it. And if it would have this, then it's just showing the levels, wich would not be a problem as you can define levels as you want. I really don't see the problem.

It will be introduced soon i think...... you define the levels through Storys and when these overlap you have a part of the model that is not defined or defined double exactly what I mean.....

Why not just continue using offsets in PIOs and introduce multi Story/Layer visual controls in them, just like in ArchiCAD and Revit (there is a reason why overlapping isn't possible in these apps either, however they have solved it through their PIOs)?!

That's what I'm saying. Let us bound objects to any level type of any story. In Revit, you also just set levels how you want it. The stories there are separate from these levels.

Well you could see Levels in Revit as DLs in VWs however you do setup the model with Storys as we do in VWs, but they can't overlap.... they use horizontal sections in hidden line instead of Top/Plan views, but then again it is not possible to create several alternatives in the same file, that I find, is a big advantage in the VWs Story-DL setup, the same for ArchiCAD.

Basically we need more powerful Top/Plan-PIO integration, with better default settings

Edited March 14, 2013 by Vincent C

[VincentCuclair]

We shouldn't forget that Revit and ArchiCAD are building modelers while VWs is a jack of all trades, Storys is only there for the benefit of us doing buildings.......

[Kizza]

but then again it is not possible to create several alternatives in the same file, that I find, is a big advantage in the VWs Story-DL setup

This fact keeps me in the VW camp, although this is partially addressed through Phases in Revit

[Dieter @ DWorks]

I'm starting to get the idea you don't really understand Storys Dieter?!

Stories are only there/needed for IFC and the 'old way' you describe so that you can only bound to levels of the story above/below. We actually don't need stories, it's the levels we need to set. Look at a file where you set up your stories and levels. Where actually do you use your stories? Right, nowhere, it's the levels you use. Look at your file and remove the stories, but keep all the levels. You will see that you can achieve the same, and more, with just setting these levels. And these levels is all we need.

Apart from this, I agree that setting levels in stories is more logical and better for the mind, but stories are just some sort of grouping of levels. There is no reason why a certain level of a story can't go beyond it's bounds (overlap others). True that for this, the pios should be able to bound to every possible level, and that's where the problem lies at the moment. We don't need design layers bounded to a level type. Let us set up design layers bound to a story, so the objects on that layer know which story they are on (for IFC). I think the whole system is made too complicated to the end user to use properly in most cases. I have situations where I have level types named 'Roof below' or 'Ceiling below' because they belong to the story below, but due to the level limitations, I have to put them to the story above.

we shouldn't even have to consider upper and lower bounds when we place a stair ... the default setting should be from the bottom of Story 1 to the bottom of Story 2 with the option of offsetting.

Here you contradict yourself. The bottom of story 1 is a lower bound for the stair and is just a level or z-height or whatever you call it. So in essence, you only need to be able to bound to levels and being able to offset from them. If your stair goes from floor 1 to floor 3 (levels), that should be possible. Off course we should need some system to tell the stair that it must appear on the design layers we want it to appear, but that doesn't have anything to do with the stories/levels, although it should be easier if it was.

[VincentCuclair]

I'm starting to get the idea you don't really understand Storys Dieter?!

I have situations where I have level types named 'Roof below' or 'Ceiling below' because they belong to the story below, but due to the level limitations, I have to put them to the story above.

I consider this mainly a limitation in the objects, this would be solved if you could set the objects to show on 2 DLs with different representations.....

we shouldn't even have to consider upper and lower bounds when we place a stair ... the default setting should be from the bottom of Story 1 to the bottom of Story 2 with the option of offsetting.

Off course we should need some system to tell the stair that it must appear on the design layers we want it to appear, but that doesn't have anything to do with the stories/levels, although it should be easier if it was.

True, I was referring to how it is now, there are 4 ways (Wall Height, Layer Height, DLs and manual input) of defining Top and Bottom bounds not one logical way, this is confusing for novices.......and requires a clear and thought out workflow which you only get after years of using VWs....

I think we mean the same thing here Dieter...... :grin:

Edited March 14, 2013 by Vincent C

[Guest Wes Gardner]

Here's my thoughts...for ease of explanation, I tell folks that Stories are a container for Layers. What we know is that a story is really nothing more than a plane in space...how's that

[mike m oz]

DWorks, yes you can do it all with Levels (i.e. Design Layers with specific Z heights) but conceptually you will still have Design Layers associated with each storey in your building.

What Stories does is aggregate the Design Layers associated with a particular storey in the building and shows their Z heights relative to that storey's elevation (Z height). That makes it easier to set the height for different elements such as ceilings and the like.

The power in Stories is the association of Design Layers with specific stories in the building. These associated Design Layers will then automatically change their elevations (Z heights) when changes are made to the Storey structure. Changes like:

- An adjustment of the building datum elevation by a Storey elevation change.

- An increase or reduction of a storey height by a Storey elevation change.

- The addition of a Storey.

- The deletion of a Storey.

How many Design Layers you have associated with each Storey is up to you, and it can be just one.

Not using Stories is an option but you need to be mindful that you will then have to manually manage the Z heights of all of the Design Layers.

[Dieter @ DWorks]

The power in Stories is the association of Design Layers with specific stories in the building. These associated Design Layers will then automatically change their elevations (Z heights) when changes are made to the Storey structure. Changes like:

- An adjustment of the building datum elevation by a Storey elevation change.

- An increase or reduction of a storey height by a Storey elevation change.

- The addition of a Storey.

- The deletion of a Storey.

The thing is that we don't need a design layer for each level and we may not need the association of design layers to levels at all. We do need an association of design layers to a story. An example of how it is now:

- I make 3 stories, floor 1, 2 and 3.

- On each story, I have 3 levels, floor, floor finish and ceiling, each being the top z of the 'slab'.

- I only draw on the design layer that comes with the floor level.

- I bound my walls from ceiling in the story below to ceiling, for external walls.

- ....

- So I never use the other 2 design layers.

This must simply be changed because there is no need to have a design layer attached to levels. The level types are simply an array of strings, so VW really don't need to have those design layers for them. Levels should just be set separately of design layers because a design layer is graphical to put thing on it while the level is a reference for objects to bound to.

I really would like to know why there is a need for a design layer with every level?

[mike m oz]

DWorks the system provided is flexible so users can work the way they want, including your method.

The user decides how the tops of variable height objects are set with the options being:

- A specific value;

- The Design Layer's Layer Wall Height value;

- A specific Design Layer's Elevation (Z height).

Apart from Walls the bottom Z height relative to the Design Layer's Z can also be set, and the tops and bottoms of variable height objects can be varied by offset values.

If there were less options there would almost certainly be users here asking for the 'missing' options.

[Dieter @ DWorks]

I give up.... I use the system to it's fullest and find it ok, but I also think it's not implemented good enough and makes it too complicated for many users and too cumbersome to use easily. It's just my opinion....

[VincentCuclair]

I give up....

:grin: already.....

Like always, we'll keep on nagging 'them' and wishing things and in the end 5 years later it will be implemented anyway, by that time who knows where the competition is? Dieter I think we all want the same thing we're just approaching it from different angles......bottom line is we need Storys but at the same time both DLs and PIOs need to be integrated with them in a much better way, e.g. we should be able to hide DLs that are created only for bounding purposes, we need PIOs to be shown on more than 1 DL at a time etc .etc.

Edited March 14, 2013 by Vincent C

[Dieter @ DWorks]

we should be able to hide DLs that are created only for bounding purposes

No, it's more logical to have the option of creating a DL for a certain level. Why create something that you will hide because you don't want it in the first place?

Sorry, I can't let it go yet...

I do agree that at the core, we do want the same things, but viewing it from a different angle. And I think that angle for me has something to do with being a programmer myself.

[VincentCuclair]

Why create something that you will hide because you don't want it in the first place?

Because of this:

- I make 3 stories, floor 1, 2 and 3.

- On each story, I have 3 levels, floor, floor finish and ceiling, each being the top z of the 'slab'.

- I only draw on the design layer that comes with the floor level.

- I bound my walls from ceiling in the story below to ceiling, for external walls.

- ....

- So I never use the other 2 design layers.

[VincentCuclair]

So let me try to understand how you propose they solve this Dieter:

Your saying that we should have Storys and in these Storys we should be able to define certain reference-levels to bound to right? But where do we draw and place objects?

[Dieter @ DWorks]

So let me try to understand how you propose they solve this Dieter:

Your saying that we should have Storys and in these Storys we should be able to define certain reference-levels to bound to right? But where do we draw and place objects?

We draw and place objects on design layers of course, like we always did. And for VW to know on which story an object is placed, we only have to tell to which story the layer belongs to. And for compatibility with older workflows and for users that doesn't use levels much, we can set the z-height of the layer in relation to the story, so that also objects that aren't bound to a story level will get placed at a certain z-height in the model.

In short:

- DL basically stay the same as before the stories, for when you don't use stories.

- Stories can be made with a certain base height (z-height)

- Levels can be made inside these stories (with a z-height)

- DL will have a parameter to set a story it is in. This will result in making it's z-height relative to the story, so that it moves with it.

- Objects placed on a DL:

---- will now know on which story they are.

---- can be 'bound' like before to the layer z-height and height.

---- can be bound to one of the levels defined.

---- will move with the stories/levels/DL

Extra:

- DL can have an extra parameter for the cut height. This will be the height objects are being cut like walls. This will be needed when we bound a wall to a level of story 0 up to a level of story 10 for example. VW can then look up all DL that have set to be in one of the stories in between 0 and 10 and draw that wall there and cut it at the cut height of the DL.

This would make the whole story system easier to understand and to work with. And I also think easier to program. And as you can see, all that is now possible, will stay possible, so this shows that the current system is made too complicated and has unnecessary pieces.

Edited March 15, 2013 by DWorks