Reflected Ceilings in 3D model

I'm frustrated too. How do you suggest we integrete the ceiling model into working drawings. When I use the ceiling tool I encounter problems just extracting the reflected view. Lights are getting overdrawn with the grid. Am I missing something here? Is the Ceiling tool not intended to be used in a 3d setting? Soffits pose another problem. How can you place a ceiling grid in a soffit using the grid tool. You need a separate space for the soffit. Doesn't make sense to me. What I am begining to realize is that Bentley Architecture is kind of a afterthought relative to all the other parts of the Bentley Suite. I can't seem to make working drawings with out drawing things twice. I model the ceiling once then redraw the RCP in 2d on a sheet. End of rant.

D

Hello,

The Ceiling Plan tools were written to help in the production of Ceiling Plan drawings, not for 3D modeling.  The ceiling elements are essentially either 2D lines of hatching or cross hatching and 2D pattern cells. 

Even though the current implementation is meant for producing drawings only, there are Family/Part definitions provided that will let you create a 3D ceiling grid from the 2D grid.  Once you place the 2D grid you can then use the Extrude Linear Element to Form command to generate a 3D ceiling grid.

Hope this helps,

Steve Stevens
Product Manager - Bentley Architecture

Hey Steve - I hope all is well.

Since we need the 3d of a ceiling anyway (Sections and Stuff)  - should it not just go ahead and produce the grid?????

Steve Stevens:

Hello,

The Ceiling Plan tools were written to help in the production of Ceiling Plan drawings, not for 3D modeling.  The ceiling elements are essentially either 2D lines of hatching or cross hatching and 2D pattern cells. 

Even though the current implementation is meant for producing drawings only, there are Family/Part definitions provided that will let you create a 3D ceiling grid from the 2D grid.  Once you place the 2D grid you can then use the Extrude Linear Element to Form command to generate a 3D ceiling grid.

Hope this helps,

Steve Stevens
Product Manager - Bentley Architecture

Great for 3D modelling? Now after I try your approach I want to change the setout point for the grid. Do you have to basically delete and redo? hnmm...

 I would hope a dynamic ceiling is in the works.

Mr. Stevens:

I understand, yes indeed, that "The Ceiling Plan tools were written to help in the production of Ceiling Plan drawings, not for 3D modeling.  The ceiling elements are essentially either 2D lines of hatching or cross hatching and 2D pattern cells." and this is, in fact, the very point I was hoping to draw attention to in my initial post.  One goal of a BIM workflow process in general, as I understand it and regardless of what flavor of BIM authoring tool is being used, is that it should not be necessary for a designer to manually draw 2-D representations of 3-D modeled bldg components & assemblies.  The grand idea is that the only 2-D drawing that should need to occur as a tracing over the (Extraction in the case of BAXM or DynamicView in the case of BAv8i) is that which pertains to the proper "annotation" of the particular view of the model which is to appear on a particular plotted sheet.  If it's necessary to redraw in 2-D any of the modeled "bldg" entities then that represents an immaturity of the BIM authoring app (which is not to say that Bentley's BIM apps are necessarily any less or any more mature than Autodesk's or Graphisoft's; they all have their respective immaturities).  I would hope that development resources are being or eventually will be allocated to improving this specific item.  In the 2007 response by Mr. Knipmeyer he used terms such as "limitations in the current implementation of the ceiling tools" and "not yet represented as a full 3D element" which suggested to me that he too understood this to be an immaturity of the product at that time.  The tone of his 2007 remarks did also suggest that we might find comfort in the fact that work was or would be underway at Bentley to grow the product along the expected development path.  Not being a long time 2-D Microstation user I'm assuming that this wireline clg grid tool is residue from the traditional 2-D Microstation app and will (soon?) be replaced by a different automated clg creation tool(s) which appropriately addresses the 3-D BIM approach to project design.  Is my assumption correct?  Is more specific feedback from we users required in order to formulate a new automated suspended clg creation tool?

At our firm one of our BIM implementation goals is to only need to revert to drafting or "drawing" 2D bldg content at the point where we shift to a detail view of an area which occurs on a plotted sheet of "details".  Views such as reflected clg plans, elevations, sections and enlarged plans, sections or elevations are ones which we expect our design teams to be able to generate from their 3D model as described above.  Probably this was a leap for most design firms in 2007 but I expect that this amount of leveraging the model is probably pretty typical of most design firms' BIM workflows now two years later.

