BIM workflow questions, issues

Zsolt Jármai

 Hey!

 I'm testing Bricscad lately and I really like the approach of BIM in it. Though I'd like to ask about the ideal way to manage multistorey buildings, In the case of bigger buildings managing all floors in the same model file is not so practical, so I tried a workflow as in bentley building designer, that all the floors are seperate dwg-s  xref-d into a Master model file (even better if you have exactly same floors, when updating the floor plan all similar levels change) and then tried to generate sections of it. The first issue is the constructs of different xrefs don't merge even though they are from the same BIM construct, and the seperation line stays between them. The second is when generating callouts from this model some of the section fills behave oddly (full black). Is there a way to solve these things, or some other method for ideal BIM workflow? Anyway thumbs up for this great software!!

Thanks for your answers in advance!

Regards,

Zsolt

Lukas Fertig

Concerning the sections appearing black, have you assigned a material composition to your geometry? You also might want to check units and scale. I didn't set my units properly, resulting in some of the hatches being displayed off scale, so that they appeared like a solid color hatch. Correcting this solved it for me.

As for the xrefs, I'm trying the same thing that you do (setting up a workflow, managing multistory/component buildings). I guess you can't get them to merge, as they're still individual xrefs/blocks in your drawing. Someone correct me in case i'm wrong.

Regards,

Lukas

Hans De Backer

For larger buildings the intent is indeed to use xrefs to split them up, which is also a requirement to make teamwork possible.
The separation lines on facades are undesired indeed, we are looking into the possibilities to either avoid them or remove them automatically from generated drawings.

The hatch fills probably are so dense that they look like solid hatches. If you file a support request and attach a sample we will have a look and see what is the cause.

Best regards,
Hans

Zsolt Jármai

 @Hans

"The hatch fills probably are so dense that they look like solid hatches."

No it's not like that. I've set the section hatch scale in the construct component settings correctly and it behaves correctly in 90%. I'm not at my computer nut I'll try to describe it. So let's say we have a cavity brick wall and a window in it. We xref it into a master model and place it on top of each other. We generate a section through the window. The brick hatch under the window (where it touches the other xref) is black, above it it's correct. I'll post an example image when I'm at my machine.

"The separation lines on facades are undesired indeed, we are looking into the possibilities to either avoid them or remove them automatically from generated drawings."

That would be great!!!

Anyway thanks for your response!

regards,

Zsolt

Roy Klein Gebbinck

An alternative for the Xref based workflow could be the use of components. With components teamwork should also be possible. Using components does not solve the problem the OP has mentioned, but it does have the advantage of not introducing, often many, Xref dependent layers.

I wonder why a component based workflow is not the default BIM approach. What is against it? Is a BIM 'assembly' too complex for the Mechanical Browser?

Lukas Fertig

Hm, never thought of the components option. Is there any limit to scalability, how complex projects can become? Can you isolate components to look at, lets say, only one level of a building?

Blocks to me have the advantage of being imported as instances in many softwares for visualization, which saves editing and render time when dealing with multiple instances of some type (windows, doors, chairs, etc.). Concerning the layers, as long as you choose the insert option for xrefs, layer names are not prefixed.

Roy Klein Gebbinck

@ Lukas:
Blocks are not the same as Xrefs. You seem to use the terms interchangeably.

Zsolt Jármai

@Roy Actually using components and the mechanical browser sounds a good idea. Thanks for the tip! I'll test it. Quite an unusual aproach though as far as I know, but we'll see.

Tom Foster

Roy, simplistic question, hoping for deeper understanding, aren't Xrefs just Blocks that are saved externally into a separate dwg file? While Blocks are effectively saved into the same file as you're currently working in?

So if a solution to the OP question is to have ea floor as a separate Xref ref'd in, couldn't same be done by making ea floor a separate Block? That is, unless the aim is to break the model up in order to reduce file sizes. Other things being equal, I've found it easier to be constantly opening floor-plan-size Blocks to in-place edit them, then save and close, that to do same with Xrefs.

Lukas Fertig

 Thanks Tom for bringing up this question, it seems i have the same misunderstanding (?) of a block.

Roy Klein Gebbinck

