Monday 28 May 2012

Generative Adaptive Component

Adapative components has been one of the common threads amongst those pursuing model transfer from Grasshopper to Revit (refer here).  So not wanting to miss out, I decided to start to start implementing this (an extension of the blog post from Nathan Millers great blog The Proving Ground).

I've enabled generation of the adaptive component itself from Grasshopper (where as to date the others have provided means of locating existing adaptive components).  This model demonstrates that IFC can exchange topology (or connectivity) of elements including vertex and edges of faces, as well as parametric locations (such as position on curve).  Note then that manually editing (or inserting) of the adaptive component, these relationships are retained.



Here's the Grasshopper model, and here's the IFC file.

One of the common criticisms of IFC is that it's a "lowest common denominator" model format, so you can't exchange parametrics or model specific attributes and have to revert to APIs.  This only has to be demonstrated in one circumstance to hold true, but doesn't mean it to be true in all circumstances.  I hope that some of the recent work I've shown demonstrates that IFC is capable of pretty advanced model transfer.  I read an interesting tweet quote from a recent BIM conference that said "If you can't get IFC to work maybe your vendor doesn't want it too", and it is important for software vendors to request and demand improvements to the IFC format for areas they have identified as a short coming.  

One of the IFC short comings I worked around in this example is how to nominate the Adapative Point locations for instance insertion.  I decided at the moment to apply the type (family) to the instance, and use a polyline shape representation to convey the point locations.  Of course a possible desired improvement for IFC might be a more specific description of this type of entity, and I'm sure there are many more that can help make this format be used more successfully.

Friday 18 May 2012

Grasshopper to Vasari (via Revit for the time being)

I've started developing more aspects of conceptual mass family development primarily extruded form.  Others will follow ASAP like blends (http://thebuildingcoder.typepad.com/blog/2009/07/revit-form-creation-api.html is a good reference for forms that can be created from the API and some of the restrictions on the defining geometry).  I'd like to highlight and publicly thank Jeremy for the excellent resource his blog provides, it's been instrumental in me getting my addon up and running.

I also implemented an aggregation of buildings associated to a site as a conceptual family.  This then opens up an easier model transfer to Vasari.  Note I have started trying to implement a revit addon to generate conceptual IFC files directly, but some technical details (ie a crash I am yet to resolve) in initiating the import is preventing thus far.



So, here's the process for the time being.  Bake the IFC file from this Grasshopper definition (or download ifc file here).  Then import the IFC into Revit using the GeomGym addon.  This will create a revit conceptual family in the same folder as the model (or download here).  You can then import this into Vasari and run analysis such as the virtual wind tunnel.

Look forward to hearing suggestions and requests for improvements.

EDIT 21st September 2012  Note now there is a Vasari addon for Beta1 that directly imports IFC files.  Note the above example generates an individual mass family element for each building (there is not means to generate an inplace family object from Revit API).  Here's a Grasshopper file where there is a single site family and here's the resulting IFC file (but this isn't as fast to generate as I might expect so patience will help).

Thursday 10 May 2012

IFC Import Revit - Walls

Todays build (http://www.geometrygym.com/downloads) of the Rhino and Revit plugins includes improvements related to wall model exchange.  This includes creation of families where they are not already loaded.

I initially started with testing the wall path curve as a NURBS (spline) curve, but Revit (2012) doesn't seem to permit spline paths so I used my BullAnt component to approximate it with a polycurve of arcs.

For the moment, the wall path curve has to be on the centroid (I'll look to enable face and offset locations) and I'll have to investigate whether I can enable my nurbs to polycurve routine using openNurbs outside of Rhino.

Look forward to hearing feedback and comments.  Openings are one of the items next on my agenda.  Improvements that come to mind include locking top/bottom to levels and I'm sure users can propose many more.
Grasshopper Model,  IFC File

Tuesday 8 May 2012

GH to Revit, Families & Cardinal Points

I've been implementing many aspects of IFC model data that facilitate the "family" based approach consistent with Revit.

You'll notice many new components for Slabs, Walls, Columns, Beams and framing members to generate a "Type" (equivalent to a family in Revit) and then "standard case" components to generate objects based on that family.

This can include cardinal (or insertion) point locations (such as Top-Mid or bottom right) as this information can be conveyed in IFC4 (make sure you right click on the ssiBake button to enable this).  Here's the example model in the image above.  Plugins should be updated from http://www.geometrygym.com/downloads

If you use IFC2x3 the location of the beams should still be accurate, but a default "mid" insertion point will be used.

Next on the agenda (other than improving and expanding on the above) are aspects such as curtain walls, grids and grid relative locations.  If you've particular requests or suggestions, I look forward to hearing them.