I’m excited to share a project I’ve been working on for a while now.
Like many of you, this started years ago with a simple Grasshopper script - deconstruct Brep, sort the bottom surface, collect the area. And probably like you, over the years I kept trying to automate more and more of that workflow in Grasshopper. Two fundamental issues kept emerging though.
The first is that Grasshopper actually isn’t that great at this task in early design, when layers are adding and dropping constantly and a meaningful amount of your attention shifts to maintaining the script rather than the design. The second is reach: unless your office is Grasshopper heavy, maybe 4 other people can actually use what you’ve built.
There are also plenty of standalone tools out there with sophisticated massing analysis and data schemas, but they come with the same core challenge: they exist outside your standard software pipeline, which means another model to maintain, another file to keep in sync, and another context switch mid-design.
Areo lives inside Rhino. It captures Brep areas on layers and categorizes them via the layer table, so your Rhino model is the model. Breps can be sorted into sites, filtered by selection, and custom metrics can be applied for early-stage planning. No separate file, no re-importing geometry.
There’s a fine line between simple-yet-powerful feedback at an early design stage and complex data management that starts pulling your attention away from the design itself. Areo tries to stay on the right side of that line — useful enough to change how you work, light enough that you forget it’s there.
I’d love to hear from anyone who gives it a try. Feedback on the features and the UX/UI, this is early days and the people most likely to have useful opinions are in this community.
Shout out to Milos Dimcic for teaching me C# through his YouTube channel, and @mrhe for showing us there’s a world of custom UIs using Eto.Forms and beyond!
