ResVR · ResOS · a simplified Higharc, built on what we own

Builder CAD in. A shoppable 3D home out — with a live price.

Take the CAD a builder already ships — interior and exterior — and turn every option combination into a priced, walkable home in the Visualizer. Higharc's buyer experience, minus the machinery we don't need.

from builder CAD (DWG) interior + exterior live pricing reuses the Visualizer
BUILDER CAD (DWG) DECK · 21'-4" x 12'-0" AI + BUILD 3D MASSING base + deck (snap-on) → + $18,500 live
Executive Summary ONE PAGE · READ THIS FIRST
The problem

One real plan (Bridgeport) carries 113 structural options and 23 elevations in PT — millions of buyer combinations. And it's just one of ~12 plans in Schell's Monarch catalog: ~1,380 structural options + 140 elevations in total, every one still waiting for a 3D model. Impossible to hand-model, and today buyers can't see or price their choices.

The idea

A simplified, Higharc-style single source of truth. Take the builder's CAD (the DWG set they already produce); AI classifies it — interior (structural) vs. exterior (elevation), mapped to the option tree in Production Tracker. We build the home from reusable snap-on 3D pieces (base + option modules, interior and exterior). The Visualizer shows every combination live — with a running price from PT as the buyer toggles.

Why now

Higharc just raised a $95M Series C (June 2026) selling exactly this to builders. The category is validated — and we already own the hardest, flashiest piece (the 3D configurator). We take that slice; we skip the rest.

Why it fits us

The Visualizer is the buyer configurator. PT already has the rulebooks — structural_options (interior) and elevations (exterior) — both with unreal_path columns sitting empty. The builder already produces the CAD. And PT's catalog already stores prices. We're finishing a loop, not starting one.

The honest limit

No "point an API at a floorplan, get a finished house" button exists today. The accurate path is a pipeline with a quick human check at the front. But because we build pieces, cost is per-plan, not per-variation.

The ask

Approve a small ~1–2 week proof-of-concept: AI reliably reads a Schell plan into structured data. If it lands, we fund the pipeline — and the live-price overlay is a cheap early win.

Higharc, and the slice we're taking

Take the buyer-facing pillar. Skip the enterprise tail.

Higharc turns one plan into shoppable 3D, plan-based estimating, and permit-ready construction docs. We don't need all three — we need the one buyers touch, and we're already most of the way there.

✓ already own it

Shoppable 3D configurator

Real-time 3D where buyers toggle options and watch the home change. This is what the Visualizer already does.

~ simplified

Plan-based pricing

Not full estimating & takeoffs — just a buyer-facing running price, read live from PT's catalog. Higharc's headline number, the lightweight way.

$95M

Higharc's Series C (June 2026), $170M+ raised total. The market has already decided builders want this. Our edge: we're not building the platform — we're extending the Visualizer we already ship.

The whole idea in one picture

It's a LEGO house kit — with a price tag.

  • 📦

    The floorplan is the picture on the front of a LEGO box.

  • 🤖

    The AI is a super-fast helper who looks at the picture and writes down which pieces go where — and which are extras you can add or skip (the deck, the porch).

  • 🏠

    We build the base house once, and make each extra a snap-on piece.

  • 🧩

    Picking "Deck 1 + Screen Porch 2" just snaps on two pieces — and the price tag adds up as you go.

  • 🎮

    The Visualizer is the toy town where the finished house gets walked around.

Two models, one home

Interior and exterior — both from the same CAD.

A home is really two coordinated model families. The builder's CAD contains both, so the pipeline generates both the same way.

interior · structural options

The inside

The rooms you walk through, built from the DWG floor / ceiling / section / framing set.

  • walls · floors · ceilings
  • windows · doors · baseboard

