Matt Overton Posted May 28, 2018 Share Posted May 28, 2018 Has anyone found a good way to build options or test changes within a single BIM file? Seems the only way to do it is have a file per option. Which then leads to lots of copy pasting and updating symbols in one file and having to update. The biggest impediment I've found is Stories don't allow 2 layers of the same level type. So if a Duplicate a layer to make an option it forgets it's story association breaking all the story aware objects like walls. I can re-associate with the story but not it's level, this not only takes time to break all the object then more time fixing them. It seems like there should be a better way. Quote Link to comment
zoomer Posted May 28, 2018 Share Posted May 28, 2018 Don't know if I got the question correct. I always have multiple Layers assigned to a singly Story. I always create my Layers in Organisation only, never in the Stories dialog. And yes, when duplicating a Story based Layer it loses its Story binding. And if you assign a Story with a certain height to a Layer, new or existing, VW somehow keeps the previous height of the Layer by adding a negative Z-shift to the Layer. So the steps to assign are always : - Edit Layer - choose Story in dropdown - set Elevation back to 0.00 (To get "relative to the Ground Plane" => =Story height) 2 Quote Link to comment
Matt Overton Posted May 28, 2018 Author Share Posted May 28, 2018 Given Design Development is a fundamental part of what we do as designers shouldn't it be easier and less error prone than that? Quote Link to comment
zoomer Posted May 29, 2018 Share Posted May 29, 2018 Of course. But this is one of the smaller problems for me. There are so many other problems with Story System I worry much more Quote Link to comment
herbieherb Posted May 29, 2018 Share Posted May 29, 2018 As always, there are many ways to organize variants in Vectorworks. We had recently played through this in the German forum: "For variants of the whole design I would always copy the current file. I would then create the layout for the plan output beforehand, so that it is the same everywhere. This is the fastest method, which does not require any additional configuration." "For variants that are within a project section and remain in the plan for a longer period of time, extra classes are created (e.g. option1, option2 or sun-store-open, sun-store-closed, etc.). The varying parts are grouped and assigned to the classes (only the groups, not the contents). You can then simply copy the viewports in the layout and you only have to change the visibility of these individual classes". "For material studies, the materials must be consistently controlled via classes. The classes can then be overridden in viewports. Many (monochrome) materials can be easily created with grayscale images and later colored with color filters in the material editor". "You can also create the individual variants completely as symbols - they can then be easily replaced in the layout at any time - and you can also "jump back" at any time - if you edit consistently..." Which methods you use depends on the situation and your workflow. Some methods can also be combined with each other. I find it quite cumbersome to copy layers to make options because this also interferes with the storey structure. I would always work with groups which are assigned to what I call container state classes. 1 Quote Link to comment
Matt Overton Posted June 1, 2018 Author Share Posted June 1, 2018 I have no problem with all these strategies they all work at different times. Still it’s not a single teachable system and that makes it a problem. Although must have another go at container classing as that is closet to how a versioning system would work. I think in past it came unusable with existing buildings demolishing different parts. Shame there isnt a way to push objects into an existing container assigned to group. After all at various way points in project you do want to clean out and freshen the file up for next stage of development. Given there is the resources to throw at VW in a web browser the. Versioning is definitely needed to stop that turning in to a right royal mess. Quote Link to comment
herbieherb Posted June 1, 2018 Share Posted June 1, 2018 It is not the way Vectorworks works to offer a single correct method. This may be considered a weakness, but many here find it exactly the strength of Vectorworks. It is an open package and can therefore react flexibly to new requirements. If you really want to have different versions in one plan, then this is possible. In many different ways. Isn't that great? Of course it makes it very complicated. It takes a lot of experience to apply efficient drawing strategies. An external draughtsman must first be introduced into each project. This is the price for great flexibility and freedom. A simple versioning system would not correspond to the Vectorworks philosophy. Rather, it would be great if we could assign several classes to objects. One for display, the other for additional visibility options. This would simplify versioning, because you no longer have to group. I even have in mind a fusion of classes and database. Each object would then have one class for display and any number of other attributes for further classifications. All current database entries would then come in here. The object attributes, general visibility and versioning, data visualization, BIM data and other databases would be integrated into a single system. That would be the real Vectorworks way. Translated with www.DeepL.com/Translator 1 Quote Link to comment
zoomer Posted June 1, 2018 Share Posted June 1, 2018 (edited) I think the Layer problem was answered (?) For the versions thing, I am not sure how a Versioning System could work and if I could understand the complexity. The only Versioning System I understand and can work with is C4Ds Render Takes. (Or nearly with Modo's less intuitive Render Passes) But these mostly rely on my existing visibilities and separation strategy from VW though. I have to do Versions all the time and it is tedious and very complicated based on VW's visibility options. But at least I can manage that complexity. I use Layers to separate things not related with the building like site models and to separate my Stories of the Building. I don't like many Layers for each Story. So for Versions effecting many Stories I don't want to make many duplicates of each Story. So give up my Story order for all elements effected temporarily. (This and reordering is much more tedious in VW than it needs to be unfortunately) But somehow I must separate everything effected by the Version from the things that stay. So that I can switch between Versions through Visibilities. And that is complicated enough in itself if you consider dependent things like Windows in Walls or Slabs connected to Walls and such things. Also elements happening in some Versions but deleted in others. That is where I ask myself, if and how a Versioning system could work without duplicates and in one file ? Edited June 1, 2018 by zoomer Quote Link to comment
zoomer Posted June 1, 2018 Share Posted June 1, 2018 (edited) On 5/28/2018 at 10:42 AM, zoomer said: Don't know if I got the question correct. I always have multiple Layers assigned to a singly Story. I always create my Layers in Organisation only, never in the Stories dialog. And yes, when duplicating a Story based Layer it loses its Story binding. And if you assign a Story with a certain height to a Layer, new or existing, VW somehow keeps the previous height of the Layer by adding a negative Z-shift to the Layer. So the steps to assign are always : - Edit Layer - choose Story in dropdown - set Elevation back to 0.00 (To get "relative to the Ground Plane" => =Story height) I think I misunderstood your question anyway. I do never use Layers assigned or created by Story's "Levels" I just assign a Story to my Layers. And as you said, you can have more than 1 Layer using the same Story. In the best case, I want only 1 Layer per Story, to be able to switch Story visibilities comfortable. If I ever need more Layers per Story, I assign the same Story to these. So all these Layers are on the same Z-Height. I see no need to have more Layers per Story (because) on different Z Heights. As it is propagated to have a Slab + a Wall Layer. I don't do that. Because I have Levels to bind PIOs to such Z heights ! If I would really need some Layers per Story on different heights, (like Split Level or such things), I would typically still assign the same Story to all those Layers and manually assign the Level Z-Offset in Layer Settings manually. Edited June 1, 2018 by zoomer Quote Link to comment
Matt Overton Posted June 4, 2018 Author Share Posted June 4, 2018 Zoomer, Yes, the levels system is proving problematic on a number of fronts and seems to only really add value with (few) PIO's that can be bound to them. Walls styles haven't really worked well interacting with levels within a storey. Slabs and Roofs can't react to levels. Windoor doesn't work with levels anyway nor do most of the fitout PIO's. If we basically ignore levels the system works better generally. Including getting back to being no worse off than previous with Duplicate and Name layers for options. 1 Quote Link to comment
zoomer Posted June 4, 2018 Share Posted June 4, 2018 Yes, for now there are a few PIOs missing like Windows and Doors. (I think they can in german localization) For me it works quite well with Wall Styles - since there is that individual height setting + prevent replace height for custom heights. Beside Levels currently aren't very useable, parametric or flexible. I could just change Story Z-base levels and adapt neighbored Layers manually too for changes if needed. 1 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.