Dieter @ DWorks

Aha! there's a bug in VW, which will remove the level type of a level if you remove it through layer organisation >> level types. But when editing the level, you will not be able to leave the dialog without setting a level type, so it is intended for levels to Always have a level type?

??? Is this true? I guess I have to play with it more, or I'm just seeing/feeling it differently. Because that would mean that level types currently are for having some kind of level in each story at the same height, and the normal level is for all those additional levels you make for certain stories that are at different heights, I will investigate this further.... I really don't see this. You Always have to have a level type, though the level doesn't have to be a default level. I think there is a misunderstanding because of translations? What I see in the NL version is that you level types, which a level Always haves. Besides this you have levels and default levels?

??? Is this true? I guess I have to play with it more, or I'm just seeing/feeling it differently. Because that would mean that level types currently are for having some kind of level in each story at the same height, and the normal level is for all those additional levels you make for certain stories that are at different heights, I will investigate this further....

no problem. It's by having a discussion around this that this feature can be cleared out for the devs.

Not needed if they let us select the levels of different stories in a list and edit them together.

No and Yes. To the user, you only have level types, like ceiling, top finish, etc... But actually, you have those level types, and for each story you have levels, which are one of those level types, but as the user always sees all level types that can be chosen, and a level is only created when activate it for that story, the user never experiences the difference. I think it's important that they are called level types, as a level type can be activated for each story and the bounding now works like level type [story/story above/story below], which gives a better understanding of where you do bound at. So it is a type, but the actual level in a certain story can be at any z-height. This will only work if levels aren't bound to a particular story. You are actually making it more complex for the user. It's far easier in bounding to levels when you know it's the ceiling level type you bound to and of which story, hence the current bounding 'Ceiling [story above]' etc... The height will be set for each type differently in each story. Ok, it's more abstract, but less complex though. IF levels weren't part of stories, than this would work very well, as you than have a system of levels, and nothing more, you can create a level with a unique name and z-value and you can bound to it. That would be very easy and simple, but due to the restrictions of VW, this will not happen. We draw the 2D plan first, not the 3D, that's why they restrict us to bounding only to levels at the story above or below. (And that's fine for me, only restricting for the further development of VW...) BUT it will be harder to set IFC data as VW still have to know at which story each object is.... - A level type can have a z-value, which will act as the default. When you active a level type in a story, you can set the z-value of it for that story. Not each ceiling is at the same height for each story. - Well, that decision is plain WRONG! Why would each ceiling (or any level type) be at the same height on each story?! Because of this you will get ceilingAt200, ceilingAt250, ... while you could just use one level type ceiling. This is very crazy now! I wonder why they did this. - Why do you need to have a z-base-height that's the same for each story, I really don't get that. Even though a ceiling might be at the same height for each story, that's not the point of a level type. - Why would you want this? A level type is just a name to identify the kind of level, and than you can just say that it's at a certain z height in a certain story, it can't be simpler. I have a ceiling level type, and I want to declare that in certain stories on different heights. - Yes, then you will see much faster at which story a layer is situated. The prefix/suffix now is just to create the layer, it doesn't update after the creation on any changes now. - No, as we wont be able to change that prefix ourselves, we can just give the layer a name, the prefix will be shown automatically based on the story it is bound to, or not. - Why? The system is almost now as I propose, I just want it to be more clear and automatic. - Yes, a layer should be able to bound to a level as any other object. It's basically saying, this layer should be at that level type of the story it is bound to. This way you can have multiple layers at the same level type, and this is only needed for all the objects that can't be bound to a level type at the moment, because when all objects can be bound to levels, this isn't needed anymore. So it's for backwards compatibility. - Totally - You can't see it that way, but you can say: I want a DL for a suspended ceiling and lighting components, and I want a DL for the fire detection and suppression equipment, both have to be at the ceiling level. DL are just containers you can use to draw and as long as there are objects that can't be bound to levels, you have to be able to say that the DL would be at that level instead. - Not true, as the level binding isn't required for a DL! A DL should be able to be in a story, but the bounding to a level type in that story should be optional (it's just for setting the height of the DL, keep in mind that the ultimate future is that every object can be set to a level type). So you just create the DLs you need, nothing more, nothing less.

