stories 2012

[Dieter @ DWorks]

Dieter, it seems to me that you are using more and more extreme (outlier) examples to support your position.

I don't think my examples are extreme. The examples I give are really common here. Customers are really demanding and we need to get good results. Buildings seem to be more complex here then what VW is being created for. The reason I give all my examples is because I need to do all this stuff to get better and faster results. Writing scripts to cover up some of the problems or searching for workarounds aren't always fun and there isn't always time for that. As a programmer myself, I find it strange that some options are left out because it's believed that the automatic stuff will always work. As an example of this: You have a watch that shows you the correct hour. This watch is build so that when the hour changes from summer to winter and back, it will do this automaticly. So the user doesn't need to care. Now for some reason, this automatic thing doesn't work anymore, and the makers of the watch didn't put in the option to change the hour by the user manually. This makes the watch totally useless at that moment. I know it sounds stupid, but that's a thing VW has on some parts. Walls will be cut out by the floors, but only when they are bounded to it, only problem is that they can't be always bounded... So I really think that VW should first get all the options there to manually do things and then automate it. This way, when the automation fails, you can still do it.

Edited November 4, 2011 by DWorks

[Christiaan]

So I really think that VW should first get all the options there to manually do things and then automate it. This way, when the automation fails, you can still do it.

The problem with this is that there's less incentive to get the automation right. One of the reasons automation works better in programs like Revit and ArchiCAD is that their developers have no choice but to get the automation right because they're so reliant on automation.

I rather see some sort of commitment from NV to flesh out newly introduced features between major releases, rather than waiting for the next major release.

[Chris D]

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.

You mean to tell me this isn't fixed yet? I hadn't checked it on my 2012 trial but I'd been merrily telling my colleagues that these issues would go away when we upgrade.

We DLVP our plans into our site file, but we want the plans to look different on the site file so we'd like to override classes...but you can't do this in an SLVP. Very frustrating.

[bcd]

Speaking of controlling class visibility in DLVPs I really wish the visibility tool would turn off unwanted classes here too. It's not always obvious from the class list of even a well built dwg what classes to switch off to clear up a dlvp to make it usable.

[VincentCuclair]

The problem with this is that there's less incentive to get the automation right. One of the reasons automation works better in programs like Revit and ArchiCAD is that their developers have no choice but to get the automation right because they're so reliant on automation.

I rather see some sort of commitment from NV to flesh out newly introduced features between major releases, rather than waiting for the next major release.

I think you're bang on the money there Christiaan!

Let's see:

- First came walls with PIOs like Windows and Doors, but wall joining was rather clunky and windows and doors can't span 2 Layers/Storeys i.e.. be placed in 2 walls on top of each other: fairly basic and common.

- Some time later came associative Slabs, wall joining slightly better, windows and doors still can't be placed in 2 walls.

- Now the stair tool has been slightly improved, slabs still clunky i.e. create a slab based on 4 walls = fine remove one wall and replace with 2 others slab = corrupt, this too is very basic and common. (the space tool has fairly similar problems)

- The roof face tool is still very basic a new associative version is sure to appear soon, why not concentrate on the stuff that doesn't function properly then introduce new problems.......

Edited November 4, 2011 by Vincent C

[gester]

It's a matter of definition, not perspective. Calling the foundation a storey makes the word storey meaningless.

(..)

there's also a term called 'a technical storey', which is designed for the technical/maintenance reasons, not necessarily for the common peoples' usage as we know it. a crawl space in the foundation height is imho such a storey...

rob

[VincentCuclair]

While we're splitting hairs, why are 'they' called Classes instead of Layers like in all the other CAD programs and why are 'they' called Sheet Layers instead of Layouts and Design Layers or Worksheets instead of Models like in most other CAD programs.......

I think for most rookies/starters the concept Storey is easier to grasp than Layers/Levels/Elevation etc in reference to buildings, I think the learning curve is more important than if a foundation, attic, split level or roof is per definition a storey or not.

[gester]

going back to the roots to undermine the whole software design concept won't help either

but we're drifting...

back to the topic:

i'm a heavy archicad user, too. and in the ac v12 we also have troubles with the rigid storey settings (i dunno if the newer versions have improved on this issue, though). the entry storey on the ground level with the retail stores, as i conceived it, with flats on the back side on the 60cm higher level wouldn't work with the lifts. the lifts' doors stuck to the storey level at 0.00, and there was no force to rise them to the required 0.60, as the lift object doesn't have this parametric capability.

