Projects > Aurora reDesigned

When I joined Aurora Solar in 2016 their core product was an SVG-based CAD engine used to design and simulate solar installations. I used this engine to develop the first version of the popular “fill zones” feature, a tool that pushed the SVG-based CAD engine to its limits and exposed issues with DOM pollution, real-time interactivity, and graphics fidelity.

Together with my background in OpenGL and WebGL, these issues motivated me to meet with the CEO and suggest that we re-write our CAD engine in WebGL. I believed that switching to a WebGL-based CAD engine could improve:

  • User experience – modeling buildings and solar panels is far more precise and intuitive in 3d than 2d
  • Graphics fidelity – we could render much more than the vector shapes possible with SVG manipulation
  • Real-time graphics – we could render >20,000 panels at 60fps on mediocre hardware
  • Development speed – the SVG-based engine had accumulated years of spaghetti code that made development slow and painful
  • Interactivity – each interactive SVG element had its own mouse handlers causing interaction inconsistencies and performance issues

My idea would spur the largest remake of the company’s product in its history, a nearly two year process that resulted in the release of Aurora reDesigned and Aurora’s entrance into the commercial solar market.

Engine overview

Like the SVG-based CAD engine before it, the new CAD engine runs within a single-page application (SPA) written in the Ember framework. Put simply, it is responsible for

  • Deserializing, visualizing, modifying, and re-serializing >80 types of Ember models (solar panels, buildings, electrical components, etc)
  • Running tasks locally (“fill zones” panel-fitting, NEC validation, etc.)
  • Running tasks remotely (shading ray-tracing, performance simulation, etc.)

Since we wanted to use the new CAD engine for very large commercial solar installations (>20,000 solar panels) on mediocre hardware (older and low-powered laptops) we wanted to keep the engine as lightweight and performant as possible. For this reason, we decided not to use a pre-existing 3d game or physics engine for the web such as Babylon.js or ammo.js and write our own.

Orbiting a large commercial solar installation design in Aurora reDesigned

Other than using three.js for its vector/matrix math libraries and WebGL functionality, the new CAD engine was written from the ground up. Based on Unity’s entity-component system, the new CAD engine uses 4 types of objects (models, components, entities, and engine subsystems) for reasons including:

  • To favor composition over inheritance
  • To encode complex dependencies between models and their attributes
  • To separate state from behavior and achieve better separation of concerns, modularity, and DRYness

Technical Challenges

Re-writing all of the functionality of Aurora’s CAD Engine was very technically challenging. Here are a few of the more technically challenging features I developed:

  • Web Worker manager
    • I developed an engine subsystem to schedule, update, run, cancel, and return results from web worker jobs. The manager ensures that jobs are run with the most up-to-date payloads and cancels redundant jobs. Additionally, the manager ensures that the results of web worker jobs are returned at the correct moment in the engine’s frame loop
  • “Fill zones”
    • I converted my “fill zones” feature to run in a Web Worker on a separate thread, allowing the main thread to run without being blocked. Since the “fill zones” feature uses a rather large irradiance image to avoid placing panels in highly shaded areas, I also used the Transferable interface with an ArrayBuffer to efficiently transfer ownership instead of using structured cloning
  • 3d ruler tool
    • I developed a ruler tool used to intuitively measure distances in a mixed 2d/3d viewport. The ruler conforms to complex roof surfaces, snaps to other objects and rulers, and acts as a snap guide for other objects and rulers
  • Camera animation controller
    • I developed a frame-rate agnostic system for animating the camera and zooming to a point in a mixed 2d/3d viewport
  • Property inspector
    • I developed the property inspector on the right-hand side of the viewport to change properties of selected objects. Written in Ember, this component had to relay updates both from the user to the engine as well as from the engine to the user
  • Street view ruler tool
    • I developed a multi-view geometry tool to estimate 3d pitches and distances from corresponding points in the top-down satellite view and the view from a street view camera

 

Carl Olsson

Engineer, musician, and lifelong learner. Loves building things