Reflected Ceilings in 3D model

Re: Reflected Ceilings in 3D model

Eric Milberger — Fri, 21 May 2010 20:40:07 GMT

We need a rael grid tool and fixture, grills, etc that are pcs file that cut through a ceiling or any other frame.

And then probably some lock that prevents them from cutting through the grid.

Re: Reflected Ceilings in 3D model

Damon Aspden — Tue, 11 May 2010 10:10:43 GMT

Just a guess, but maybe Bentley MEP can handle these things? I havnt used MEP, and havnt even looked at it.

Maybe they have a tool there that can do the penetrations automatically?

Would be nice to have a ceiling tool for sure to use in 3d.

Re: Reflected Ceilings in 3D model

Brian Yeo — Wed, 05 May 2010 22:37:26 GMT

OK so getting clg "slabs" in place isn't that complicated once you grasp that this clg tool is actually just redirecting you to use the floor slabs tool (you just have to switch your brain to think backward for this task). But enough of that and on to the next headache related to the shortcomings inherent in this "stopgap" programming solution. I'll try not to simply vent my frustration but rather provide some constructive criticism (reiteration?) for how the clg tools, which are pretty important to the whole BIM collaboration process, might want to get some attention from the developers. Others have already pointed out, but I'll repeat, that by these slabs having no association w/ the clg grid patterns means that when items such as light fixtures or HVAC diffusers protrude from the plenums to perforate the clg plane the clg grid, which is basically just dumb linework, just goes crashing right through these items so one must then manually snip each of these indiv lines to clean up this graphics coord problem. which otherwise leaves the resulting refl clg plans from being confusing. Another important problem hopefully which can be addressed at the next release is that the hovering slab portion of the clg, not being intelligent enough to understand that it's a clg entity, cannot then auto-cut itself and auto-heal itself as these various objects protruding down from the plenum proceed to penetrate through it. And I'm assuming that, but have not yet attempted to confirm, that were I to use the very fine and very efficient boolean tools to quickly cut all these various holes then these slabs would demote to even less intelligent forms. So now here I am at the routine clash detection task again after having previously added the missing clg slabs and I'm reminded that not only do these clashes impact how the clg plans appear graphically but I'm reminded that these clashes are also a headache that we should not have to deal with at this clash detection task. Dealing with each of these intersecting items at this clash detection task consumes a significant number of man hours.

Assuming as I am that we should avoid using the boolean functions on intelligent items (hopefully another issue which will be corrected soon too BTW) what is the methd for automating these perforations. Should I be communicating to our engineering consultants that they should be usingdifferent "out-of-the-box" Bentley items than the ones they are using? Or is the fact that the arch clgs are in one dgn file while the various MEP items are in different dgn files at the root of this issue?

Re: Reflected Ceilings in 3D model

Eric Milberger — Mon, 26 Apr 2010 21:25:23 GMT

I dind it generates the ceiling "slab" fine. And to assemble multible players use the "assemble" tool

the issue I have it it does not gernerate the ceilign plans automatically as it should.

Forward and Reverse attributes need to separated

A "Marker" need to be defined to be the starting point of a grid,

And if there is a plenum. the Centerline tool needs to be corrected to provide the support for the grid

THIS SHOULD BE AUTOMATIC

Re: Reflected Ceilings in 3D model

Brian Yeo — Fri, 23 Apr 2010 19:33:30 GMT

I'd like to reawaken this ceilings construction thread with the Bentley folks. We're on to another project and, again, find ourselves struggling to understand I think the basic Bentley concepts behind the construction of the ceilings. This project is another BAXM one but I've poked arounf in v8i a little now and it looks like the clg tools may not have evolved to their next generation yet but please correct me if that is wrong as that will help me make the mental XM->v8i transition. I'm jumping into this project in its latter stages of design and notice that the clg slab forms have not yet been generated. What our users have been doing is simply keep turning off layers of data inside the plenum to produce the rcp extractions for annotation and that works OK most of the time. But sometimes this method is simply not sufficient so I'm attempting to create these forms now for those instances. The help page for this tool is, unfortunately, not helping me understand the process expected of me and perhaps explains to me why our users have abandoned it up to now. I'll deal with the step-by-step instructions in a tech support call but I'd also like to re-activate the discussion about how this tool might want to evolve as the BA software moves forward. I hate to compare the Bentley software to competing products in these forums but in this case I don't know how else to approach it. Sorry in advance to Bentley for that indescretion.

Our users bounce back & forth between RevitArch & BentleyArch dependant on the indiv project req's and so do I. I notice that the BA conceptual approach to clgs is dramatically different that that of RA. In the Revit environment the clg form and the clg grid patterning are integrated into the same physical 3D construction much like the actual physical built clg entitie would be. To accomplish this the grid (or other) patterns are applied to the bottom face of the clg form as a bitmap image and they've some tools to control the origin of the patterning just as one does with straight 2D crosshatch patterning. What this approach allows is that items such as light fixtures or HVAC ducts which penetrate the clg can then auto-communicate to the patterning that holes in it are occuring. Surely there may be some disadvantages to this approach compared to the BA approach of treating the grid (or other) patterning as separate 2D linework disassociated from the solid hovering slightly above it but I cannot at first glance imagine what that may be. My conclusion (perhaps prematurely, perhaps not, not sure yet) is that this conceptual leap should be one of the areas targeted by the BA developers for future releases of BA. I think this mindset applies not only to clgs but also brick (and other) coursing patterns at elevational projections and tile (and other) patterns at flooring areas in plan projections. Might this evolution be on the horizon for BA (and if so, then when?) or is there some deep conceptual reason why it might not be which I'm simply neglecting to see?