Haha, lol, that's a very old one! I reported it a long time ago, but it's still not solved, that's why I always advice to have your classes structured in a good way, so that you don't ever need to scroll, use the 4 levels we can use and you'll never have any trouble with it. Plus it will be more clear to select a certain class for any user.

You can change a story in z-height without affecting the others...

@gester, sorry to disappoint, but these drawings are 2D ones. Though I draw the water proofing in 3D now, sort of. I use walls and slabs to create them and they are good for the building application, but not for details.

Thx for all these great views on this subject, but let's not forget simplicity/consistency here and get to the core of it. In essence, this is how it should work: (forget the DL linking to Level types! that's absurd, DL should be able to be at a level type like walls do, so we can have multiple DL at the same level type of that story!)

Ok, this is actually very simple to accomplish. You just have to see a story as not the complete story with floor and ceiling, but see the story as the whole slab of that story. And to make it easier, combine floor 1 and floor 1.5 into one story. Ow, and as a plus, you'll not get into trouble with story levels overlapping... Here are sections to see what I mean: (They aren't split levels, but you will get the point, you begin with drawing story boundary lines through the middle of each floor.)

Please leave stories. Revit does have them, but it's not really visible to the user though. And the levels in VW are actually like Revit, the difference is that Revit does it graphically and VW through dialogs. My main point and frustration on stories and levels is that it's too restrictive, though that's solved in v2015, but side things like defaults etc... still make it restrictive! They just need to clean it up and it's ok. For example, when you edit the z height of a default level, VW creates a new one, so you end up with two levels???? Defaults should not be about z heights, as that can differ on many occasions, it should just be about the name and basic settings. In general defaults are just for getting initial data when you create things. I'll try to add real use cases in the next couple of days to show what I mean.

Thx for that, but to be honest, if the system really needs such a long help file, then it's way too complicated. this should be simple for users to use. I really don't know why they are making it so complicated. The way I see it: - Design layers are just containers to draw, nothing less, nothing more. There is no reason to bind a level type to it, unless you want objects that can't be bound to a level type at that z height, though this can be solved by making sure each objects can be bound to a level type.... - Design layers can be 'bound' to a story, so that the objects in it know to which story they belong, but that's just saying to the layer that it belong to that story and setting a specified z offset relative to that story. - Level types, which belong to a story should not be bound to design layers. No reason for this. We just want to use them to have objects be bound to them so that they are at the correct z height and overall height etc... It seems to me that VW is tying too much together. This can also be seen with wall styles. Wall styles should be just defining what kind of wall it is with which wall components in which class etc... There are settings that should be based on the wall instance, like the offset of the components. For example the wall on the ground level can have an offset due to the connection with the foundation, but the levels above will have not... But that's for a different wish list item....

Thx Matt! I have bought this tool not so long ago and must say that it's a super good one! Easy to work with and great results.

It's been some time that I actually had to draw much in VW, but the 'new' way story levels work is driving me crazy? How could someone get away with this? He who designed this should be fired! It is way to restrictive and you end up with lots of stuff you don't want. Let me explain in more detail some points of this: - Why have the default levels in a drawing the same height offset? It's nice to have an initial default offset so that you can go with that at first, but not all building will have the same height offset for some type of level. Now when you edit the level, you end up with two levels of the same type but with different offset Heights. This is crazy, I just want to use that default level type, but have it at a different height offset. - The same counts for the layer you can add to the default level. This should only serve as an initial setup when you add that type of layer, but if you don't want it, then let us remove it for that story. - Let us bind existing level types to existing layers. Why can't we? It's crazy. Do I really have to create a new layer through a level type and then move all objects to that new layer and delete the old one? - And the list goes on.... I thought that they had all this story stuff worked out after the previous disaster, but it's just got worse. So please revision this so that it just works and is user friendly!

