Elefront was developed by Ramon van der Heijden and is a plug-in focusing on managing model data and interaction with Rhino objects. The plug-in allows users to bake geometry to the Rhino model with the option of specifying attributes. These attributes include an unlimited amount of user-defined attributes using key-value pairs. This way it is possible to treat a 3D Rhino model as a database. Each object ‘knows’ what it is, what it belongs to, where it should go, what size it is, when it needs to be fabricated, etc. Instead of trying to store geometry in a database, Elefront stores data in a ‘Geometrybase’. Thereby turning your Rhino model into a quasi BIM model or as Ramon refers to it, ‘SoftBIM’.
SoftBIM
SoftBIM was first coined by UN Studio, of which Ramon use to work. In their ACADIA 2012 paper, ‘SoftBIM – An open-ended building information model in design practice‘, the authors proposed an integrative, schematic, and open-ended model for dealing with complex assemblies of geometric and non-geometric project data, aiming to remain non-reliant on specific software packages.
Elefront adopts this methodology by focusing on both geometry and data. By storing all data inside Rhino geometry, Elefront will enable you to split up your Grasshopper process into manageable portions that multiple users can use as input for further Grasshopper development. Moreover, Elefront is ideal for exporting Grasshopper data into Dynamo/Revit. By using it in conjunction with Rhynamo, Rhino objects with embedded intelligence can be transferred seamlessly into Revit. Without initially intending to do so, Elefront has significantly improved the interoperability between Rhino and Revit.
Elefront components
Here are a few useful components that I use regularly:
Bake Objects
Required inputs include: Geometry, attributes, bake name and Boolean toggle to active. One of the cool features of this component is that if a name is specified, all objects that were previously baked with the same name will be automatically deleted once the new objects are created. This setting means that you no longer have to delete previously baked geometry before re-baking them.
Object Attributes
This is used in conjunction with the ‘Bake Objects’ component. Required inputs include name, layer, colour, material, keys and values. Once baked, it will create objects with ‘UserText’ assigned to them.
This Rhino feature is one of the ‘hidden’ commands that often gets overlooked by users. Essentially, UserText will allow you to create custom parameters for objects which aren’t visible in the properties pallet. Therefore, beyond just specifying the name of the object and its display colour, etc., we can create custom parameters just like in Revit. For example, if we had a panelised surface, we could create a ‘Mark’ key (parameter) and define its value. There is no limit to the number of keys/values that can be applied to elements. We can therefore build-up as much information as desired.
However, it is important to note that when baking an object, it can only have one set of Elefront attributes. Also, Elefront attributes can only be assigned to Rhino objects that have been baked from Grasshopper. It is not possible to assign attributes to a Grasshopper element and use those attributes without baking them. This limitation means that parallel data structures (geometry and data) will need to be maintained throughout your Grasshopper script until they are ready to be baked.
To access UserText values once elements have been baked, you can use the ‘GetUserText‘ in the Rhino command line. If you select ‘All keys’, Rhino will return all the user attributes for that element. To clear an object’s UserText once it has already been created, use the ‘SetUserText‘ command in Rhino and enter “” (double quotation marks).
Get User Attributes & Get User Values
One of the powerful advantages of Elefront is the ability to bake objects into Rhino and then reference them back into Grasshopper. When doing this, you will need to perform a solution recompute (F5) before Elefront can read the baked Rhino geometry.
Data Description
This component will help you organise your grasshopper definitions. By setting a description, it will automatically be updated downstream if modified.
Reference Block by Name
This is a powerful component and works similarly to some of the other Grasshopper plug-ins like Human and Horster. For example, you may have some residential apartments that have been manually modelled. If these are turned into a Rhino block and named accordingly such as ‘1 Bed’, ‘2 Bed’, etc., we can use this component to reference in only the blocks we need. Additionally, the blocks contain any associated data in the form of user attributes we can use the ‘Filter by User Attributes’ components to narrow down our selection.
The example below shows a series of predefined apartment layouts that have been analysed with Ladybug for SEPP65 solar compliance. The results were then embedded into the rhino block. Using this component, we can reference into our Grasshopper script from our library only those 1-bed apartments that comply with SEPP65 solar access at a given rotation.
