Simple vs complex is done best by having multiple geometric representation contexts at different target scales.
I agree (though others may have different views) that the best way to handle simple and complex representations is through multiple geometric representation contexts at different target scales. The question is—should additional details be captured within the shape definition itself, even if they aren’t always used in certain representations, such as a 1:100 drawing?
For example, in the image below, these profile details could be defined within the shape but only activated when a higher-detail scale is required.
If this is the right approach, I was thinking that three predefined increments might be sufficient:
1:5 and below (high-detail representation)
Above 1:5 up to and including 1:50 (moderate detail)
Greater than 1:50 (simplified representation)
Alternatively, should these increments be user-defined for more flexibility? What do people think?
@tim user defined, I may not want to have anything but a simple rectangle at any scale whereas others may for perfectly valid reason want ten options. Also in the world we use 1:10 1:50 etc but freedom units have 1 inch equals a foot or something like that so even the scale naming needs to be user definable
@tim when you say 'multiple geometric representation contexts' what does that mean as I took it to mean changing levels of detail at different scales or is it something else?
Yeah, that was probably a bit misleading - the implementation in Bonsai can come later. For now, I just wanted to gauge whether defining detailed elements at the "shape" level is a good approach. Personally, it makes sense to me, but I’d love to hear if others see any drawbacks. Also, good to know that user-defined scales are the preferred approach.
I know "target scale" comes from ifc, but I believe "target design phase" would be more appropriate:
3D views don't have a scale
Sometimes you need 1:100 in early design, sometimes it is enough for construction, but the detail level needs to be different
@tim said:
Yeah, that was probably a bit misleading - the implementation in Bonsai can come later. For now, I just wanted to gauge whether defining detailed elements at the "shape" level is a good approach. Personally, it makes sense to me, but I’d love to hear if others see any drawbacks. Also, good to know that user-defined scales are the preferred approach.
I'm still not sold on packing everything in a single element (what Revit does) it leads to bloated models and confusion in the early design phases, because you have 20 different types of doors you have to choose from, even though the information is irrelevant in that early design phase and you want to leave it out.
As I said I'd prefer having a primitive "design phase door" and be able to easily switch it to a more complex one later.
The complex window/door divisions in some of the sketches surely require a graphic interface. Maybe it's more feasable to pick from a list of enumerated partitions.
The object should be modelled with geometrical detail that will not compromise the BIM model when used in practice. To avoid over-modelling, follow the principle of not modelling elements of a product that will not be seen.
The same NBS source proposes Boolean Yes/No to deal with information on accesories that don't need to be modelled (from attached shared parameter file) e.g.: HasLock, HasGrabHandles, IsLaminated, SelfClosing; hasPanic, TripleGlazing, IsWired, DoorSeal...
@tlang said:
The complex window/door divisions in some of the sketches surely require a graphic interface. Maybe it's more feasable to pick from a list of enumerated partitions.
Ha, cool, didn't know this existed. But I'd still prefer a graphic interface.
The same NBS source proposes Boolean Yes/No to deal with information on accesories that don't need to be modelled (from attached shared parameter file) e.g.: HasLock, HasGrabHandles, IsLaminated, SelfClosing; hasPanic, TripleGlazing, IsWired, DoorSeal...
I'm not a fan of booleans for properties that generally require more detail. For example HasLock - pretty much all doors have some kind of lock, but what kind? IsLaminated is one of maybe twenty different possible surfaces, in Europe we have at least three types of panic handles, three types of closers and so on.
Comments
I agree (though others may have different views) that the best way to handle simple and complex representations is through multiple geometric representation contexts at different target scales. The question is—should additional details be captured within the shape definition itself, even if they aren’t always used in certain representations, such as a 1:100 drawing?
For example, in the image below, these profile details could be defined within the shape but only activated when a higher-detail scale is required.
If this is the right approach, I was thinking that three predefined increments might be sufficient:
Alternatively, should these increments be user-defined for more flexibility? What do people think?
@tim user defined, I may not want to have anything but a simple rectangle at any scale whereas others may for perfectly valid reason want ten options. Also in the world we use 1:10 1:50 etc but freedom units have 1 inch equals a foot or something like that so even the scale naming needs to be user definable
@tim when you say 'multiple geometric representation contexts' what does that mean as I took it to mean changing levels of detail at different scales or is it something else?
Yeah, that was probably a bit misleading - the implementation in Bonsai can come later. For now, I just wanted to gauge whether defining detailed elements at the "shape" level is a good approach. Personally, it makes sense to me, but I’d love to hear if others see any drawbacks. Also, good to know that user-defined scales are the preferred approach.
I know "target scale" comes from ifc, but I believe "target design phase" would be more appropriate:
I'm still not sold on packing everything in a single element (what Revit does) it leads to bloated models and confusion in the early design phases, because you have 20 different types of doors you have to choose from, even though the information is irrelevant in that early design phase and you want to leave it out.
As I said I'd prefer having a primitive "design phase door" and be able to easily switch it to a more complex one later.
@JanF ... and be able to easily switch it to a more complex one later. That is a very appealing idea
The complex window/door divisions in some of the sketches surely require a graphic interface. Maybe it's more feasable to pick from a list of enumerated partitions.
Regarding scale let me quote the (UK) National Bim Standard:
The same NBS source proposes Boolean Yes/No to deal with information on accesories that don't need to be modelled (from attached shared parameter file) e.g.: HasLock, HasGrabHandles, IsLaminated, SelfClosing; hasPanic, TripleGlazing, IsWired, DoorSeal...
Ha, cool, didn't know this existed. But I'd still prefer a graphic interface.
I'm not a fan of booleans for properties that generally require more detail. For example HasLock - pretty much all doors have some kind of lock, but what kind? IsLaminated is one of maybe twenty different possible surfaces, in Europe we have at least three types of panic handles, three types of closers and so on.