stories 2012

[taoist]

Christiaan,

Yes, we can have negative values

A you say a storey is level that people can use

Maybe as crawl spaces are not storeys, we can assign the crawl space (Foundation) to the ground floor (1st floor) storey by using levels from footing to ceiling

See attached files.

taoist

Edited October 30, 2011 by taoist

[Christiaan]

That's good but why not just include your Footings layer as part of the Ground Floor storey?

[taoist]

Christiaan,

Because we need to draw the footings separate from the foundation walls separate from the 1st floor floors and walls, so I do not think of the footings and foundation as part of the ground (first floor).

I have ground floor set at 0" (Ground Level)

Top of Footing -6"

Top of Foundation Wall 32"

Top of Floor 42" (2x10 joists and 3/4" sheathing)

Top of Finished Floor 42-3/4" (hardwood floors)

Bottom of Ceiling / Top of Wall 12'-6" above ground floor 0" + 42" to top of floor + 9' ceiling height

taoist

Edited October 30, 2011 by taoist

[Christiaan]

Like this.

[taoist]

Here is what I have so far.

Do we need to add walls as a level / layer?

taoist

[Christiaan]

I would have expected to the see the foundation and footings as negative values and either Floor-1 or Floor-FF1 as 0.

[taoist]

So this is what you are after?

taoist

[Christiaan]

And either Floor-1 or Floor-FF1 as 0.

[taoist]

Here is updated Storey for a Crawl Space Foundation

Top of floor system is 0"

Finished floor (hardwood) is 3/4"

Ceiling is 108"

Top of Sill plate is -10" (1-1/2") thick

Top of Foundation (Crawl Space) wall is -11-1/2"

Top of Footing is -49-1/2"

taoist

Edited October 30, 2011 by taoist

[Christiaan]

Yeah, that's what I'd expect to see.

[taoist]

So are you feeling better now about stories?

taoist

[Christiaan]

Hehe, nah, because I found a situation that doesn't work with the negative values for foundations.

Say you a situation where half of the area under your ground floor is basement and half is normal foundations. In this situation you can't define the elevation of your ground level foundations with negative values because VW won't let you overlap with the basement Storey.

In this case you have to add the ground level foundations to the basement storey.

[VincentCuclair]

That's good but why not just include your Footings layer as part of the Ground Floor storey?

Why not just call the Foundation, Foundation and the First Storey, Storey 1?

Say you a situation where half of the area under your ground floor is basement and half is normal foundations. In this situation you can't define the elevation of your ground level foundations with negative values because VW won't let you overlap with the basement Storey.

You can add foundation, footing DLs etc. in your Basement storey to incorporate all foundation objects on that level.........

Edited October 30, 2011 by Vincent C

[Jonathan Pickup]

remember to keep it as simple as you can, especially if you want to use fit walls to roof

[bc]

Given the use of Storeys, Isn't Fit Walls to Roof obsolete?

I would think one could set things up using stories or the layer system as in 2011 but if you do use stories, I would think the walls on the story below the roof could be bound to that and therefore fit to it appropriately. Not so?

Haven't tried it yet but I am hoping this "Stories"

is not just another half realized feature.

Edited October 31, 2011 by bc

[Christiaan]

It doesn't work. If you try that it simply bounds to the Elevation height of your roof layer. It's not aware of the roof geometry.

[Christiaan]

Why not just call the Foundation, Foundation and the First Storey, Storey 1?

Because Storey has a known definition and it doesn't include foundations, so it's counter intuitive to have to add a foundation under a feature that VW calls a Storey (or Story).

It's little details like this that make the program harder to learn. Any competent technician or architect who comes to VW afresh will have to first unlearn what they know a Storey is. Guess I'd be more comfortable if they had a broader term such as Levels.

You might argue I'm splitting hairs but these sorts of things add up.

[Dieter @ DWorks]

The storeys as they are now are just a grouping of layers. There is nothing other to it.

The only benefit of having them is when you edit a height, the others go with it. All other things could be done before too.

Edited October 31, 2011 by DWorks

[Jershaun]

I agree with DWorks. NemV should have just made editing the levels in the Layer dialog affect other Layers and made objects in vw more intelligent (eg. a door and window should have a ceiling representation instead of playing with classes for a ceiling drawing, a slab should be able to be drawn on the same layer but be intelligent enough to understand it should be at the back of all other objects, etc, etc.). What they're done with this Stories thing is created a whole lot of confusion. This thread is proof of that.

