Invector

Inspiration

Most real-time destruction systems choose one of a few compromises: blocky voxels, pre-fractured props, temporary decals, or one-off mesh tricks. Those approaches work for many games, but they do not give developers a smooth surface that can also be crawled on, deformed, grappled to, cut repeatedly, replayed deterministically, and eventually saved as part of a procedural world.

I built Invector to explore that engine problem in the most demanding visual setting I could think of: living biological surfaces. If the architecture can keep a wet, curved, moving tissue wall coherent while a player draws a cut across it, it can transfer to terrain sculpting, creature damage, tunnels, soft architecture, and other editable implicit worlds.

What it does

Invector is a Rust/Bevy engine prototype and verification harness for deterministic, editable SDF worlds.

The main demonstrator lets the user hold RMB and draw a curved cut directly over a smooth tissue surface. The mouse wheel changes the kerf width. One held gesture removes exactly one shallow 0.40-unit layer, even when the path overlaps itself. Releasing and making a fresh gesture can shave another layer from the newly exposed surface. Deliberate holes and discontinuities remain separate rather than being bridged.

Under the presentation, the gesture is compiled into a canonical quantized SweptCutPass. The field update, dirty-chunk selection, material classification, Surface Nets extraction, mesh validation, and render installation are tracked with explicit command IDs and epochs. A responsive pale head and dark wet groove appear immediately, but they are presentation only. They retire when exact authoritative command, epoch, and dirty-chunk coverage arrives.

The repository also contains generated biological macrostructure, curved surface locomotion, a physical grapple dart and tether, transient tissue deformation, mapped biological materials, chunk/seam diagnostics, and bounded proof scenarios.

Why this is a developer tool

The product is not just a cutting visual. It is the runtime architecture and proof workflow around mutable geometry.

Every major scenario can run interactively or as a bounded deterministic proof. Scripted runs auto-exit, enforce frame and wall-clock watchdogs, capture named screenshots, and write structured logs, state, metrics, edit IDs, hashes, typed faults, mesh audits, and lifecycle records. A failed transaction keeps the last valid field and meshes instead of partially publishing corrupted geometry.

That makes Invector useful as an experimental engine bed for developers who need to answer questions such as:

Did the edit change only its declared chunks?
Did adjacent chunk samples and seams still agree?
Did every raw triangle enter exactly one material partition?
Did speculative visual damage retire only after the real mesh covered it?
Did the same seed and command stream reproduce the same canonical result?
Did an invalid workload leave authority unchanged?

How I built it

The rest surface begins as an analytic or procedurally generated signed-distance field. Signed lattice coordinates divide editable space into one-cell-padded chunks. Surface Nets creates the renderable surface, while validation checks finite vertices, indices, degenerates, material partitions, shared samples, and seams.

For cutting, render-rate input samples are resolved against both a stable guide and the current live field. A pure spatial compiler removes duplicate/collinear samples, applies a causal filter, resamples by kerf width, refines frame changes, and parallel-transports a sign-stable tangent/normal frame. The resulting ordered sections become a canonical tag-6 command with fixed layer depth and six frozen widths.

The current authoritative evaluator is deliberately conservative: CPU-side, synchronous, deterministic, and bounded. The visual wound is GPU-rendered through Bevy/WGSL, but I do not call the current backend “GPU cutting.” Persistent GPU buffers, baked modified fields, incremental GPU Surface Nets, indirect draws, and cross-consumer readiness are the next recorded stages.

How Codex and GPT-5.6 were used

I used Codex with GPT-5.6 as an engineering collaborator throughout the submission-window extension. It worked against the live repository rather than generating an isolated sample. It inspected Rust and WGSL, converted design decisions into bounded slices, implemented/refactored modules, added property and lifecycle tests, ran format/Clippy/test/release gates, executed bounded scenarios, read the resulting JSON/log evidence, and maintained an explicit planning stack.

