Experience map

• Native Three.js · browser rendering
• Property scenes · development and unit views
• Shared rendering foundation across sales applications

I own the viewer as a product surface, including its application integration and ongoing engineering. I built on an early rendering prototype.

• Property content → scene configuration
• Camera presets · unit selection · highlighting
• Filter events ↔ viewer state

The useful part is connecting the 3D scene to what the sales application knows about a property and what the buyer selects.

• Sales agent guides the property view
• iPad controls camera movement on a larger display
• MQTT messaging · device-appropriate rendering budgets

The iPad can act as the control surface while a more powerful machine drives the large display. The interaction state travels between them.

• Blender scripts · repeatable asset preparation
• Export conventions · naming · ingestion expectations
• Prepared content → browser viewer

I wrote Blender scripts to help the art team prepare content for the engine, and worked on the conventions that make ingestion predictable.

• Captured surroundings + modeled property assets
• Loading · detail · GPU resource budgets
• Dataset size ≠ resident data ≠ drawn splats

I work on bringing splat content into the browser experience and fitting it to the loading and rendering constraints of the device.

• Symptom · scenes fail during loading
• GPU diagnostic buffers · allocate when needed
• Lightmaps · bound simultaneous loading
• Textures · guard fallbacks · release unused resources

I traced the loading failures to avoidable startup memory pressure. We changed allocation timing, limited concurrent texture work and corrected resource lifetimes while preserving rendering quality.

• Merged loading fix
• Regression tests + live desktop Chrome checks passed
• Rendering settings preserved

The merged fix passed regression and live desktop Chrome checks with the rendering settings preserved.

• Technical decisions · integration · review · validation
• Rendering code ↔ application behavior ↔ art workflow
• Customer task · guided property sales

My principal responsibility is following a problem across the whole viewer experience, making the technical decisions and validating the result people will use.

• Backend delivers IFC model chunks
• Browser assembles + caches model parts
• web-ifc → GLB parts → interactive scene

I assembled and cached incoming IFC chunks in the browser, using web-ifc to build the GLB parts. That gave us a working model people could inspect and edit.

• Original direction · backend assembly
• Constraint · practical cost + earlier delivery
• Decision · assemble on the client
• Result · working modeling prototype

We moved model assembly to the frontend for practical cost and earlier functional delivery. I got the browser modeling path working.

• Vertex · edge · polygon interactions
• BIM properties · measurement tools
• IFC + custom model schemas

My hands-on work was the browser-side geometry interaction: assembling parts, editing the model and connecting those edits to the application's data model.

• Element selection · highlighting
• Translate · rotate · scale model instances
• Distance · edge length · area · volume · angles

I built model interactions and measurement tools around the BIM data so people could inspect and modify the geometry in the browser.

• CAD / Revit upload → conversion pipeline
• Parasolid in the pipeline
• My slice · browser assembly + editing
• Backend team · conversion + APIs + kernel integration

I worked with the conversion pipeline and the team behind it. I did not author Parasolid or own the separate backend kernel and APIs.

• BCF topic data · comments · viewpoints
• Save and restore ticket edits
• Browser persistence · IndexedDB
• Backend handoff · separate API-team collaboration

I built the BCF ticket UI and local persistence, and worked on pushing ticket information to the backend. The local storage implementation supports this slice; I do not claim a verified complete remote roundtrip or preservation across every model revision.

• Purpose · coordinate architectural + MEP models
• Delivered · viewer, modeling + ticket-data integration
• Full automatic clash-to-issue workflow · unfinished

The product aimed to help construction teams catch conflicts before construction. The modeling and ticket-data work was real; I do not claim the complete automatic clash-to-issue lifecycle was finished.

• Integration team · IFC + company-specific schemas
• Model changes ↔ backend records
• Clear frontend / backend ownership

I worked with the backend and integration teams on how IFC and custom schemas map into the UI and how model changes move back into their records.

• React · TypeScript · Three.js
• Select an organ → relevant biomarkers
• 3D organs + 2D slices + volume rendering

The viewer connected organ selection and annotations with the relevant biomarker information, so the 3D view was part of the dashboard workflow.

• Side-by-side panels
• Linked camera movement · rotate / orbit
• Doctor–member screen-sharing conversations

I introduced camera locking across image panels. Doctors could compare prior and current scans while keeping the view synchronized.

• GLSL volume rendering
• MRI scan context alongside organ geometry
• Inspect source slices + derived models

I used volume rendering alongside the prepared organ models so the browser could show the source imaging context as well as the extracted surfaces.

• Image Recon supplies segmentation masks
• Python · Marching Cubes → rough meshes
• Cleanup + validation → GLB levels of detail
• Prepared outputs → frontend viewer