Students are the future. Imagine a student now have to set aside some time in their busy schedule to learn software. I've worked with vw since minicad 7 (1997) and I think Revit has a simpler approach to setting up a model, now imagine what students are thinking. This is why Revit is becoming so huge. A student has to choose between a complicated vw or straight out of the box simple Revit. They're choosing Revit. It has very little setup issues. The whole of Australia is adopting Revit and it's becoming the standard if not already.

[Christiaan]

The storeys as they are now are just a grouping of layers. There is nothing other to it.

Agreed, and they're limited in that they can't overlap each other.

All I'm saying is that Storeys probably wasn't the best name. Storey has a specific architectural definition and VW Storeys don't particularly adhere to it, based on the above examples. Levels probably would have been better name.

[Stan Rostas]

Christiaan,

Stories can overlap based upon the elevation settings. The real reason for stories has to do with the new associative data fields for walls, stairs, etc. allowing them to move in concert with a change in the overall story setting. All the sub layers of the story are set in relation to the story setting. Yes, you could do all this with to old method but you would have to adjust each and everyone, this speeds things up a bit. The settings to the wall could also be set to adjust accordingly but the new story feature gives you finer grain control.

Could this have been better, yes, we would have preferred that this was all done directly and interactively with a modeling window Graphic control rather than the dialog settings.

Depending on how much a user actually models to generate the 2d representations of elevations, building sections and wall sections this new feature will have varying levels of usefulness.

Regards,

Stan

[Dieter @ DWorks]

Stan, try building two different houses in one file with each of them having other elevations.

Or try to draw an appartment building where you have x number of floors that need to be the same and make the model....

Can't be done anymore, so stories just remove features from vw instead of adding.

The 'extra' work you had before stories to alter the heights and elevations of design layers is nothing compared to the trouble we have now.

[Christiaan]

The example I was talking about where I couldn't overlap was where I was trying to give the foundations for my ground storey a negative elevation value, but it wouldn't let me do this because it said I couldn't overlap with the basement storey.

[Robert Anderson]

Dieter, it seems to me that you are using more and more extreme (outlier) examples to support your position. For multiple buildings, best practice (now as before) is to have separate building files and consolidate them on site using referenced DLVPs. Multiple identical layers can also use DLVPs, just as before. Nothing has been taken away.

[Dieter @ DWorks]

Dieter, it seems to me that you are using more and more extreme (outlier) examples to support your position. For multiple buildings, best practice (now as before) is to have separate building files and consolidate them on site using referenced DLVPs. Multiple identical layers can also use DLVPs, just as before. Nothing has been taken away.

I know we can use dlvp, but there isn't anough control over the class attributes in slvp for the inner dlvp that comes from other files. And this is really needed. When the classes are the same, why not being able to set them through the slvp?

The examples I give are much used around here and are working really fine, but with the new stories, we wont be able to do this anymore, unless we don't adapt those stories.

How a drawing looks is also really important to us. So the flexibility to override classes in viewports is a really good thing. We need that same flexibility for dlvp through slvp. Changing every class in each file or having to need multiple viewports for just the same thing is just not workable, it's time consuming and asks a lot of organisation.

Example: Imagine you have building A in drawing A, and reference this in drawing B on the dtm. Now you want to make presentation plans: floor plans and elevations and 3D's.

How to do this?

* Reference each design layer with a floor plan from drawing A to drawing B. Here you can make your floor plans from.

* You won't be able to make elevations from these referenced dlvp because you can't turn off the classes that needs to be turned off for elevations, while they need to be turned on for floor plans.

* So to be able to create elevations, you will have to make dlvp again, but this time setting other class visibilities.

* Now if you want to be able to present your plans in different color schemes, you'll need to duplicate it all and again do a lot of settings.

* You'll end up with so many viewports and references that it's not controllable anymore.

I think you can imagine that doing this for a couple of buildings require a lot of work, not to mention that a particular bug that doesn't update classes with long names for referenced dlvp require you to redo the whole thing. And don't forget that not all classes are set in dlvp! this will cause you to alter the class settings everytime you have a new object in a class that wasn't used untill then, even while that class exists from the very beginning. This is so stupid, just let us set the class overrides of referenced dlvp, even if there are no objects in them, so we don't forget it later.

that's out....

Sorry for the rant, but it just frustrates me that we got less control and more work with the new releases. The intentions are good, but the result is not. It's just not worked out enough. Still hoping though...