Tom, you are right. Xrefs are in essence similar to blocks except that they reference an external file.
If your entire model and all your layouts are contained in a single file, and you are the proverbial 'one man band', you may well prefer blocks over Xrefs. If, on the other hand, you are part of a team working simultaneously on a complex project, using Xrefs is almost imperative. The choice is not just about file sizes. As a team member, you may be working on the ground floor plan, while your colleague is working on the façade, using your plan as an overlay, and another colleague is creating the layout for the ground floor. This type of collaboration would be very hard without the use of Xrefs.
I have nothing against normal blocks, but Xrefs and blocks are different. If you use the 'insert option' for an Xref, you should be aware that you are turning the Xref into a normal block that no longer references an external file.

Tom Foster

Thanks Roy - good to have it confirmed that the difference is nothing more than what you've described. Now, why can't help files explain it like that?

Knut Hohenberg

[code]An alternative for the Xref based workflow could be the use of components.[/code]

Roy, this is exactly what I thought, and already tried to some extend. I think it would in fact be kind of stupid from Bricsys' side not to leverage their component technology for architectural modeling; first, the mechanical (this name should change) browser offers nice functionality for navigating your model, hiding parts of it, or e.g. displaying the parts you work on shaded and the parts you need for reference in wireframe. Second, keeping modeling techniques for all disciplines that might use BricsCAD as close as possible together seems to be a logic continuation of the 'do everything in dwg' strategy.

However, there are currently some drawbacks to using components - some inevitable (as far as my shallow understanding goes), some hopefully lifted in the future.

In detail: if you BMINSERT a file, the following logic seems to apply:
- if the file does not have a mechanical structure, it will be inserted as Xref, with additional properties that cause it to show up in the mechanical browser.
- if the file does have a mechanical structure, its content will be read in and placed into an anonymous block, which gives you the possibility to change its parameters, but on the other hand means that you lose the possibility to edit it in place (which is bad for architectural modeling).

At the moment, the second form of insertion applies not only to files that contain directly editable parameters, but also to files that just contain components (like windows and doors). This could certainly be corrected, but my preference would rather be to let the user choose the intended kind of insert.

For example, the attached file (multiple_storeys.dwg, sorry for its ugliness) contains the same simple floor (variable_height_storey.dwg) stacked up four storeys high, with the middle two (standard) storeys inserted as xrefs (to keep them directly editable), while the top and bottom storeys are inserted as components (so their parameters get exposed and can be overridden). If you refedit the standard storeys and use direct modeling to change something, this will propagate to the bottom and top ones (needs a BMUPDATE), but if you change their storey height (GSH) parameters, the bottom and top storeys will not be affected.

Note that the way the storeys are glued together by constraining the top wall surfaces to bounding box solids that are in turn connected by coincident constraints is probably over-simplistic and of limited use in real-world scenarios.

And be warned that changing the TSA parameter to a value that causes an intersection between the top and bottom surfaces is likely to crash BricsCAD.

One last thing: I tried to insert a door into the bottom, parametric component. The BIMINSERT command correctly picked up the nested wall surface and allowed placing the door as usual, but creating the relation for the opening did not work. I wonder if this could be made to work...

test3.zip

Roy Klein Gebbinck

@ Knut:
Maybe the BIMINSERT command has changed since your experiment. In my test the command always results in an insert of an anonymous block. Note that I have only tested with fixed components. If the same fixed component is inserted a second time, the new insert references the same anonymous block as the first. However, changing the visibility or the shading of a nested component results in the main component referencing a new anonymous block definition. This situation remains after changing the nested component back to its original appearance. So multiple instances of the same fixed component can, unnecessarily, reference multiple anonymous block definitions.

The fact that BIMINSERT results in at least one anonymous block definition is a disadvantage when compared to using Xrefs (increased file size). But the features of the Mechanical Browser, thanks for pointing them out, are indeed clear advantages.

Roy Klein Gebbinck

...
About BIMINSERTing in nested walls: I would not be in favour of this.
What I have requested is the ability to BIMINSERT in multi-ply constructions (adjoining solids that share a major face). I believe mutli-ply constructions can be very useful. For example when dealing with complex L- and T-connections.

Tom Foster

