Jump to content

BIM vs Design Developement


Recommended Posts

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.

Link to comment

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)

  • Like 2
Link to comment

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.

  • Like 1
Link to comment

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. 

Link to comment

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

  • Like 1
Link to comment

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 by zoomer
Link to comment
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 by zoomer
Link to comment

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.

  • Like 1
Link to comment

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.

  • Like 1
Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...