I built the processing path from the imaging team's segmentation masks to browser-ready organ geometry, including cleanup, validation and multiple levels of detail.

• Checks + alerts for failed outputs
• Debug conversion problems
• Profile geometry for browser rendering

I added checks and alerts for conversion failures and investigated the bad outputs. I also profiled the resulting models so they could render efficiently in the browser.

• Image Recon · segmentation AI + masks
• My work · geometry pipeline + viewer
• Separate API team · application APIs

I worked primarily with Image Recon to understand the source data and make the derived geometry useful. Their team owned segmentation AI; the API team owned the application APIs.

• ~3,000 members · dashboard access
• Doctors · daily member conversations
• Discuss organ changes + relevant biomarkers

About three thousand members had dashboard access. Doctors used the viewer daily to guide members through organ changes and biomarkers.

• React · TypeScript · Three.js
• Side-by-side · overlay · swipe comparison
• Linked views · exact reconstruction versions
• Saved findings retain source + placement basis

The review opens a specific reconstruction version and its source and placement basis. Linked comparisons help inspect differences while the saved assessment remains attached to the exact evidence it used.

• Exact original evidence basis retained
• Replay identical assessment commands safely
• Changed command → reject key reuse
• Explicit corrections link to earlier findings

I keep a review tied to the exact result it assessed. Corrections are explicit, and retries should not silently create another finding or rewrite the previous assessment.

• Share specific evidence with a named recipient
• Recipient can discover the shared evidence
• Assessment brief reopens its exact basis
• Revocation removes access · saved assessment stays intact

I implemented sharing around specific evidence and assessment briefs. A recipient can reopen the evidence they were granted; revocation removes that access without silently rewriting the saved assessment.

• Node / Fastify API → processing request
• PostgreSQL → job + asset state
• S3 → source files + generated artifacts
• Lambda / AWS Batch → processing orchestration

The API records the work and its state, object storage holds the data, and workers produce the outputs. The browser returns to those stored results for inspection.

• Job-driven GPU processing
• AWS Batch manages compute for queued jobs
• Separate request handling from expensive reconstruction

My scaling example is managed compute around batch jobs. It is distinct from running a continuously autoscaled API or a real-time fleet.

• Atomic claim + time-limited lease
• Persist provider execution identity
• Reconcile stale / terminal executions
• Bounded attempts + explicit retry / failure state

The job record tracks who owns an attempt and which provider execution is running. Leases and reconciliation let the control plane identify abandoned work and recover under bounded retry rules.

• Symptom · fresh request key still returned HTTP 409
• Cause · API policy vs older PostgreSQL attempt limit
• Decision · fix boundary · keep duplicate protection
• Regression · first admission + replay + changed-input rejection
• Result · passed · repair verified in staging

I traced an apparent duplicate-request error to a mismatch between the API and database retry rules. I tested the real boundary and fixed the policy mismatch while preserving duplicate protection.

• Mocked route tests skipped the real SQL rule
• Real TypeScript input builder → PostgreSQL reproducer
• Keep a regression across the API / database boundary
• Lesson · test the handoff, not only each component

The route tests mocked the database, so they missed the older SQL rule. I reproduced the refusal with the real API input builder against PostgreSQL and kept that boundary regression with the fix.

• Owner + job type + request key
• Same request → existing job
• Changed input under the same key → reject
• Capture / manifest identity + processing options

A repeated request should not accidentally create another processing job. The identity checks also need to reject a reused key when the inputs have changed.

• Lock capture during admission
• Save job + sources + audit event + dispatch signal together
• Prevent overlapping work for an active capture

Job admission needs to be atomic so concurrent requests cannot each create work for the same capture. The job and its dispatch state belong in one consistent transaction.

• Source data → processing job → output artifact
• Stable version references for review
• Processing status separate from review assessment

The database connects a result to the job and source that produced it. A completed processing job and a useful, reviewed reconstruction are separate facts.

• Implemented · browser review + exact-version comparison
• Historical staging delivery · frontend + backend + served assets
• API / database regression · repair verified in staging

The implemented processing and review workflow reached staging. These are historical delivery and regression checks, not evidence of broad production adoption or a fresh health check.

• AutoCAD Plant 3D · Maya · Rhino
• NURBS / splines ↔ polygonal models
• Formal CAD training · BCIT

I have practical experience with both CAD-style surfaces and production polygon models. That helps me reason about the data and the constraints behind a viewer.

• Founded capture-services business
• Capture-system design + integration
• Captured data → usable digital-twin assets

The business needed a repeatable path from capture to usable assets, so I built processing and delivery tools around the capture work.

• Python · asset assembly + dataflow
• Geometry processing + asset conversion
• Rendering-pipeline automation

Writing tools was part of getting the modeling and capture work done. That is where the progression into software engineering began.