Performance Network

BHoM provides a single common language between applications. Instead of creating translators between every possible pair of software, you just have to write one single link per application to connect to all the others. So, at its core, the BHoM is really straightforward, it contains:

• A collection of object definitions that we all agree on as a collective. Each definition is simply a list of properties that an object should have (e.g. wall, beam, speaker, panel,...). We call that collection the BHoM (Buildings and Habitats object Model).
• A collection of translators to convert objects between the BHoM and the external software. We call those translators Adapters.
• And when the adapter doesn't just send data to and from the external software but also exposes the BHoM within its interface, we then call it UI for user interface. This is the case for example for Grasshopper, Dynamo and Excel.

Through its central object model, the BHoM provides a common platform for everyone to write scripts in a scalable way. A common language means that the output of a script created by one person can easily be used as the input for another script. 

There are 4 categories of code in the BHoM Github repositories:

• oM: Definitions of the data we manipulate (e.g. Beam, Wall, Speaker,…)

• Engine: Our own custom tools, algorithms, data exploration & manipulation.

• Adapters: Connections between the BHoM and engineering tools such as Revit, GSA, Tas, IES,... This is where BHoM objects are translated to and from the proprietary representation used in each of those tools.

• UI: Expose the BHoM functionality through user interfaces such as Grasshopper, Dynamo and Excel.

Toolkits follow the same 4 code categories.

• oM: You could see this as our base specialised vocabulary. It doesn't depend on anything else but everything else will rely on the definitions it contains.

• Engine: Depends only on the oM. Since this is an internal engine, it doesn't have to be aware of any external software or UI.

• Adapters: The adapter will depend on the oM for the objects definitions and on the engine for the conversion methods

• UI: Depends on everything else since it will expose all the functionality above to the UI.

There is also a large collection of code that will be useful in multiple toolkits. All the code that fits that description will be stored in one of the Core repositories. You will find there is one repository for each category of code.