Interesting agenda listing the top ten reasons using Aecosim, for a webinar next week. Always good to know what Bentley think it does well or best.
Also insightful are some of the project-based 'show and tells' that organisations like CITA do. Noticed this fairly recent vid on the Trinity Business School in Dublin, Ireland. Presentations were given by the architect, engineers and the contractor's BIM managers.
I particularly like the one given the contractor's BIM manager. Particularly upfront about the problems.
Architects (STW)
1. Point cloud in parallel to CAD geometry. Need to be able to look at two different info sources to verify or interprete the situation, which seems to be a reoccurring theme. Aecosim should be able to shine here with its reality mesh, point cloud, STM referencing tools.
2. BIM efficiencies: Simple things like automation of printing drawings are important for profitability and programme.. Aecosim should brush up on its Sheet Index, Print Organiser tools. Dynamo probably still has the upper hand here as it beats GC when it comes to accessing DGS and other ABD data structures.
3. Clash detection: limited benefits during design phase due to speed of changes. Aecosim should still have an advantage due to its ability to reference far more formats that Revit without having to 'clean' them up first. Actually, referencing is still much easier in Aecosim compared to Revit's model linking.
4. Modelers need to have construction knowledge.
5. Purpose of the model: needs to be commensurate to fee and programme. Minimum info efficient. 2d drawn information is still assumed to be less costly. Easier to have one drawing for a skirting (presumably with some wording in a spec or finishes schedule) than to model everywhere. This is where Aecosim's Hypermodeling should be able to shine. The problem is most jobs are still using DEM. More tools to link to external text docs or schedules. F+P Components, DGS spec and classification info. Bentley Facilities and Spaces tools to be honed?
6. Costing from the model: naming of elements to allow quantification. The downloaded object may not be what is specified or costed. Rolls Royce doors in model may in fact be Fiat Puntos. Revit's is known for being very database-like which would be good for costing. Its QTO tool is also pretty good. A lot of 3rd party tools. You could argue that Aecosim's DGS is a bit more flexible compared to Revit's Shared parameters. The new Edit-in-Excel mode is also a big equaliser. GC update 3 has introduced database links. SQLite under-exploited?
7. Contractor should be building from drawings... contradicts Contractor's wish for 'for construction' models. See below. Again, this is where Aecosim's Hypermodeling and interop muscle should come in handy. The point is that the 3d model still needs to be read in conjunction with 2d info. It would be good to be able to convert Revit's Sheet Views and insert them Hypermodeling-style in the i.model that the Revit plugin exports.
8. BIM not in contract! MEP contract out of synch with main contract, and design programme. LOI, LOMD, LOD still ambigous... not surprising. Old fashioned project management mistakes will still trip up BIM.
9. Phased model release... difficulty differentiating 'for reals' info from preliminary info. Info is always in flux. Yeah, Aecosim could benefit from iModel 2.0 tech. Always had Triforma date stamp, Design History, ISM etc. Revit having everything in one model is more susceptible to overproviding info, compared to Aecosim's Ref file based working.
10. Subcontractor submission: easier to check steel subbie's 3d model.. for clashes... for an architects nonexpert eye, of course. Again, ad hoc access to DWG, IFC is much easier in Aecosim. No need for intermediate apps / workflows using Navis. Reacting to changes or clashes much easier as you can reference the Navis model directly from your authoring app. Revit has started providing Navis linking support, but is still clunky.
11. Checking 3d mode against drawings... still important. Ditto on Hypermodeling.
Engineers (Arup)
a. Working in an existing building fabric, means working with point clouds and documentation of what needs to be demolished. Upfont cost and programme. Again, Aecosim/Mstn is much better with reality meshes, PC etc. Surveyors predominantly use DWG-based apps. Phidias Phocad as companion app?
b. This includes below ground civils, means using dwg-based Civils3D. No mention of the lack of interoperaility between Revit and anything DWG-based. Again, Aecosim/Mstn is much better with civils info where R'vit is not widespread. Georeferencing built in. Lots of municipalities use Bentley apps for road/drainage/utilities etc design. ABD installer should offer to install appropriate object enabler. One killer Aecosim tool is the Slope Thematic Display Style.
c. Structural engineers needed to provide quite detailed structural information on the existing structural members. Again, legacy info will be more likely to be in DWG or scan formats. It would be great if Bentley could add vector pdf to the list of formats it can reference. Descartes companion provides inclusion of photos as camera objects in 3d model.imodels should provide streaming access for viewing and commenting on site. Issue resolution service. Hypermodeling provides AR type viewing.
d. Below ground utilities, is a huge problem that requires real time survey (DWG again) information - need to switch to Navis to coordinate. More likely to have common modeling environment in Aecosim. No need for repeated conversions. Hypermodeling AR-type viewing. See YII presentation highlighting the advantages of single platform for dealing with below ground earthworks design which has to continually react to unforseen conditions and site usage and planning.
e. 'Key to a tool like Revit is understanding the LOD to be included' - sounds like Revit scalability problems. Still reliant on the 2d drawing information for conveying detailed information. Aecosim should be much better at handling large models. Hypermodeling.
f. Visualisation: soft factor that helps with things like temporary works stability problem identification and visualisation. Also helps the contractor to hit the ground quicker. Revit has Enscape as addon. LumenRT might not be as slick, but it is part of the Aecosim package.
g.Typical/standard details: detail provided for a typical detail for things that will repeat. Again Revit scalability limitations?. Again, Aecosim should be much better at handling large models. Hypermodeling Ref files should pave the way for less detailed models to be swapped for high detail models on demand. BV's 2d Symbols or view dependent cell tech could be enhanced.
h. Some trades / packages still do not benefit from a BIM model (piling). Yup. USACE BIM deliverables does not require 3d for everything, which recognises this fact. Topcon integration etc?
i. Proliferation of formats that need to be provided: more information- dwg, pdf, ifc, nwc,nwd, dwxf. Aecosim/Mstn should handle this much better. PW automation services lite? Batch conversion should be extended to deal with more formats, not just DWG/DGN. See the need mentioned above to make sure of little productivity bright spots do add up.
j. Substitution of products will create coordination problems. This is something that has been long anticipated by AIA E202 MPS and other protocols. It looks like contractors will need to build up their BIM 'drawing offices' to manage the post tender updating of the BIM model post tender.
k. Need for parametric tools increased due to need to react to changes during the design process. This is a wake-up call for those Aecosim users who has been traditionally averse to 'fly-by-wire'. Revit/Dynamo still ahead here but Aecosim/GC is catching up. Aecosim due to its CAD origins has always been better at modelling / snapping in 3d. Short chain associative tools like Prostructures Associative Planes and Intersections can be game changers. CE's MCAD style constraints-based Functional Components should be much easier and flexible compared to Revit Family Editor.
l. Model as single source of truth will also need to host things like RFI's, progress reporting, health and safety. Maybe Navigator and Structural Synchronizer could be enhanced to provide PW-lite sevices to medium sized projects.The new Issues Resolution tool could also be used as a platform to host RFIs in the 3d model. Constructsim as companion app to aecosim?
Contractor (JJ Rhatigan)
a. Coordination still a big thing for contractors. Read CDE and clash detection. See above.
b. MEP schematic model separated into Mech and Electrical models. I suspect that this common due to lack of big 'Tier 1' MEP contractors for the size of job. ABD/AES as a combo should have some advantages here. Hevacomp? It would be good to get the installer to install the Autocad MEP etc object enablers when ABD/AES are installed.
c. Number of 'ad hoc' or contractor-specific models for 3d room tags, crane / temporary works, syphonic drainage that would be done by the contractor's 'drawing office'. Lot's of apps that serve these kind of design are based on DWG.
d. Soft factor: 3d model helps clarify and explaining the design. Free LumenRT
e. Consistency of drawings derived from the 3d model. Contradicts the amount of 'embellishment' that Aecosim jobs typically have. Uh oh... Drawing rules should in theory prevent this, but even with MEP, lots of 'custodial' clean up work is needed.
On the structural front, a lot of the embellishment could be avoided by better integration of Prostructures for steel and concrete detailing. Microtrans for connection design? The detailed connection for example would be modelled in PS, and the 2d results added to the aecosim BV drawing via Drawing Rules?
f. Elements like fire barriers that are in the 2d drawings and not in the 3d model. This is typical for all BIM apps including R'vt, which will contain a lot of detail in 2d views. See also the engineer's comment on not over doing LOD. Aecosim whould have the scalability advantage here. Hypermodeling. Use Drawing Rules to thematically colour the fire rated walls. Copy walls through to temporary work model. Convert wall to fire batt as profile...associatively linked to wall(?).. copy back into original model.
g. Contractor's Information Requirements: this will be contentious and I suppose should be implemented via an industry-wide body like buildingSmart using MVD's. iModel 2.0 could help here? I think that Igor or Bentley is on the DT MVD committee?
h. Models still only for information. Schematic models like MEP are accepted as something that will need to be developed further. It seems that the arch and structural models are still subject to lots of changes post tender.. typical RFI stuff that leads to 'missing' information or corrections that will need to be incorporated into the model. But, post tender the contractor 'owns' the model and has probably modified and added to it. How would the changes be incorporated? Doesn't sound like Glue etc supports the kind of multi-party 'federated-worksharing' needed. iModel 2.0 could help here? Drilling down into the process, the changes will need to costed quickly, meaning tracking lots of add and omits; and the change scrutinized by the MEP team on a granular case by case, duct by duct basis. Sound familiar?
i. 'For information' models are technically not supposed to be used on site. This creates a info gap in the process... and illustrates why 2d info tends to be relied on for 'for construction' info. Human interpretation is still required to 'fill in the blanks'. There is a keen desire to be able to 'trust' the 3d model. I think that this over-emphasis on the 3d model is to be expected. But, it also highlights the contradiction. The BIM model provides more comprehensive info compared to 2d or textual info, but for the the infomation to be 'trust'-worthy it has to be checked and the assuarance process is still very much a 2d, manual and human affair :-). You can pretty much be sure the design has not been 'checked' if there were no 2d drawings produced. 2d info is also still needed to fill in as it is not possible to stuff the 3d model with everything. Hypermodeling, PW Component Indexing?
Hi Steve,
Yes, scale or zoom level-dependent LOD would be great. See MicroGDS which is apparently pretty good at this.
But, before we go there, there needs to be a basic means to intelligently select (and define) the amount of detail in a object.
1. It probably needs to start with at the element level- it would be great if the element could have a 'LOD' property.
2. At the Cell level: C-Cells are already half-way there.
3. For linear elements like Walls and Beams... or Ducts... Drawing Rules are probably the way to go? There is already Rules to convert ducts and structural columns and beams to single/double line representation. In would be good to extend this to Walls . Linear C-Cells would also be good for things like railings and curtain walls, even ceilings. It should also provide the means to provide more flexibility to what the lower (or higher) LOD representation would look like. No bolts / connections? No embedments?
4. For planar or surface elements... something that is based on Geometry Maps would probably be required. Mstn SS4 already dynamically mods the hatches to suit the Annotation Scale.
5. At the file level, you can already just swap the files quite easily. For low LOD, you could attach an Aecosim model for the concrete frame; for high LOD, you could swap that for one generated in Proconcrete (or a more detailed Aecosim model) for example. The problem is intelligently dealing with the 'duplicate' detail. It would be essential in a production environment to be able to filter out a 'duplicate' low LOD element when the higher LOD element is referenced and vice versa. In the vid above, PS seems to be able to recognise and link to elements in Aecosim, presumably using ElementID's or some other GUID-type mechanism. A Drawing Rule to implement this would be great.
What happens vs what should happen when the user Activates the higher/lower LOD model is a topic for another day...
Hi Dominic,
For this one:
Are you imagining the drawing scale and/or zoom level to control whether the symbol is detailed or coarse? We do have an Enhancement (or two) filed for this type of functionality, I just wanted to check whether you had any other ideas floating around...
First of all, I would like to give you thanks for the detailed feedback about current AECOsim capabilities and also about what we can improve in the product to be better in the future.
Regarding some of the points you mention, I recommend you to take a look at the next examples regarding
- Scan to BIM (How to use reality meshes in AECOsim) Tech Talk showing how to Integrate your reality mesh with AECOsim
This tech talk by my colleague Kurt Rasmussen explains how to use the reality meshs to create BIM Objects
- Use of parametric objects with AECOsim CONNECT
AECOsim create and add Parametric Cell to the Datagroup Catalog
How to create a parametric object using AECOsim Building Designer
These two examples explain how in AECOsim CONNECT we have made most simple the creation of user custom parametric objects.
Anyway, I hope you receive more feedback, as this is a very interesting starting point for a discussion.
Thanks again,
Eduardo