and in the end i've wound up changing the main storey level to the 0.60, with all consequences of false wall foundations and heights to be corrected. the same with the lift overhead slab height, which sticks to the roof storey level, and has to be set to the value required by the lift object, not having much in common with the real construction nor finished roof level.

so don't lament and try to find out the best way to proceed. other cad software vendors have their troubles, too.

i still don't have the vw2012, but as i recognize, the best approach could be a combination of both layer and storey ways.

rob

Edited November 4, 2011 by gester

[bc]

Vincent

It's because a Class is an attribute of an object and a layer is a place to put that object. Calling an attribute of an object a "layer" does not make sense to me. Sheet and design layers make perfect sense to me and I am OK with stories now that I know it is simply a group of layers that can't overlap others.

Overall VW nomenclature is a non-issue. Half-baked functionality IS an issue and one that actually boggles the mind. VW would earn a far greater market share if it's functionality were fully realized when it is first released. I would pay more for a better VW.

[VincentCuclair]

Agreed! Hence the splitting hairs, however when I first purchased VWs (having used AutoCAD, Point, ADT, Bentley Architecture, ArchiCAD and now Revit) this nomenclature attributed to much of my initial confusion/misunderstanding in learning VWs. It is of course not an issue any longer.

[VincentCuclair]

Vincent

Half-baked functionality IS an issue and one that actually boggles the mind. VW would earn a far greater market share if it's functionality were fully realized when it is first released.

One wonders for example why when bounding a slab to walls it is a must for the walls to join properly? Why not just make the slab intuitive enough to distinguish bounding wall intersections and get rid of the whole wall joining problem in this respect, this way moving or editing walls shouldn't be a problem + while we're at it why not make it possible to edit the bounding wall list and add or remove bounding walls from a specific slab, why can't we edit a slab even though it is bounded to walls? this limits its usability greatly (what happens when slabs suddenly stop in the middle of a room or adjoining escalators or stairs or elevators, these boundaries don't have walls and why isn't this type of intelligence present for roof faces etc. etc.

Edited November 4, 2011 by Vincent C

[bc]

Indeed, VW is a program full of wonder. It is simply wonderful.

[VincentCuclair]

:grin:

[maarten.]

... why can't we edit a slab even though it is bounded to walls? this limits its usability greatly (what happens when slabs suddenly stop in the middle of a room or adjoining escalators or stairs or elevators, these boundaries don't have walls and why isn't this type of intelligence present for roof faces etc. etc.

Maybe i misunderstood you, but isn't this where that "Virtual Wall"-Wall Style is for? (draw the boundaries of your hole with the "Virtual Wall" (invisible) and connect the slab with this "Virtual Wall")

[Dieter @ DWorks]

... why can't we edit a slab even though it is bounded to walls? this limits its usability greatly (what happens when slabs suddenly stop in the middle of a room or adjoining escalators or stairs or elevators, these boundaries don't have walls and why isn't this type of intelligence present for roof faces etc. etc.

Maybe i misunderstood you, but isn't this where that "Virtual Wall"-Wall Style is for? (draw the boundaries of your hole with the "Virtual Wall" (invisible) and connect the slab with this "Virtual Wall")

The concept of the 'Virtual Wall' is one that Design Express, the localiser for Belgium, has made up. I don't think many others do know this. The problem with the Virtual Wall is that it's created with a script because you simply can't make it by hand. The wall dialog won't let you set a thickness of 0, so we can't use that wall because we can't set the class of it etc... There are also other problems with it in real life buildings, so it's not any good.

Plus the real bad thing here is that even if you draw that virtual wall, it's the wall connections that are the problems in general. Slabs can't be bound because most of the time (90%) the wall connections can not made properly for the slab tool to bound. That's why we need the slabs to cut out the walls always, even if they aren't bound and being able the set each component differently and not with the current add and remove system, because it's no good.

Edited November 7, 2011 by DWorks

[maarten.]

Why do you think DE made the "Virtual Wall"? It was made by NVW, it's located in their default library (they have 3 Virtual Walls btw).

And you can set the class of that wall trough the properties of that wall style.

[Dieter @ DWorks]

Why do you think DE made the "Virtual Wall"? It was made by NVW, it's located in their default library (they have 3 Virtual Walls btw).