Indeed, a BIM can't be called a BIM unless it has good, flexible multi-ply facilities - you might as well use any old solid modeller. Non-multi-ply building 'planes' are rare.

Knut Hohenberg

Roy, I was talking about BMINSERT, not BIMINSERT.

As far as I can see (I just switched to 16.0.07 on Linux), the BMINSERT command still behaves as described - if you insert a dwg without mechanical structure you get an Xref, and if you place more than one instance, you can change the visual style for each of them without turning anything into anonymous blocks.

I think BIMINSERT should offer the same choice as I requested for BMINSERT: attaching an opening either as static (xref) or dynamic (anonymous block) component.

Dynamic components clearly have advantages as well as disadvantages (increased file size, no refediting); IMO the ability to apply geometrical overrides (the door in the example) could be seen as another use case for them.

I second your request about multi-ply construction; the 'compositions' approach looks only feasible for preliminary design, there will be the need to explode these multi-layer materials into real geometry during design development - unless you prefer to switch to 2d at that point anyway.

How to best glue this geometry together remains to be seen - I guess the same approach as with windows and walls could be used, but it should be possible to expose these normally hidden workings, so parts can be detached an re-attached as needed.

Roy Klein Gebbinck

@ Knut:
Aha, similar commands with similar names... confusing!
The _bminsert command still works as you have explained (V14.1.05).
But there are two interesting issues which add to the confusion:
1.
If you _bminsert a component that used to have a 'mechanical structure' (e.g. a wall that used to have a window) the component will always become an anonymous block. It does not matter if you purge the component's dwg file prior to inserting it. You may have to delete some hidden data. I don't know.
2.
If you have a component dwg that never had a 'mechanical structure' and you use both _bminsert and _biminsert to insert it, the order in which you use the commands determines what will happen. If you use _biminsert first, the component will become an anonymous block, and subsequent calls to the _bminsert command will also insert it as such. Use _bminsert first and the component will become an Xref and the _biminsert command will also use that method.

Knut Hohenberg

Hello Roy,

thanks for shedding more light on this - so the situation is even more convoluted than I understood.

But luckily, the solution still looks as simple as before: don't try to be too clever, just let the user decide...

As to 1.): Did you use BMUNMECH to purge your drawings?

Roy Klein Gebbinck

@ Knut: To lose the 'mechanical structure' you indeed have to use bmUnmech. Thanks.

Knut Hohenberg

Doing some further testing, I ran into additional problems using components / sub-assemblies for model organization that made me switch back to using plain xrefs for the moment.

Mainly to reactivate my rusty lisp skills a bit, I used some spare time over Xmas to write a couple of scripts that partially make up for the now inapplicable ease of use that came with the mechanical browser and the related commands.

As a replacement for applying different visual styles to components, overriding xref layer material settings looked like a viable workaround to me (as long as the geometry uses materials byLayer). The attached xrefdisplay.lsp contains an XDISPLAY command that changes the layer color and material of selected xrefs to chosen values, while its counterpart XRESET reloads the original settings defined in the source files.
To substitute for BMHIDE, there is an XHIDE command that will hide selected block and xref instances, and an XSHOW complement to BMSHOW as well. Additionally, a similar pair of commands for un- and reloading xrefs is also included (XUNLOAD / XRELOAD), as well as a complement to BMUPDATE (XUPDATE).

The commands do not closely follow the options found in their BM* counterparts, but e.g. use dialog boxes to choose the inserts to unhide or reload, and implement a kind of undo functionality for hiding/unloading xrefs via two global variables (xhide_list and xunload_list) - this will only work reliably if you do not use other means for the same purpose, e.g. (UN-)ISOLATEOBJECTS, but should not have negative side-effects as far as I can see.

See the attached screen-capture for example usage if you think these scripts could be of any interest to you.

To avoid misinterpretation: I still think that the mechanical browser could be a big asset for building modeling, it would IMO just need the option to choose between static and dynamic (xref/anonymous block) insert mode for components, and a bit of tidying up (e.g. classified solids showing as walls, slabs etc., and doors and windows listed as child objects under their respective wall parents).

xrefdisplay.mp4xrefdisplay.lspxrefdisplay.dcl