Stories

[Dieter @ DWorks]

DWorks, we did consider embedding Story-levels at wall components, but frankly we felt the complexity of this would be overwhelming for most users and would provide little additional benefit. Would you mind providing an example of a wall condition you cannot do with the current system of Stories, wall-height bounding and wall/slab interactions?

Well, that would be almost all situations we draw. The problem is the following:

* Walls doesn't always join right.

* Because of this, you can't have slabs to be attached to walls.

* Because of this, your walls will not be cut where the slabs sits.

* Because of this, we need to use the extra offset of the components to create the cutout effect.

* Because of this, we have a LOT of extra work when the slab components changes in height.

* Because of this, storeys doesn't have any additional benefit from what we can achieve with design layers.

* Another thing is that when it does go right, we still can't have a floor piece where the windows or doors cut out the wall. So we still need to have the slabs be manually editable and not bound to walls.

* Because of this and other reasons, we can't use those automatic bounding of slabs.

* Because of this, we need to use the extra offset of components

* ...

Another problem is that you can't just define elevations without a layer. For a storey, we don't draw ceilings, but we want to be able to set the ceiling elevation so that objects can bound to that elevation. So for getting the most of the storeys and the object bound to them, you'll have to have several layers you will not use, except for its bounding. This fills up the layer list and makes it harder to use, especially when working on 10+ level buildings. This just slows you down.

A solution to this could be that the layer list would also contain the storeys, and that the layers in those stories are subitems that you can hide or show like in a tree view.

A solution for having elevations to bound to withouth the unneeded layer can be that we just can set an elevation, and that you have an option to have a layer to that elevation.

A solution for getting away the extra work when changing slab components is letting wall components bound to key elevations of the story. That's something so logical I'm suprised it isn't there. You can't expect that all automatic things will always work and that there needs to be other ways to achief things when this happens. And let us just be honest, What do you do the most: changing the free height of a story, or changing the slab components?

Edited September 15, 2011 by DWorks

[Robert Anderson]

DWorks, that's quite a list of problems! FWIW, we did do quite a bit of work on wall joining. But I'd like to see some concrete examples, if you don't mind. Would you email me a problem file that shows what you are trying to achieve but can't? There may be an easier / more straightforward approach than what you are using...

[Dieter @ DWorks]

DWorks, that's quite a list of problems! FWIW, we did do quite a bit of work on wall joining. But I'd like to see some concrete examples, if you don't mind. Would you email me a problem file that shows what you are trying to achieve but can't? There may be an easier / more straightforward approach than what you are using...

Well, I will try to use the system like it is meant to be in this 2012 version, and every time I cannot do something in relation to the walls, floors and storeys, I will post them here, because there are still many problems with walls in 2011.

[Bart Rammeloo]

(...) every time I cannot do something in relation to the walls, floors and storeys, I will post them here, because there are still many problems with walls in 2011.

Please do - and keep it up. NVW can only try to solve a problem when they are aware of its existence. That's not a guarantee that it will be solved quickly (a problem might have hooks all the way into the core of the software), but if you don't give them real examples, the problems will never go away.

Edited September 16, 2011 by BaRa

[Dieter @ DWorks]

Here is the first wall join that can't be made. And you know the story, if walls aren't connected well, no floor can be bounded, and the walls will not be cut, so bad section, ....

Even in v2012!

So basically, the whole automatic thing in v2012 tumbles down in this drawing and result in a HUGE amount of extra work. Just because it's decided that those wall components offsets would be too confusing????

Edited September 19, 2011 by DWorks

[Robert Anderson]

Dieter, you're bringing 4 walls together at this intersection. Which two of the walls form the boundary that you would use to bound the slab?

[Robert Anderson]

Dieter, by the way, Y-joins have improved in Vectorworks 2102 such that I can join the wall containing the door to this junction. 4-wall joins are still a challenge!

(See image)

[VincentCuclair]

DWorks, we did consider embedding Story-levels at wall components, but frankly we felt the complexity of this would be overwhelming for most users and would provide little additional benefit.

Just having the option is always a benefit Robert (it is one of VWs strengths imho), just make sure the default is logical for new users that aren't aware/willing to use this function.

A strength would be that the existing wall/slab types wouldn't need to be changed when used in different combinations with each other or even in combination with certain new wall/slab types.

[Dieter @ DWorks]

Dieter, by the way, Y-joins have improved in Vectorworks 2102 such that I can join the wall containing the door to this junction. 4-wall joins are still a challenge!

(See image)

I know it's a challenge, but in the real world, this happens all the time. We have lot's of joins where 4 walls come together. And it's not acceptable how it looks now, so we need to manually draw them with workarounds, which is not the big problem here. The big problem is that the whole system VW is going to falls down when some of the chains don't work! Like I said:

If you can't connect the walls => you can't bound the floors to the walls => you can't automatically cut out the floors from the walls => Your section doesn't look correct => your worksheet will not be correct => You can't use the new system of floors related to storeys => ....

And because of the new system with storeys, VW gives you MUCH more work when such things happens than what we have in vw2011. That's also the reason why I was really dissapointed in this. It's good as long as everything works, but once one piece falls apart, the whole building collapses. That's why we need more control of those wall components. If only we could bound them too. I can't believe it's that much more work. I'm a programmer myself, so I know what I'm talking about. It's just a matter of calculation the right values here.

I hope my point is clearer now because I have a fealing that it's not comming out clear.

[Dieter @ DWorks]

DWorks, we did consider embedding Story-levels at wall components, but frankly we felt the complexity of this would be overwhelming for most users and would provide little additional benefit.

Just having the option is always a benefit Robert (it is one of VWs strengths imho), just make sure the default is logical for new users that aren't aware/willing to use this function.