Hi, sorry to bring this back up, but it's still not fixed. And reload works, but then you have to do it on every import in every file, wich is not plausable when you structure your work in a good way... Is there a nother solution to this? I wouldn't mind restarting VW if it just starts, but as it crashes on startup most of the time....

I really had enough, If I'm Lucky, it doesn't crash the 10th time... All loads, I can see a new document being created, and then, poof, it just crashes. The log files are no use as they don't tell anything what went wrong. Does anyone else encounter this? I really can get some help with this. Debugging with Visual Studio gives me the following: Unhandled exception at 0x0000000000000048 in Vectorworks2015.exe: 0xC0000005: Access violation executing location 0x0000000000000048.

I do the same now. If you don't use the Heights/boundings by wall style, it's really easy and far better. That's why it's really really bad that we can only set the wall component bounding through the wall style, THAT, and only THAT makes it complex and a mess. If you bound per wall, you can easily unbound the bottom, or better bound to the bottom and say that your whole is x high, to automatically adapt.

For your particular situation, I draw the walls like normal, as it will be better for your spaces to bind to. By this I mean that you should not create the whole, but include that peace in the room. Then you can set the height of each wall to your liking. For the 'beam' above the hole, I solve this by drawing another wall on a different level. Your wall connection will be correct. If it's not clear, tell me. It's no good to bind wall components to levels, as you can't control it anymore on a wall by wall basis. As long as we can't do this for each wall, it's a useless setting and far better to use the normal wall bounding settings, like it worked before. Floors will cut out the walls were needed.

Play with the roof line you see in plan view, the roof edges are drawn differently if they are below or above that line.

+1000 for the gaming environment. It really is better to view the model that way, probably even better for walktroughs.

If two structural elements line up correctly, then there will be no line visible. So check that first. When you can't find what's wrong, please post a picture of the situation so we can look at it. There are several threads about these lines...

We also need more control for the classes. I know create several auto-hybrids to get the classes right, when one should do it. For example, the object cuts have to be in some sort of hatch and the visible objects in a color. You can use the by class for the cut, but the visible objects can't be if you want to show them different, meaning they will be only one color. I personally think it doesn't need fixing by the auto-hybrid, but by the classes themselves. A class should have at least two fills for this, one to represent the cut, and one for the 'front' view. When this is done, we don't need to set the classes anymore in the auto-hybrid, because we then can just rely on the classes. The auto-hybrid will draw the cuts with the cut fill and the visible parts with the 'front' fill. This should also benefit all other things, especially sections, where this system also can be used, even for walls. I wonder why the didn't even have done this by now, or they are planning to incorporate materials that bring this?

I disagree for the most of this. Yes it's true that the most auto-hybrids drawn are architectural things and you only draw them once, BUT it's also true that those things have to be shown on different levels most of the time, and then you have to duplicate the auto-hybrids, setting one to 2D/3D and the others to 2D only. In this case, you can use a symbol inside the auto-hybrid to really use the same, but a symbol with an auto-hybrid would be so much simpler, where you can then set the cut height for each symbol instance and if 3D must be drawn.

Though I agree, the question is what happens for example when you make a door into an auto hybrid what representation is it supposed to choose for the Top/Plan representation? I mean PIOs are already a sort of auto hybrid...?! The same applies for a stair, perhaps even more so because the stair has a Top/Plan representation for the actual floor plus one floor up....?! That's an easy question, if such pio is used in a auto-hybrid, the 3D part must be used to create the 2D part, as that's the auto-hybrid is all about. That's why I would rather see it being part of a symbol: You can then choose if you want to draw the 2D yourself, or let it render by the auto-hybrid option of the symbol.