I would take it forther than only notes, outlines, annotations should be placed upon a BV.  the Building view should be complete enough for a detail also.  I was able to do this on my last job.  the only difficulty is tuning a crosshatched form into cMU block and having all the centerlines work consistantly.

I would also like to have two different groups of centerlines and patterns - one for a plan and the other for a section.

AND last I need my elevations to pattern.

Mr. Milberger: Thanks for your thought provoking reply.

I assume that what you're describing is the use of DV's or DEM's as a background starting point for your details rather than the 3-D model itself becoming more granular with the inclusion of detail data.  Our Revit-based project teams have been pretty successful with this method as well and the coordination reverberation across the model is an important leveraging for those teams of the time spent constructing their 3D model.  Our previous experience with ADT and its DEM similar approach to coordination across the various views of the model had proven cumbersome usually to the point of uselessness so as we began utilizing BAXM we recognized pretty quickly the similarity of BA's DEM approach to that old ADT method of inner model coord so we've not really been pushing our BA users much to leverage their models in that way.  I anticipate that as we migrate our BA production to v8i (scheduled for Fall) we'll find that DV's will allow us to expand the amt of leveraging of the 3D model we can realistically accomplish on our BA project teams.

Your inclusion of elevations production into the conversation causes me to think more deeply about what we've been trying to accomplish with our RCP production.  We often do draft as 2-D overlay linework things like masonry coursing (sp?) and exp jts on our elevations.  Mostly, I guess, because the constant shifting of the working planes can become very difficult to manage, were we to draft these as 3D entities in the model, for all but the most BIM literate designers.  Conversely, however, we often draft floor tile patterns as linework straight in the 3D model because it would be much too difficult to try to keep multiple versions of the same floor grid coordinated across many views of the same location if we approached this as a 2D overlay at the plot sheets.  I suppose the proper workflow is for us to treat the acoustical tile clgs as individual clg slabs just as we do those gyp ceilings and then treat the clg grids as separate entities from the clg slabs that represent the mass of the clg tiles just as we would floor tile jt patterns atop the floor slab.  For some reason I had it in my mind that the ceiling grid tool provided in BAXM was intended to create both the clg slab mass and the associated grid linework of the clg tile joints.  And our workaround solution for no opacity to the clg grid "problem" whereby we created a single clg slab across the entire bldg using the bldg perimter shape is/was a quick opacity solution for the production of the "design intent" construction documents but, of course, it has down-the-line costs to whomever is doing the clash detections coordination as it then intersects every single interior wall which terminates above the clg plane...so we'll bag that quick fix.

Mr. Milberger: Thanks for your thought provoking reply.

I assume that what you're describing is the use of DV's or DEM's as a background starting point for your details rather than the 3-D model itself becoming more granular with the inclusion of detail data.  Our Revit-based project teams have been pretty successful with this method as well and the coordination reverberation across the model is an important leveraging for those teams of the time spent constructing their 3D model.  Our previous experience with ADT and its DEM similar approach to coordination across the various views of the model had proven cumbersome usually to the point of uselessness so as we began utilizing BAXM we recognized pretty quickly the similarity of BA's DEM approach to that old ADT method of inner model coord so we've not really been pushing our BA users much to leverage their models in that way.  I anticipate that as we migrate our BA production to v8i (scheduled for Fall) we'll find that DV's will allow us to expand the amt of leveraging of the 3D model we can realistically accomplish on our BA project teams.

Your inclusion of elevations production into the conversation causes me to think more deeply about what we've been trying to accomplish with our RCP production.  We often do draft as 2-D overlay linework things like masonry coursing (sp?) and exp jts on our elevations.  Mostly, I guess, because the constant shifting of the working planes can become very difficult to manage, were we to draft these as 3D entities in the model, for all but the most BIM literate designers.  Conversely, however, we often draft floor tile patterns as linework straight in the 3D model because it would be much too difficult to try to keep multiple versions of the same floor grid coordinated across many views of the same location if we approached this as a 2D overlay at the plot sheets.  I suppose the proper workflow is for us to treat the acoustical tile clgs as individual clg slabs just as we do those gyp ceilings and then treat the clg grids as separate entities from the clg slabs that represent the mass of the clg tiles just as we would floor tile jt patterns atop the floor slab.  For some reason I had it in my mind that the ceiling grid tool provided in BAXM was intended to create both the clg slab mass and the associated grid linework of the clg tile joints.  And our workaround solution for no opacity to the clg grid "problem" whereby we created a single clg slab across the entire bldg using the bldg perimter shape is/was a quick opacity solution for the production of the "design intent" construction documents but, of course, it has down-the-line costs to whomever is doing the clash detections coordination as it then intersects every single interior wall which terminates above the clg plane...so we'll bag that quick fix.