A strength would be that the existing wall/slab types wouldn't need to be changed when used in different combinations with each other or even in combination with certain new wall/slab types.

That's what I'm saying all this time. It can't be that hard! We need this option, because VW now thinks that everything will always work, and that's not the case!

[Dieter @ DWorks]

Some other news: The Y wall joins may be better, there is one deal breaker that forces us to use the old method of using 2 T joins instead of an L and T join! That's the line we don't want in hidden line renders! See attached image. As long as this isn't fixes, the better Y joins can't be used.

[Dieter @ DWorks]

Dieter, you're bringing 4 walls together at this intersection. Which two of the walls form the boundary that you would use to bound the slab?

I have 3 floors, the rooms are upper left, upper right, lower left. The lower right is outside. So I need to bound to all walls.

[Dieter @ DWorks]

Wall component also needs to be able to move backward and forward. If you set all attributes to class, you get this for example: See attached image.

If you set the line to none, as a 'solution', then you will miss some lines at wall caps or joins.

Oh, and the wall lines of the components in 3D doesn't take over the attributes of their class, even if you set them by class. Another basic thing!

Edited September 19, 2011 by DWorks

[Chris D]

Chris, with the 2012 release we did not give Stories any special navigation capabilities. What would you like to see in this area? (I think this kind of feature has potential, but exactly what the feature would do is not so obvious to me.)

Well, at the moment we draw with several layers per storey (fabric, furniture, fire, ceiling), and would continue to do so in 2012. Now the trouble with navigation is that say I've got a layer and class combo on screen for one storey, and would like to flick up to the storey above...it's all a bit manual...turn 3 layers off, 3 layers on etc. With storeys there could potentially be an easier way...as long as my layers are associated with storeys then it's a simple scripting excercise to make a tool that could switch storeys with the same layer/class combo, isn't it?

Haven't had any free time over the last few days to delve into this, so correct me if this functionality is there.

[VincentCuclair]

Chris, a reasonable solution is to save different class visibilities by using 'save view'.

However a more usable function has been wished for:

http://techboard.vectorworks.net/ubbthreads.php?ubb=showflat&Main=31348&Number=154102#Post154102

Edited September 20, 2011 by Vincent C

[Dieter @ DWorks]

I created another thread for posting all wall joins that doesn't work in VW:

http://techboard.vectorworks.net/ubbthreads.php?ubb=showflat&Number=160421Post160421

[Chris D]

Chris, a reasonable solution is to save different class visibilities by using 'save view'.

However a more usable function has been wished for:

http://techboard.vectorworks.net/ubbthreads.php?ubb=showflat&Main=31348&Number=154102#Post154102

Saving views is the same old 'manual' solution. I'm usually doing something very specific like comparing the ceiling grid to the fire layer...but I wouldn't set up saved views for every scenario like that.

Keeping the same zoom/class/(sub)layer settings whilst moving between storeys should be more intelligent. Imagine you're clash detecting a particular area...you've zoomed, got your classes on/off, the relevant layers on/off, but you want to check all storeys...I just wanna flick up and down storeys on a keystroke or at least on a palette.

With regard to the link to your wishlist, I support this for the future. Less abstraction, more building intelligence:

"Computer. Show me the ceiling grid on the third floor at 100 scale!"

[Guest]

Please do - and keep it up. NVW can only try to solve a problem when they are aware of its existence.

Thats funny they created the problem by ignoring structural element detailing in X-section V/Ps...Furthermore you two guys (Belgium) are the only ones complaining about Block/Brick Work high rise...Unless you are in some third world work economy where Labours cheap (2c a brick)...the world uses PRECAST-CONCRETE for high rise not brickwork nor timber framing....Heres a tip "get some real structural engineers involved earlier on".HTH

[Jonathan Pickup]

DWorks, we did consider embedding Story-levels at wall components, but frankly we felt the complexity of this would be overwhelming for most users and would provide little additional benefit.

Walls an slabs will interact with each other to control top and bottom bounding of the wall components, provided that you use Auto-Bounded slabs.

[Dieter @ DWorks]

DWorks, we did consider embedding Story-levels at wall components, but frankly we felt the complexity of this would be overwhelming for most users and would provide little additional benefit.

Walls an slabs will interact with each other to control top and bottom bounding of the wall components, provided that you use Auto-Bounded slabs.

LOL, That's just the problem, you can't use auto-bounded slabs when you can't join the walls properly!

That's what I mean by saying that VW relies too much on such thing. When one thing falls apart for a reason, all tumbles down. VW need more things to catch these problems. So bounding wall components would be the answer in this case.

[Christiaan]

So bounding wall components would be the answer in this case

Which, no doubt, we won't see until at least v2013...

Perhaps NV need to widen their beta testing program.

[VincentCuclair]

2 things that have become clear within a week of release:

1. Reference elevations/planes on stories shouldn't automatically be connected to Layers.

2. Component bounding to reference elevations/planes is needed.

....basically this could have been solved with better Beta testing, these are not bugs they are basic user issues.

Has been pointed out before:

http://techboard.vectorworks.net/ubbthreads.php?ubb=showflat&Main=29807&Number=147451#Post147424

(Mind, stories and reference elevations/planes are essential if we want to have functional and flexible PIOs in the future.)

[Dieter @ DWorks]

2 things that have become clear within a week of release:

1. Reference elevations/planes on stories shouldn't automatically be connected to Layers.

2. Component bounding to reference elevations/planes is needed.

....basically this could have been solved with better Beta testing, these are not bugs they are basic user issues.

(Mind, stories and reference elevations/planes are essential if we want to have functional and flexible PIOs in the future.)

Finally, someone also noticed this. And because of this, this release is only a v2011.5 because there nothing really new in it. I'm still dissepointed with this release, although I'm very happe that all new 2011 tools finally work like they should be.