Metal Meshes

A GLASS puzzle is saved as vector data. The finished window needs pane surfaces, metal leading and triangles that can be rendered on the device. I keep those as generated output rather than the thing the author edits.

That distinction carries through the game. The same design can be saved in a puzzle pack, opened in the editor, turned into a thumbnail or rebuilt as a playable window.

The boundary with C++

Godot handles the game and editor. The geometry work lives in a C++ GDExtension, which validates the design and returns meshes Godot can use.

The regions and their leading need different treatment. A pane starts as a two-dimensional polygon that needs triangulating. The leading follows the line network and is constructed and stitched into the surrounding geometry. They share the design, but are not the same meshing problem.

Rebuild the affected regions

Moving one control point can change several regions. Rebuilding the whole window on every movement would do a lot of work that had no effect on the current edit.

The system identifies the affected regions and updates those. Checks and geometry processing run in parallel where possible, including region triangulation. I also spent time on how the data is moved through that work, avoiding large copies that did not contribute to the result.

The C++ boundary gave me control over the geometry work and the data moving through it, separate from the game and editor presentation.

Looking at what the mesh needs

A finished shaded window can conceal unnecessary geometry. I used wireframe views to inspect the leading and the joins between regions.

The aim was to retain the shape and joins that matter in the game while reducing work that did not change the visible result.

Save the design

The output meshes do not need to become another authored asset library. Compact vector puzzles can travel in packs and be reconstructed on the client, including the geometry used for thumbnails. That keeps the source of a puzzle close to the thing its author drew.