And you can set the class of that wall trough the properties of that wall style.

My mistake, the thing is we do not get those in our localized version, unless they are hidden in some way.

I tried it again, and it worked now. I'm pretty sure it didn't worked before. Maybe a corrupt file or something.

But still, it's useless in many situations.

[mikatoa]

I'm 2 months into Revit and I'm liking it alot. Trying to set pre-setup our VW default files like Revit (structure)- realise how many classes are needed to support a storey. A storey with a min. of 4 layers (roof, ceiling, slab, floor, foundation...)

If we are going to start using these ceiling, slabs, roofs tools then these 'smart objects' need to actually know where they are actually placed in the built environment. They should also come with common attributes easily managed on the object and be viewport specific. We should not need layers to locate them or classes to create viewport specific views.

ahhhhhhhggghhhh...

[VincentCuclair]

Well I'm also getting into Revit (couple of months) and I hate it, the UI is terrible, especially visibility control is horrible .... I don't like software dictating how I work.

Every other action you do in Revit prompts a warning which on canceling doesn't seem to lead to any sort of consequence anyway?!

This is my personal opinion, however Revit has taken parametric implementation to the max, (so much so that simple 2D line work is hard to find/implement/understand) so if you like/want a parametric-object-based CAD app get Revit.

Storeys in VWs has made it possible to make better use of PIOs, but this needs to be incorporated much more.

Edited November 9, 2011 by Vincent C

[Luke Gilmer]

I'm a 'newbie', trying to enter data with Stories. I have a basement (8'), main floor (10'), and second floor (9') ... existing house.

How do I adjust heights in the simplest way? I first used the default set up, but couldn't successfully modify wall heights. I then read "Help 2010", and followed it's instruction to edit "Default Story Layers ...". Ouch! Slow and inflexible. Surely not the way to make changes.

I'm sure I'm missing something obvious. It appears that you can not edit heights once a story is created from the Stories page of the Org table. Where do I make height changes? (In Design Layer page of the Org table?)

...Aside: Where are user instruction for features? The 'Help' is way too obscure for a newbie like me, and very light on operation description. This community board is great, but not good as a 'user's manual'. Webinars are good, but fly through the commands too quickly without any documentation. The tutorial manuals are good, but generally don't go deep enough, nor or they organized well for quick, later reference based on common working procedures; they also don't outline the bigger picture (it took me awhile to discover that slabs could be ceilings (not obvious to the uninitiated), etc). .....

Thanks in advance for a bit of your coaching! Best, Luke

[Jershaun]

I agree with mikatoa. I like revit. It knows how objects interact with other objects.

With regard to Luke's post, this is why Revit is simpler to use. New users don't have to worry about all these various settings just to get drawings setup on a sheet. Revit does most of the thinking.

@Vincent C

It's funny you say software shouldn't dictate to the user because that's exactly how I feel about vw. I also thought vw was the best thing since sliced bread however after I started learning and getting into Revit (with an open mind), I started to realise the shortcomings of vw and how far behind vw is and will be.

Basically, I'm ready for the change to Revit. Much more simpler and more control.

[bcd]

Personally, I'd like a way to turn off the stories interfaces completely. For many projects types they serve no purpose and only confuse the file structure.

[Tom G.]

"Basically, I'm ready for the change to Revit"

Jershaun--don't be a stranger. Be sure and come back to the Board and bash Vectorworks every now and then, just for old times sake.

Tom

Edited November 13, 2011 by Tom G.

[VincentCuclair]

It's funny you say software shouldn't dictate to the user because that's exactly how I feel about vw.

I find this hard to believe if you like the way Revit works because there, everything is dictated. There is basically only one way to do each action (I'm sure this appeals to many because it is simple to learn and apply) but no possibilities for workarounds if you happen upon something that cannot be done. Perhaps what you needed was the dictating way....nothing wrong with that however I don't that is exactly why I like VWs so much.........pity they just can't get the present tools to work properly.

Edited November 14, 2011 by Vincent C

[starling75]

http://www.youtube.com/user/3dmodelsfree

Very interesting, but still, Revit is almost 2 times more expensive and I doubt the program is equally more productive compared to VW.

Btw VW is not that strong BIM production tool but its flexibility, very good 2D and almost direct modeling 3D capabilities make it very powerfull designing tool.