Using Design Options for Small Variations of Repetitive Hotlink Modules (Hotels etc.)

[wkrt-hs]

Design options in AC 27 raise hope to solve a longstanding challenge in hotel/housing projects with repetitive room or apartment modules.
Usually, over time, there are more and more variations within modules that were the same in the beginning. For example caused by structural differences in higher vs. lower storeys.
Until now, this ment that we had to either break the hotlinks or create multiple versions. Both approaches break the basic advantages of hotlinks, like avoiding the need of dimensioning every single instance, or applying common changes to every instance individually.

Using design options, I can keep using one hotlink module for many instances while being able to include some differences e.g. in wall thickness or material etc.

My question is: Are there any experiences with this workflow already? 
There are still some challenges, and many options in regard of how to apply the Design Option Combination - Design Option Set - Design Option logic to this workflow.

[Aaron Bourgoin]

not yet, but it's definitely in our template roadmap.

[wkrt-hs]

As I am working on different implementation options right now, I'll just share my WIP thoughts:

For this example, I'm using a basic housing project with different apartment types. For some apartments, there are slight variations e.g. in wall thickness, material or existence.
The apartments are modeled in the negative storeys of the project (iceberg structure) and linked as hotlink modules in the positive storeys.

Before the design options feature, having slight differences meant that we'd have to copy the whole apartment to another storey for each variation.
This is problematic because it means that hotlinks are loosing their advantages as many identical elements are modeled several times - and changes/dimensions have to applied individually. Also, the project and storey structure is getting more and more unclear.

How design options could be implemented:

A:

One design option set per apartement, which contains several design options.

Ap. 1 (design option set)

A (design option)

B

Ap. 2

A

B

C

This approach is quite intuitive and simple. When placing the module you simply chose the appropriate design option.
A big disadvantage is, elements that are part of multiple, but not all variants, have to be modeled multiple times - something that we wanted to avoid from the beginning.

B:
For this implementation, we're also using design option combinations. It enables the reuse of those elements mentioned before for multiple, but not all variants. At the same time, this approach is maybe less intuitive.

Looking at design option sets and design options, we have a structure like that:

Feature 1 (design option set)

A (design option)

B

C

Feature 2

A

B

C

Feature 3

A

B

..

The "features" are generic and are just option sets that can be used in multiple apartments. In each apartment, one "feature" stands for a specific area that exists in different variations, e.g. a wall that exists in different matierals. In another apartment, the same "feature set" can be used for a completely different area.
Now we can make use of the design option combinations to create apartment types that are partially using the same elements. Each design option combination has the name of a specific apartment type and is containing the respective combination of feature options.

Ap. 1 - A (design option combination)

Ap. 1 - B

Ap. 2 - A

Ap. 2 - B

Ap. 2 - C

While the second option is definitely more powerful and really leverages working with hotlinks and avoiding multiple instances of the same element, I'm a bit afraid that the solution described above is not intuitive enough for a easy implementation in everyday workflows.

I'm really looking forward to more thoughts on this topic!

Edit: B: Maybe the idea of generic features is a bit off, and it would be more intuitive to just create individual design option sets for each individual feature of every apartment, resulting in a more verbose design option set structure like that:

Ap. 1 - Walls 01, 02 (design option set)

A (design option)

B

Ap. 1 - Wall 03

A

B

C

Ap. 1 - Door 02

A

B

Ap. 2 - Walls 02, 03

..

[Mahmoud Qenawi]

That's an interesting topic,

For me i consider the module file which have all required dedign options as follows :

Every room is represented as a design option like Kitchen 1, Kitchen 2 & 3 inside a design option set named kitchen,

Also Master bedroom and bathroom design sets then i create different design option combos according to the requested apartments which contain some visible options inside their relative sets.

Then i have all freedom to choose which apartment (represented by a combo) is shown by the module file in the main design file.

Edit: Regarding external and internal walls & openings they can be modeled as design options in the main design file under sets named to floors (Ground, First,....) and combos named to building types (A, B, C.....).

Or w/o creating another main design file i can continue in the same file by using renovation filters,

Here i can model all floors and assign each plan to a custom reno filter, this way i can modify design options directly without leaving the file as in HLM case.

[NicolasSolid]

We are currently using option B that you recommend. It is quite confusing sometimes but it is better for managing the elements properties or geometry for elements that are identical between the options. So we just have one module file containing all the options and then build up our masterplan by hotlinking it. 

The issue i have now is that with the masterplan the plan views are VERY slow even though the 3D navigation is quite nice. Does anyone have any experience with this methodology and how to speed up the masterplan?