Yeess...BA ‘practitioner tools' have been pretty 'low tech' for a while. It's probably because BA is based on a third party add-on that was acquired centuries ago. Hopefully, there is some ‘next gen' rethinking going on back at Bentley HQ. Revit ‘cough' comes across as much more coherent and smarter package in comparison, even with its scalability and geometry limitations.

OTOH, DV/BV is a big step forward for Bentley, which gives BA a lot of the 'BIM'ey everything synchronized' feel Revit currently enjoys. Hopefully, all the knock-on implications on printing, translations, reference file handling/display etc won't be insurmountable. It must be a huge task to get what is displayed, printed and translated to be coherent while maintaining flexibility / performance / reliability. Hopefully there aren't any deep seated flaws that will dead-end or stunt DV/BV in the future.

For a lot of architects, going 3d as a goal in itself masked a lot of the sticky problems that needed to be solved first. For example:

1. Coordination: Before we needed to coordinate between 2D drawings. Now, we need to be able to coordinate between 2d and 3d. Bi-directional associativity  and other reference tools required.Scripted ref file attachments/ configurations with ACS matching? Prmis-e and Prosteel have powerful ways of linking views between drawings that make coordination much easier. Mstn should support multiple active models so that 2d and 3d files can be accessed simultaneously in the same windowfor coordination. Propagation alone will never fully adequate.

2. More information; 3d means at least twice as much information to be handled. Working in 3d means more filtering, view clipping, ACS management, orbiting about and  other buggeration that makes working with the files that much longer/harder.Give me Spacelaim / Cocreate style working in section and an accudraw that can manipulate 3d faces by their section cuts, please !

3. 2d vs 3d representation: Need to manage 3d as well as 2d representations (plan, section, elevation) of objects. 2d representation is heavily symbolic, driven by industry drawing conventions. This means that simple hidden line views are not adequate and lots of re-symbolisation is required. For some disciplines, the ‘schematic' view bears no resemblance to the drawing ‘projection'. Bi-directional associativity required. BA dimensioning hot spots are a start.

4. Level of Detail (LOD): LOD always need to be managed. Even if clockspeeds didn't stall. Agree that single databases are probably not the way to go.Revit has a hard time synchronising its database even on mid sized jobs and struggles to reference other more conventional file formats for coordination. More abtract infomation like key ACS. axes, planes, grids, boundaries, arrays, skeletons, rigs, contrained sketches, parameter sets/families, schematic P+ID etc will need to drive more verbose data, which in turn may drive more data. Procedural or dataflow orientation would help to control info overload and de-fog the designer's POV. See the way Tekla handles connections for a simple example.Would be interesting to see if the i-model format, which is supposedly faster, can be dynamically replaced locally by the 'real' data where editing is required like NX handling of JT.

 5. 3d CAD view versus Data-centric view that includes 3d: The latter is what BIM (with +ROI) should be really about. Working in 'information modeling' mode and not just '3d' mode requires  a supporting framework that is based on domain 'ontologes' like IFC/ISO 15926, KBE integration to capture industry specific rules / grammars for componentization, analysis / simulation knowledge fusion feedback loops / roundtripping...etc

6. ....

IMHO, none of these problems have been fully and effectively solved as yet. 

The idea of 'drawing once' in 3d and extracting 2d drawings that Yeo describes is really dangerous and naive. It ignores the fact that 2d information is here to stay and will always be separate from the 3d model. What Bentley needs to do is to facilitate simultaneous access to -and associativity/propagation between- 2d and 3d data.

I will say that I have been very succesfull having a 3dModel that does fully generate my sections and plans.  With the exception of a few elements that need greater detail line CMU walls my 2d generated sections are very workable at Detail Scale.

My elevations are also there if I just ahd the patterning of the materials for elevations.

It is the slowness of doning some tasks like streching an entire model across all the reference files as well as creating molding or mytered forms that maintain their intelligence.  A working method for roofs and the ability to see forms as 6 sided elements without a top or bottom

Mr. Seah:

If the point you're intending to make with "2D information is here to stay and will always be separate from the 3D model" is a reference to the layer(s) of annotation data which relates to specific planar slices through the model (ie:views which relate to a plotted sheet) then certainly I'd agree that this is an accurate assessment of conceptual limits that BIM software should not attempt to overcome.  Maybe we could even stretch the concept of "will always be separate from the 3D model" to include non-graphical attribute data such as links to spec sections, manuf data or the like and this could still have an accurate vision of where the BIM movement overall is probably headed.

With respect to actual bldg data (ie: components & assemblies) vs. the annotation data I'd say this differentiation (ie: bldg data vs. annotation data) represents the appropriate "goal" line of where it's reasonable to separate that data which resides in the 3-D model and that data which must remain external to it.  Our pain threshold toward achieving that goal at this time with BA seems to still be hovering around the enlarged plans, elevs, sections with the the large scale details LOD data starting to edge its way into the model.  At our firm we have teams who are able to push their "pain" threshold and extend their model coordination through to the details at least to a degree but then we have other teams where either there are cultural "but I've always done it this way" sorts of obstacles yet to overcome or there are bonafide technical limitations which restrict them.  BIM implementation is an evolutionary process much like the gradual process whereby CAD eventually overtook ink on mylar.  I recall centuries ago (oops I mean decades) how we used our paper plot sheets as an additional layer of data underneath our mylar sheets until eventually all the layers of data which we had been accustomed to placing on the mylar migrated to the CAD layers on the plot sheet beneath.  The diminishing return point of integrating increasingly detailed layers of bldg data into the coordinated 3-D model has a long way to move yet, in my opinion, before I would be willing to declare that we understand exactly how much granularity it's realistic to expect to eventually migrate into the shared 3-D model.  The larger danger right now, in fact, might be that of underachieving by underestimating the ability of your project teams to push their "intergrated into the model vs. external to the model" threshold a few notches along their particular implementation path.  You're absolutely correct, of course, in calling attention to the need to "eyes wide open" understand exactly where one should draw that LOD mgmt line for each particular project team.  But I'd be cautious about advising anyone to wait on the sidelines until "problems have been fully and effectively solved" before attempting to transform their 2-D workflows into 3-D/BIM ones.

I agree wholeheartedly, BTW, with your recognition of the need for industry standard supporting frameworks to help smooth the trail as BIM tools continue to evolve.  I had not encountered the word ontologies before though so I looked it up in the dictionary to be sure I'd understand your meaning precisely.  Interesting to me that you would draw (satirical?) references to metaphysics when discussing IFC development.  Hmmm.

Hi Mr. Yeo,

‘2D info to stay..'

I think you are jumping to the wrong conclusion here. I am not promoting the idea that 2D annotation data and 3D data should be kept separate, in line with common practice. I am saying that they will need to co-exist side by side. So, in order to realise productivity, the user needs to be able to manipulate the different info simultaneously in the same CAD 'window'. Separation between 2d and 3d as 'conceptual limit' definitely needs to be overcome.

Ideally, 2d and 3d data should talk to each other thru bi-directional links and propagate changes between them. This is a sticky transaction/propagation centred problem that does not have a clear solution. In the meantime, Bentley should provide the tools for a human to operate effectively in the loop (sort of a human notification / constraints management layer) This requires a reasonable amount of 'granularity' in the way we are forced to store and work with data. The way Mstn/ACAD currently works, files represent impermeable barriers that impede effective working and coordination. We need to be able to combine multiple separately stored files for simultaneous editing. We need to be able to tunnel into grouped elements at the desired nesting level, or relax the grouping constraints at will.

I know that Bentley has looked at granularity before and offers design history and Triforma MCS, but these are repository based tools that do not really address these problems.

In fact, the 'dynamic or 'associative' relationships between data sets will be more important as the amount of information in the system increases. There are many examples of this in the MCAD and plant construction world. MCAD has a long history of using 2d sketches to drive complex 3d models. The prescribed uni-directional BIM workflow where 3d models are sliced up and extracted to produce documentation is deeply flawed. What actually is needed is a bi-directional 'nonlinear' workflow between 2d and 3d. At present, I haven't seen any CAD programme that does this very well. Pro/E has a bi-directional link between the 3d model and 2d extraction where the 'drafter' can modify the 2d dimensions in an extraction and change the associated 3d feature in the modeler's 3d file, but dimension parameters as the sole link is really restrictive. An exception may be Spaceclaim, which bypasses this problem by making 2d extraction really specialised views of the 3d model, much like what Bentley is trying to do with DV/BV.