GPT-5.6 was particularly valuable when the obvious fix was not the real fix. It traced Update/FixedUpdate ownership races that appeared only during long mouse drags, found an empty-index material partition that Bevy could interpret as unrelated non-indexed triangles, separated stable targeting from newly edited surfaces, and designed canonical encodings and replay tests that keep visible feedback separate from deletion authority.

The collaboration also included rejected ideas. I visually rejected an authored wound “pucker” and a masked snapshot tear because they read like floating geometry or caused render handoff flicker. Codex preserved those as historical engineering evidence, contained their failure paths, and returned normal interaction to the accepted head/groove presentation. I made the final interaction, art, scope, workload, and claims decisions.

What changed during Build Week

Invector was a pre-existing project. Before the July 13 submission-period start it already had a runtime shell, an analytic SDF/Surface Nets proof, early surface locomotion, biological material experiments, and transient deformation work.

The meaningful Build Week extension added shared deformation/shadow parity, generated macrostructure and traversal practice, deterministic chunks and canonical edit logs, held continuous cutting, mesh-stage diagnostics and partition safety, exact-coverage wound presentation, the accepted inspection light and wet groove treatment, canonical fixed-depth swept passes, prior-cut reacquisition, repeat-pass deepening, expanded regression coverage, and reproducible bounded proof artifacts.

The repository includes a timestamped proof-of-work ledger that identifies the pre-window baseline and the relevant submission-period commits.

Challenges

The hardest problem was that responsiveness and authority advance on different clocks. Input and presentation update at render rate, canonical transactions run at fixed ticks, mesh assets install later, and a newly cut surface changes the next targeting query. Early implementations could move a preview that the workload had not admitted, retire a sample range before it committed, or reacquire the wrong layer.

The solution was to give every stage explicit ownership: immutable sample IDs, stable guide frames, admission before presentation, canonical command ranges, field/mesh epochs, dirty-chunk coverage, and last-valid fallback. That bookkeeping is not glamorous, but it is what turns a damage effect into engine state.

Surface Nets also exposed a subtle renderer fault. An empty skin/interior partition retained unrelated positions while losing its index buffer, allowing a non-indexed draw interpretation. Deterministic compaction, placeholder meshes, and staged audits removed the flyaway geometry and made the failure typed and reproducible.

Accomplishments

A smooth RMB gesture compiles into deterministic fixed-depth canonical field edits.
Same-pass retracing remains one layer; a later gesture can reach 0.80 and 1.20 depth.
The current bounded cutting proof exits cleanly with five passes, six runs, 43 sections, epochs 5/5, exact depth/gap witnesses, six captures, and no typed fault.
A separate 72-chunk fixture completed 104 edits across faces, edges, and corners with 104,976 shared-sample comparisons and zero mismatches.
Mesh transactions preflight atomically and preserve the previous complete state on failure.
Immediate wound feedback is explicitly non-authoritative and retires only on exact coverage.
The repository has a strict format, Clippy, test, release, scripted-proof, state, metrics, and audit workflow.

What I learned

The biggest lesson was that editable geometry needs protocols, not just algorithms. A good SDF operation and a good mesher are not sufficient if input, presentation, field truth, render installation, collision, and persistence do not agree on which version exists.

I also learned to treat visual rejection as useful engineering evidence. The failed pucker and masked-clone paths clarified the boundaries that the accepted presentation now follows: surface-native motion, no authority from visuals, no promise after capacity rejection, and exact handoff instead of a guessed timer.

What's next

The immediate next slice is a persistent GPU renderer spine with bounded render-world buffers, compute scheduling, indirect drawing, asynchronous status, and a safe CPU fallback.

After that, modified chunks move from replaying historical cutter shapes to authoritative baked signed fields plus a bounded recovery journal. Incremental GPU Surface Nets will update only changed cells/faces, and atomic newest-epoch installation will coalesce obsolete derived work without dropping accepted commands. Collision, grapple, traversal, save/load, streaming, and query readiness then converge on the same baked field version.

Those are roadmap items, not claims about the current submission. Today, Invector demonstrates the deterministic command model, mesh safety, responsive/authoritative handoff, procedural surfaces, and proof infrastructure needed to make that transition credible.