Maps to PT structural_options. Bridgeport (real): 113 options — Kitchen (Chef's/Gourmet/Pro/Standard), Owner's Bath (Luxury I–III), rear decks/porches/sunroom, garage, basement…

exterior · elevations

The outside

The facade — the curb-appeal look a buyer picks first. Also CAD-derived.

CraftsmanSchell ASchell BSchell CSouthern

…each with sub-elevations (brick, side-load, 4th-bed variants) — 23 elevation models for Bridgeport. Maps to PT elevations.

1 level

In Unreal both live in the same level, separated by layers (interior / exterior). They must stay in sync — a "4th bedroom" or side-load garage changes both the inside and the facade. Keeping them consistent is exactly what a single source of truth buys you.

Bridgeport Schell Style A — exterior render by Santi
Santi's actual Bridgeport render — Schell Style A, one of 5 styles (each with sub-elevations). This is the target the assembled 3D must match.
How it works · 5 steps

Drawing in, walkable priced home out.

1
🤖
Ingest + classify

Read the CAD

Geometry comes straight from the DWG. AI classifies it: interior vs. exterior, and which option each piece belongs to.

2
👀
Review

Human checks

A person fixes anything the AI got wrong. The safety net that builds trust.

3
🧱
Extrude

Build the pieces

Deterministic code turns the plan into accurate walls, a base, and snap-on modules.

4
🎮
Assemble

Into the Visualizer

Base + modules load into Unreal; option toggles wire to the existing config.

5
💲
Price + Publish

Live cost, then GDN

Each toggle pulls its price from PT and updates the total; ships via NVIDIA GDN.

Because the input is real CAD, the geometry is deterministic — accurate, repeatable, auditable. AI's job is the tedious human step: classifying which piece is which option (interior or exterior) and matching it to the PT rulebook. Not guessing shapes.
The handoff · how a piece reaches the Visualizer

Into the Visualizer — the honest version.

The pieces don't magically appear in the Visualizer. They cross a real boundary: we produce the assets and the option/price data; the Unreal team brings them into the project, wires the toggles, and ships the build. It reuses the exact pipeline that ships every Visualizer build today.

1

Export

Interior + exterior modules from the CAD as Datasmith / FBX / glTF, plus the option & price data.

2

Import

Pulled into one Unreal level as static meshes — interior and exterior on separate layers.

3

Wire toggles

Each module bound to an in-engine option toggle, keyed to the PT option ID. unreal_path written back to PT.

4

Cook

Baked into the map & packaged — BuildCookRun.

5

Ship to GDN

Uploaded to NVIDIA GDN, pixel-streamed to buyers. Build-monitor watches it.

ResOS · our pipeline (steps 1) Unreal team · Plastic SCM → GDN (steps 2–5)
Reality check: the Visualizer is baked — every content change needs a cook + GDN redeploy (not instant like a web app), and the in-engine toggle wiring is owned by the Unreal team. Want "edit in PT, appears instantly, no rebuild"? That's a separate runtime-loading rework — a future fork, not part of this plan.
Why this approach

Build pieces, not combinations.

✕ The hard way — model every combo
Bridgeport, one real plan (PT):
113 structural options
× 23 elevations …
millions of buyer combinations · one plan

You could never model each. That's the trap.

✓ The LEGO way — snap pieces together
1 base + a piece per option
+ each elevation & sub-elevation
= every combination
~120 reusable pieces (Bridgeport)

Cost is per-plan, not per-variation.

Build ~120 pieces once, get millions of priced variations for free.

It plugs into what we already have

The data — and the prices — are already sitting there.

PT already stores each plan's options as a structured tree, with the 3D columns in place. The catalog already stores prices. The pipeline just fills the blanks and reads the numbers. No new source of truth. PT is also the authoritative worklist of what to build for a builder — e.g. Schell Brothers → Monarch — not any one sample plan. The tree below is real Bridgeport data — the render_url / unreal_path columns are literally empty in today's export. Across the whole Monarch catalog that's ~12 plans · ~1,380 structural options · 140 elevations with no 3D yet.

production-tracker · structural_options · elevations · catalog_options
INTERIOR — structural_options  (real Bridgeport export)
   "Rear Structural Option Location 2"   ← choice group (parent)
     ├─ Deck 2  ├─ Screen Porch 1  ├─ Sunroom
     ├─ Covered Porch I  ├─ Courtyard Porch 1    ← pick ONE
     └─ each: floor · room · render_url · unreal_path  ◄ EMPTY
   … + ~56 more groups (Kitchen, Owner's Bath, Garage, Basement…)

EXTERIOR — elevations  (5 styles, each w/ sub-elevations)
   Schell A · Schell B · Schell C · Craftsman · Southern  ← style
     └─ brick · side-load · 4th-bed variants · unreal_path  ◄ EMPTY

catalog_options.price  + community/region overrides   ◄ live total
The pricing overlay

Watch the price move as you choose.

Your home · Cassidy plan live
Base planschell · cassidy $412,000
+ Deck 1rear structural · loc 2 + $18,500
+ Screen Porch 2rear structural · loc 1 + $24,000
+ Gourmet Kitchencatalog · appliances + $12,750
Total $467,250
◦ Illustrative numbers — not real Schell pricing.

How it works

As the buyer toggles an option in the Visualizer, its price is read from PT and the total re-computes instantly — the same option data that drives the 3D also drives the number.

Finish/catalog options are priced in PT todaycatalog_options.price, with community & region overrides. This half works right now.

Structural options and elevations aren't priced yet — each needs one new price column (structural_options, elevations). Small, honest add; called out so nobody's surprised.

Scope discipline

What we're deliberately not building.

This is what keeps it "simplified."

Construction & permit docs

Structural drawings, code-compliant permit sets. Huge, regulated, not our lane.

Full estimating / BOM

Line-item material takeoffs and bids. We show a buyer price, not a builder's cost sheet.

Generative "AI house" mesh

Meshy / Tripo-style guesswork. Not dimensionally trustworthy for real homes.

The plan · crawl → walk → run

Phased, with a go/no-go gate up front.

PhaseWhat we doRough effortSkills
0 · Prove the AI gate Ingest the real Bridgeport DWG set; AI classifies interior vs. exterior and tags each piece to PT structural_options / elevations. Measure accuracy. ~1–2 wks · 1 eng AI / vision
1 · Trust layer Scaffold a ResOS app (from orgchart). A review screen to correct scale, walls, and option tags. D1 for jobs, R2 for files. ~4–6 wks · 1–2 eng React / TS + platform
2 · Build the pieces Headless pipeline: CAD → accurate geometry → base + interior option modules and exterior style/variant modules. Export to the Visualizer's format. ~4–6 wks · 1 eng 3D / Blender
2.5 · Live pricing Wire toggles to PT prices; running total in the Visualizer. Add a price column to structural options and elevations. Cheap early win, high visibility. ~1–2 wks · 1 eng platform / PT
3 · Into the Visualizer Import into one Unreal level (interior/exterior on separate layers); wire option toggles to PT IDs; publish via GDN. Reuses the existing config. ~6–8 wks · 1 eng Unreal (existing team)
4 · ResOS automation A new community or plan auto-kicks the pipeline → review → publish, kept in sync with PT. The single-source payoff. ongoing platform / PT
End-to-end (1 builder)

~4–6 months to a working, priced configurator for Schell, then scale to other builders & plans.

Team

~1 AI/vision eng + 1 3D/Blender eng + the existing Unreal engineer + part-time platform/PT.

⚠ Effort figures are best-guess bands to refine with the team — not commitments. Phase 0 is deliberately tiny so we learn cheaply before investing.

Straight talk

What AI can and can't do here.

Real leverageAI shines

Classifying the CAD. Which layer/block is which option, interior vs. exterior, and matching each to the PT rulebook (structural_options / elevations). The tedious human step — now the AI's job.

Assist onlyAI helps

Untangling messy CAD. Layer names and how variations are encoded differ plan-to-plan and builder-to-builder; AI helps reconcile them, a human confirms. This is the real risk — not the geometry.

Not AI at alland that's good

The geometry, and the pricing. Geometry is read straight from the CAD; prices come straight from PT. Deterministic — accurate, reproducible, auditable. Even less generative than reading a floorplan image would be.

The ask

Let's spend two weeks proving the hard part.

Fund a small Phase 0 proof-of-concept: run it on Bridgeport and show that AI can reliably classify Schell's CAD into the structured options our tools already understand. Low cost, clear go/no-go. If it works, we've got a simplified Higharc — built on the Visualizer and PT we already own.

Approve Phase 0 → ~1–2 weeks, 1 engineer
Everything after the gate is optional and sequenced.