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

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

I have struggled with this for a while. Presently, I just place ceiling forms for the ceilings and avoid the grid. I am a contractor so extractions don't mean anything to me but geometry for interference detection does. So would the steps be...

1. Place grid, extrude to form, create ceiling form, boolean for tiles (Ceiling Tile Forms Lost)

2. Place grid, extrude to form, fill each gap with ceiling form

3. Place grid, extrude to form, array single form for the full sized tiles and clean up the edges with option 1 or 2?

None of these seem like great options, is there another way?

Thanks,

Jordan

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.

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.

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.