The first one is Nathan Miller of THE PROVING GROUND. He has been working on this development for a while and has made very interesting/useful progress in this development. He primarily focuses on Revit Python scripting to achieve this interoperability. If you are one of those scripting nerds and interested in Revit & Grasshopper link then you must visit Nathan's blog.
 |
| Image courtesy: The Proving Ground Blog |
The second one is Jon Mirtschin of GEOMETRY GYM. I posted about Geometry Gym development in couple of posts this year. Jon focuses on this interoperability issue from open standard file format point of view, IFC. He uses IFC as a 'translator' to send data back and forth between Revit and Grasshopper. While IFC is clearly gaining moment as a preferred BIM file format for data exchange between BIM tools and archiving BIM models, this development is definitely a huge step forward addressing collaborative / open BIM goal. The main advantage of IFC is that you can interact with lot of BIM tools out there such as Revit, Bently Architecture, ArchiCAD, Tekla etc.
 |
| Image courtesy: Geometry Gym Blog |
The third one is Hiroshi Jacobs of CHAMELEON. This one is relatively new to me. I only came across this tool in last couple of weeks when one my colleagues mentioned it to me. By far, I have found this plugin to be the easiest one to use compare to the above tools. Chameleon uses point data from grasshopper definition and places adaptive component straight into Revit project environment and also can change instance parameters of adaptive components. In addition to placing adaptive components it has some useful tools for curtain wall editing, edit parameters via grasshopper, and bring Revit geometry to Grasshopper and clean it etc. Have a look on it's website for full list of tools available for Grasshopper and Revit.
After looking at all these wonderful developments by one man team each, I wonder why on earth big players like Autodesk/Bentley/Nemetschek etc. with their massive R&D budget and team cannot address age old interoperability issues. Surely, It ain't that hard!-;)
Thanks a lot Rahul for the sharing.
ReplyDeleteInteresting blog post, and thanks for the reference.
ReplyDeleteYou've highlighted three successful developments, and of course there are many other developments we'll never hear about either due to in house commercial restrictions or lack of success.
The final comment is an interesting one that can be argued many ways and invoke varied opinions. Is it preferable for Autodesk and others to provide the best possible API and then lever off user efforts to enhance the core product with desired efforts? You highlight three different approaches enabling similar workflows, and this is many ways a testament to the API argument (None would work without a strong API to work with). Grasshopper is emerging also in this fashion, with a quality core product enhanced by third party users.
Is it in the software vendors best interest for interop and model exchange? Import is an obvious one for encouraging more use of your software, export much less so. An independent (or private) effort motivated by real project work flows might very well produce a better result.
And finally, if you have suggestions for making the IFC model creation easier in Grasshopper, I'd love to hear them. I have some ideas of my own, but nothing beats feedback from users.
Cheers, Jon
Thanks Jon for your comments.
ReplyDeleteI agree with you there will be many other developments such as these but we'll never hear about them for the very reasons you mentioned.
I agree with you that this Interoperability issue can be argued in many ways and can have varied opinions. I also agree with you on API argument and quality core product enhanced by users with strong API. In fact I am in full support of this kind of developments so that we can benefit from best of all tools.
However, when I mention 'age old interoperability and Autodesk/Bentley/Nemetscheck' I am mean working seamlessly between those BIM/CAD tools. For instance, we are all aware of the history of DWG and DGN battle and until recently(2008) it was a big issue within AEC industry. In 2008 Autodesk and Bentley announced an agreement to expand their interoperability and shared their DWG/DGN libraries. This was after almost 25 years being in the AEC industry.
Now take BIM, we all know the efforts put in by BuildingSmart(IAI) and other similar organisations in developing open standard file formats to facilitate interoperability between BIM tools. Do you think private users will be able to address this issue, even with the strongest API available? Even so, why should users spend additional money/time to resolve this issue when this should have been FIXED when they purchase any software? Saying this, It would have been a different story if I don't have to spend as much as £6000 (appx) to purchase a BIM tool.
Interoperability between different tools aside, have you ever done round trip (export/import) IFC from Revit or any other BIM tools? I have tried IFC round trip from Revit and been only 50% successful. Now you add another level of complexity to this and export IFC from one BIM tool and import into the other BIM tool. Will it work at this moment in time? Will ArchiCAD exported IFC work in Revit as expected and vice versa? NO? NO? I hear you saying this -;). This is what i am refering to as interoperability and would like to see resolved one day befor i retire.
I should be communicating to you separately on my suggestions for IFC.
R
Hi Rahul,
ReplyDeleteSoftware developers like the major companies you identify should be driven by market demands. Customer/Market pressure is the only way that will encourage model exchange/interop. To date, I would say the pressure has not been sufficient to motivate the developers and override the consequence of permitting intelligent model export (ie loss of use of their tools).
I would not say I have had more success in round tripping models than you have seen (in part for reasons as per above). I would say having developed on the basis of IFC that it is not technical flaws in IFC that prevent this (although I would state there is scope for improvements in IFC to make it easier or more comprehensive).
As an example, my tools (although more specialist or targeted more specifically) only use IFC to serialize, export and import data and I am yet to have users request data/attributes that are not incorporated into IFC (although I am using the new IFC2x4 as it has relevant improvements).
I agree, every user should not have to expend effort and cost to develop interop themselves. This is in part one of the influences of me starting a bespoke software company that can then service many design firms but with an "independent" approach.
In response to your question about whether Archicad exported IFC working in Revit as expected, well I can't promise complete success. But I do have clients using my "advanced" IFC importer doing this with files from Digital Project and the like. And if you pursue this my "software as a service" approach I will do everything I can to quickly address any shortcomings observed on a needs basis.
The issue then is whether you should expect this from a native importer, or have to bear the additional license fees of my software (licensing my developments seems the best way for me to work full time on them). This also relates to my first comment and point above.
As for costs of software, this should relate to market size of users and cost of development (as well as competition alternatives). Actually the cost of wages of staff, computers and offices is more significant and the license fee is a part of this consideration.
If you've other questions, suggestions and points of discussion on IFC, I look forward to hearing them a lot, publicly or privately.
Cheers, Jon