-
Notifications
You must be signed in to change notification settings - Fork 15
What Is the BHoM For
Across our industry, regardless of our discipline, we will generally have to work with multiple softwares during the course of any given project. Since there is rarely a simple solution to transfer the data from one software to another, we usually end up either doing it manually each time or writing some bespoke script to automate the transfer. Things get even more complex when we work across disciplines and with other collaborators. When the number of software to deal with becomes more than just a few, this one to one ad-hoc transfer solution quickly becomes intractable.
This is where the BHoM comes in. It provides a single common language between all those 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.
The commercial softwares that we are using in our work do not always provide solutions for 100% of our needs. The bespoke scripts/spreadsheets/programs that we end up creating are rarely shared with more than a few people. This means that the same problem has often been solved by multiple people across the company. Such solutions have often also not been designed with scalability in mind. So, it will rarely be usable for anything but the very specific problem it was meant to solve and will not connect with other bespoke scripts other people might have written.
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. Thanks to the BHoM being exposed in various UIs such as Grasshopper and Excel, you don't even need to know how to write code in C# to use the functionality created by other people. We call this large collection of "scripts" the Engine where we have organised them in a way it is easy to find a specific method or figure out where to create a new one.
If you want to know more about the internal structure of the BHoM:
If you want to start using GitHub and Visual Studio:
-
Introduction to the BHoM:
What is the BHoM for?
Structure of the BHoM
Technical Philosophy of the BHoM -
Getting Started:
Installing the BHoM
Using the BHoM
Submitting an Issue
Getting started for developers -
Use GitHub & Visual Studio:
Using the SCRUM Board
Resolving an Issue
Avoiding Conflicts
Creating a new Repository
Using Visual Studio
Using Visual Studio Code -
Contribute:
The oM
The Engine
The Adapter
The Toolkit
The UI
The Tests -
Guidelines:
Unit convention
Geometry
BHoM_Engine Classes
The IImmutable Interface
Handling Exceptional Events
BHoM Structural Conventions
BHoM View Quality Conventions
Code Versioning
Wiki Style
Coding Style
Null Handling
Code Attributes
Creating Icons
Changelog
Releases and Versioning
Open Sourcing Procedure
Dataset guidelines -
Foundational Interfaces:
IElement Required Extension Methods -
Continuous Integration:
Introduction
Check-PR-Builds
Check-Core
Check-Installer -
Code Compliance:
Compliance -
Further Reading:
FAQ
Structural Adapters
Mongo_Toolkit
Socket_Toolkit