'Goaline / LOD'

The pain your team is experiencing is a direct result of the flawed approach to and use of 3D advocated by a lot of BIM'ers. I think they call it the "Single Building Model' (SBM). This is associated with the 'draw once in 3d and extract 2d drawings' idea borrowed from the MCAD world. By all means use the 3d model to as a 3d frame for coordination and approximate take-offs etc but why try to cram all the detail in? CAD should also the user to incrementally layer on information and peel it off at will. We need to be able to work like a music composer who starts with a bit of notation (representation of music), testing iteratively it on one or two favourite instruments before hiring the whole orchestra. The way BIM is set up now, you always have to drag the full load around or your extractions will not be detailed enough to work. Painfully stupid.

'Mylar'

Drawing is central to what we do. We use it to develop designs, communicate, coordinate and even sell our designs. It is deeply representational and tries to project a future more 'verbose' or real construct. It will always have a fraction of the information contained in the next stage. I guess, it will always be a 'virtual' reality standing in for the real thing. 3d is valuable as it helps us to model or simulate the behaviour of a future construct in order to anticipate and avoid problems. Generative modelling may even help optimise designs. I think, the changes we are seeing are not the simple evolutionary ‘digitisation'of old analogue work practices. There are many forks in the road, leading to a lot of dead ends and detours.

'Eyes Wide Open'

Don't kid yourself too much. Software development is a messy and expensive business. Even if you are Gehry with Digital Project / CATIA, you are still bounded by what the CAD platform allows you to do. Beware of software vendors telling you how to do your job. Not as if they are particularly golden in their own domain.

'Wait on the sidelines'

Heard this 10 years ago; Heard this 5 years ago; Won't be too surprised if we will still hear this in 5 years. MCAD started trying to convince the industry to move to 3d ages before AEC and still have more seats stuck in 2d. Its coming... but not as we know it?

'Ontologies'

Not really. Ontologies are to do with the way the CS researchers are looking at making intelligent CAD components mimic real work components in a rules based framework.

https://www.posccaesar.org/wiki/ISO15926Primer_History

Bentley's Design++ and Bluethink are also good starting points. IFC development is really way behind ISO 15926, which to be expected given the amount of money the petroleum sector has. Simple illustration would be how a valve component would behave in a CAD environment. Simple implementation would be a 3d object with some hot spots and some attribute data attached. The cad operator would need to ensure that the correct valve is placed properly and is compatible with the connecting pipe etc. But this will require manual checking of the valve's real world characteristics / manufacturer's info (tagged attributes) and other considerations.

A data dictionary / ontology attempts to make the 'meaning' of the valve component 'machine readable'. A framework of production rules would constrain and guide the user as to how the valve can be used i.e. its behaviour.

Also, Safety or code checks can be done algorithmically. Material take-offs, simulation, analysis and rules based generative design would flow from the inherent data. This requires component manufactures to describe in a standardised way the characteristics, function and performance of their products, i.e. 'what' their product 'ís' i.e. their ontology.

It is interesting to note that one area where BIM seems to be paying immediate dividends is structures, especially hot rolled steelwork. I suspect this is due to the reduced and comparative clean nature of the structural information. Steel members are normed, the basic connections are pretty well defined. The node + member framework lends itself to analysis and automated fabrication drawing production etc. Schematically, the close relationship between beam + connection and line + node provides an easy entry to LOD and change propagation. It's no wonder design time can be compressed and overlap with fabrication detailing using a single model, the problems are relatively linear in process and well defined. Cold rolled steel gets messier because of the increased number of members and having to deal with articulated details like openings, where there thousands of possible variations. See AECBytes article on Robertson Ceco for a taste of industrial strengh BIM,and its problems. Precast concrete, MEP etc has their own particular problems as well. From this perspective, the problem becomes more domain knowledge capture and automation (i.e. KBE) rather than purely software adoption, which will be something new for most AEC firms.

I think there is a tendency for BIM advocates point to the success of structural steel and imply that the improvements can be repeated in other disciplines using the same methods and approach. Bentley has a done a lot of work in structures with the upcoming ISM and Openplant may provide the foundation for MEP. Architecture: who knows? GC? Cost based like DP profiler or Trelligence or FM based with Spaceplanner?