Re: Reflected Ceilings in 3D model

Damon Aspden — Tue, 25 Aug 2009 05:58:20 GMT

Yeo. You say that the ceiling grid is transparent when calculating the RCP?

I do not get this when I am doing my ceilings. I place a shape at the height of my ceiling and then use the Place ceiling tool to make the grids inside the model. Then this shape will block out all my plenum space. It does however create problems with my light fittings and stuff but I now end up doing that in my 2d sheet file now instead of in the 3d model.

Mind you, I also am not using spaces yet in my models. hmm something I need to adress.

In fact in the latest project I am just referencing in the 2d DWG files sent from the elec engineers who of course are doing 2d only.

Re: Reflected Ceilings in 3D model

Damon Aspden — Tue, 25 Aug 2009 05:06:09 GMT

Another interesting thing to point out too is the timeline of new products that Bentley released in teh AEC areas.

I will start at Triforma as this is the first 3d program I used.

First Was Triforma, Next came Structures for Triforma , Next came HVAC for Triforma. and then after alot of politicing by some people, Architecture for Triforma was created.

Interestingly I remember the first version quite well as I was a user of Triforma. And when Architecture for triforma came out I never migrated to it as all it did was repackage all the Baseline Triforma tools into a diferent looking toolset. Nothing actually was changed in the actual programming from base Triforma to Architecture for Triforma. That came out in later versions. ie. ceiling tools, Terrain tools, separate tools for placing windows, doors, plumbing items and furniture.

Architecture definately seems of the lowest priority of the Bentley AEC systems. But in saying that it probably should be as it is a very fluid and dynamic part of the AEC industry there are not many constants which the other feilds definately have.

As Seah points out. hopefuly the work done in the MCAD, Structures and MEP areas will be develpoed back into the Architecture arena.

One hopes that this will be next on the agenda after the next version of Microstation, which I believe is currently in Release Candidate mode. One hopes.

Re: Reflected Ceilings in 3D model

dominic Seah — Tue, 25 Aug 2009 04:26:13 GMT

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?

Re: Reflected Ceilings in 3D model

Brian Yeo — Fri, 21 Aug 2009 19:45:53 GMT

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.

Re: Reflected Ceilings in 3D model

Eric Milberger — Thu, 20 Aug 2009 07:18:21 GMT

I am doing everything with BV's

And I don't beleive BV's pattern elevations.

Re: Reflected Ceilings in 3D model

Damon Aspden — Thu, 20 Aug 2009 01:58:15 GMT

emilberger:

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

Eric. Did you not get the paterning to elevations script working? Or does it just not work?

Re: Reflected Ceilings in 3D model

Eric Milberger — Mon, 17 Aug 2009 05:03:34 GMT

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

Re: Reflected Ceilings in 3D model

dominic Seah — Sat, 15 Aug 2009 18:50:44 GMT

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.

Re: Reflected Ceilings in 3D model

Brian Yeo — Fri, 14 Aug 2009 23:07:03 GMT

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.

Re: Reflected Ceilings in 3D model

Eric Milberger — Thu, 13 Aug 2009 09:44:57 GMT

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.

Re: Reflected Ceilings in 3D model

Damon Aspden — Wed, 12 Aug 2009 01:58:06 GMT

hmm.. It seems lately that bentley will wait for someone else to make the tool as a 3d party app before they aquisition it and make it part of BA..

Cmon u MS gurus do your thing..

Re: Reflected Ceilings in 3D model

Brian Yeo — Mon, 10 Aug 2009 19:54:50 GMT

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.

Re: Reflected Ceilings in 3D model

Damon Aspden — Mon, 10 Aug 2009 06:49:44 GMT

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.

Re: Reflected Ceilings in 3D model

Eric Milberger — Fri, 07 Aug 2009 00:42:29 GMT

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?????

Re: Reflected Ceilings in 3D model

JordanH — Thu, 06 Aug 2009 20:32:21 GMT

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

Re: Reflected Ceilings in 3D model

Steve Stevens — Thu, 06 Aug 2009 18:40:11 GMT

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

Re: Reflected Ceilings in 3D model

Damon Aspden — Thu, 06 Aug 2009 07:33:02 GMT

Definately needs a revamp.

I remember my last position when I was using ADT2009. When I placed a grid it was 3d.
When I go to place 3d light cells (or others) I could snap to the center, or to each node to the sides of each grid cell

Much better tool to use.

Bentley can u please try to emulate if you can.

Re: Reflected Ceilings in 3D model

Eric Milberger — Tue, 04 Aug 2009 23:31:21 GMT

I suggest the tool be modified.

It should create it's boundry at the height you select.

Then it should use assemblies to create ceiling. Spaces should be something different.

PLUS we need more than one way to create the ceiling. By fill is not enough when you ahve an odd shape

Re: Reflected Ceilings in 3D model

Donovan — Tue, 04 Aug 2009 21:41:29 GMT

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.

Re: Reflected Ceilings in 3D model

Eric Milberger — Tue, 21 Apr 2009 10:04:48 GMT

If you could just place a volume with a transparent fill - the column could be from the ceiling to the deck if rectangular.

Right now I have a line style that draws the grid in my sections then creates a shape that is transparent to disquise the plenum.

If we can get odd shaped volumns from a ceiling to the deck then spaces could be the answer