GlazingCalc

Calculate, visualize, and compare facade glazing options.

Comment

One-line summary

GlazingCalc is an interactive glazing specification tool that helps facade teams build custom glazing systems, calculate optical and thermal performance, compare product options, and visualize facade appearance early enough for design decisions.

Inspiration

I am an experienced building simulation engineer. Over years of project work, I repeatedly saw the same frustration: glazing specification is usually decided and communicated through fragmented information.

Facade designers and engineers often select glass mainly from thermal performance, solar control and cost. Those values matter, but they do not fully describe how a building will look. A glazing option with a good g-value or SHGC can still be darker than expected, more reflective than the architect intended, or visually different once it is installed over a large facade.

Clients and developers, on the other hand, care deeply about the appearance of the completed building. They want to know whether the facade will feel transparent, dark, reflective, green, blue, neutral, premium, or closed. But they are often not given enough visual evidence at the right stage. The result is a painful late discovery: the glass is installed, the project is technically compliant, but the facade looks too dark, too reflective, or simply different from what the client imagined.

The real issue is not only performance or cost. It is the trade-off between performance, cost, daylight, comfort, reflectance, color, procurement and architectural appearance. That trade-off is still not well understood across all stakeholders.

Market Research: Current Tools and the Gap

The most comparable tools in the market are specialist optical and thermal glazing calculation tools such as LBNL WINDOW, Optics and THERM, and commercial or specialist tools such as WINSLT, Flixo and WINISO. These tools are technically strong and are based on mature calculation methods, but they are generally built for expert users rather than fast, visual and collaborative option comparison. The issue is not that the industry lacks calculation physics. The issue is that performance calculation is still difficult to turn into a clear design conversation.

Manufacturer tools such as Guardian Glass Analytics and Performance Calculator, Saint-Gobain Calumen, AGC Glass Configurator, Vitro Construct, Pilkington Spectrum and Sisecam GlassTool make product selection easier and often provide polished reports or visual comparison features. However, they are usually tied to each manufacturer's product portfolio, and their visualizers tend to show selected supported products, fixed scenes or database-backed illustrations rather than real-time appearance for every custom glazing build-up. This leaves a gap for a neutral tool that connects custom glazing build-up, performance values, product comparison and realistic appearance in one workflow.

What I Built

GlazingCalc is a web-based prototype for early-stage glazing option exploration.

It lets a user assemble a custom glazing build-up from layers such as glass, coatings, cavities and interlayers. The interface validates whether the build-up is physically meaningful, then sends it to a Python backend for optical and thermal calculation.

The tool does more than return a table of numbers. It also supports:

  • Interactive drag-and-drop glazing build-up configuration.
  • Calculation of optical and thermal properties for custom assemblies.
  • Spectral data output for transmission and reflection.
  • Angular optical data for facade visualization.
  • A scatter plot for comparing candidate glazing systems.
  • Visual comparison of facade appearance under different lighting and viewing conditions.
  • Precomputed static assets for faster deployed performance.
  • A deployment-ready demo workflow for Vercel.

The current prototype uses a Flask backend and a browser front end. The calculation workflow builds equivalent panes and cavities, then evaluates the glazing assembly. The visualizer uses a WebGL2 compositor that applies live glazing optical properties to pre-rendered scene-linear facade passes, so the image can respond quickly when the user changes the glazing.

This makes the project more than a manufacturer-style calculator. It is a step toward a shared glazing decision interface: one place where the client, architect, facade engineer and building performance engineer can see both numbers and appearance.

How I Built It With Codex

I already had the calculation method from previous work and had created backend calculation functions. My missing piece was software product development: how to package that calculation into something usable, intuitive and presentable.

Codex helped me turn the engineering logic into a working web application. It helped mock up the front end, especially the glazing build-up configuration section. We tested several layout options to find a more intuitive way for users to assemble custom glazing systems without needing to understand every internal calculation detail.

Codex also helped structure the frontend state, build the performance comparison workflow, connect the backend APIs, prepare static assets, document the calculation rules, and give detailed deployment instructions for Vercel. That changed the project from a technical calculation script into a presentable demo that other people can understand.

What I Learned

Codex can be a very useful tool for filling the missing software engineering pieces needed to complete a product.

I brought the domain knowledge. I understand the market gap, the stakeholder frustration, the glazing performance terminology and the practical decisions that happen on real facade projects. Codex acted like a software engineering and product development partner. Together, I defined the scope and direction, and Codex helped execute the missing implementation steps.

I also learned that using Codex well is an iterative process. The first instruction is rarely perfect. The best results came from describing the intended user workflow, reviewing the mock-up, identifying what felt wrong, and then asking Codex to revise the interface or implementation.

Challenges

The biggest challenge was my lack of formal software engineering experience. I knew what the tool needed to achieve, but I did not always know the best way to describe the implementation. Translating a domain problem into clear product requirements took practice.

The second challenge was UI design. A glazing build-up is simple to an engineer but not simple to a new user. The interface had to support glass layers, coatings, interlayers, cavities, validation errors and calculation results without becoming confusing. That required testing multiple layouts and iterating toward a more intuitive workflow.

The third challenge was appearance. Physically meaningful glazing visualization is difficult because glass appearance depends on spectral transmission, front and back reflection, viewing angle, sun and sky conditions, interior brightness, facade geometry, tone mapping and display behavior. A small indoor A4 sample cannot reliably communicate all of that. Building even a prototype of real-time spectral facade appearance required separating scene rendering from glazing optics.

The final challenge was deployment. A local engineering prototype can be slow and fragile. A public demo needs precomputed data, static assets, clear APIs, and predictable performance. Codex helped reorganize the project so it could be deployed and shared.

Why This Project Matters

Glazing decisions are expensive, visible and hard to reverse. A wrong choice can affect energy performance, daylight, glare, comfort, procurement and the public identity of a building.

Current workflows often make each stakeholder look at only part of the problem. Engineers see performance tables. Architects see renderings. Clients see samples. Contractors see cost and availability. Manufacturers see their own product range. The exact glazing decision gets passed between these views, and information is lost each time.

GlazingCalc is an attempt to make those trade-offs visible in one place. It helps stakeholders understand not just whether a glazing option performs, but how it may look and what compromises it creates.

Next Steps

The next development steps would be:

  • Expand the product database across more manufacturers.
  • Add a controlled "glazing passport" for each option, including build-up, performance, visual evidence, calculation provenance and approval status.
  • Add cost, availability and manufacturing constraints.
  • Support more project scenes, orientations and weather conditions.
  • Add clearer option comparison functions so users can compare multiple build-up options, their performance values and their visuals side by side.

Sources Reviewed

Built With

Share this project:

Updates