# Augrade

Ruslan Vasylev: Senior Software Engineer, Jun 2024–Aug 2025.

Help general contractors coordinate model corrections with specialist subcontractors before construction.

At Augrade, I owned the web UI and 3D viewer, including design and implementation without a dedicated designer. I balanced customer and CEO needs to help general contractors inspect models and communicate required corrections to specialist subcontractors. The code includes model interaction, worker-based clash review and local BCF issue creation; remote ticket synchronization is not verified.

- Operator: General contractor coordinating the project
- Audience: Specialist subcontractors responsible for model corrections
- Ownership: Whole web UI and 3D viewer · product design and implementation · customer/CEO prioritization
- Impact: Two customers used the product; use of individual feature slices is not separately established.
- Delivery: IFC loading, model interactions, caching, clash detection and local BCF issue creation are present in inspected cached-main code; deployment of those revisions is unverified.
- Workflow: Load and inspect models → identify coordination conflicts → select findings → create local BCF issues for correction discussions

## Projects

- **BIM coordination viewer**: Facts: Model assembly, Worker-based mesh clash detection, Clash review and local issue creation.

## What did you build?

### Model assembly

Ownership: Browser model assembly and caching

I added IFC loading to the existing viewer and developed the browser model-loading path. Inspected code reconstructs interactive IFC fragments and caches model bytes with version/checksum metadata and invalidation.

- Existing GLB path → direct IFC loading
- ThatOpen/web-ifc → fragments and interactive models
- Browser Cache Storage · checksum/version metadata · validation

Technologies: IFC, web-ifc, WebGL, GLB, ThatOpen, Cache Storage

### Why browser assembly

Ownership: Client-assembly decision with the team

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

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

### Design and delivery priorities

Ownership: Viewer product design, implementation and prioritization

I owned the viewer’s design and implementation without a dedicated designer. I prioritized what customers and the CEO needed, translating general-contractor coordination tasks into model interactions and review workflows.

- No dedicated designer · owned design and implementation
- Balance general-contractor needs and CEO priorities
- Coordinate inspection and correction communication before construction

Limits: Preventing downstream conflicts and rework is the intended purpose; this account does not establish a measured safety or rework-reduction result.

## How did model editing work?

### Model editing

Ownership: Browser-side geometry editing

I developed browser-side geometry interactions, including vertex tools, multi-selection and model-instance transforms, and connected editing state to the application’s model data.

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

Technologies: IFC

### Selection + measurements

Ownership: Viewer interactions and measurement integration

I integrated selection, transforms and library-backed measurement tools into the BIM viewer so the general contractor could inspect geometry while discussing corrections.

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

Collaboration: Measurement tools use ThatOpen components; another engineer contributed some initialization code.

Technologies: Three.js, IFC, ThatOpen

### Building data in GIS context

Ownership: Building visualization and property-editing workflow

The application placed BIM and building data in GIS context for planning and design decisions. I built browser visualization and property-editing interactions.

- BIM / IFC geometry within GIS context
- Building properties · design options
- Browser visualization for planning and design decisions

Limits: The delivery claim covers broader building/GIS visualization and property-editing work; it does not establish deployment or customer use of the particular viewer, clash or BCF revisions inspected in code.

Technologies: IFC

### Conversion handoff

Ownership: Browser model assembly and editing

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

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

Collaboration: A separate backend team owned conversion, application APIs and kernel integration.

## How did clashes become coordination issues?

### Worker-based mesh clash detection

Ownership: Browser clash engine, worker integration and rule-based review

I developed a browser clash-detection path that sends geometry and instance transforms to a worker, builds BVHs and returns intersections for semantic and rule filtering. General contractors can review the resulting conflicts and select findings for local BCF issue creation. This is mesh-based analysis using Three.js and three-mesh-bvh.

- Serialize meshes and instance transforms to a Web Worker
- Build mesh BVHs and test intersections
- Semantic/rule filtering → reviewable clash results
- Progress, cancellation and worker cleanup

Limits: Committed implementation is present in cached main; runtime correctness, numerical accuracy, deployment and feature-level customer use were not verified by this source review.

Technologies: Three.js, three-mesh-bvh, Web Workers

### BCF ticket persistence

Ownership: Ticket UI and local persistence; backend-team handoff

I built the BCF ticket UI and local persistence so model findings could be retained for coordination discussions. Inspected code stores topics, comments, viewpoints and relations in IndexedDB and supports BCF file import/export. I also worked on backend handoff, but a complete remote submission and retrieval roundtrip is not verified.

- BCF topics · comments · viewpoints · element relations
- IndexedDB CRUD and clash-to-topic mappings
- BCF ZIP/XML import and export
- Backend handoff reported; remote synchronization unverified

Limits: Local persistence and file exchange are code-inspected; remote synchronization, arbitrary model-revision preservation and deployment of the inspected revision are unverified.

Technologies: BCF, IndexedDB

### Clash review and local issue creation

Ownership: Clash-review UI and local BCF issue-creation integration

The general contractor uses model conflicts to identify corrections to discuss with specialist subcontractors before construction. Inspected mainline code converts selected clashes into local BCF issues, records element/rule identities and handles partial creation failures.

- General contractor reviews model conflicts for subcontractor corrections
- Selected clashes → stable IDs → BCF topics
- Partial-create failures → keep successes or roll back
- Remote synchronization and deployed revision unverified

Limits: Local clash-to-BCF creation is implemented; deployed/customer-used feature scope and the complete remote lifecycle are unverified.

Technologies: BCF, IndexedDB

## How did you work with backend?

### UI ↔ model records

Ownership: Frontend model-record mapping and change interactions

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.

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

Collaboration: I collaborated with backend and integration teams on IFC/custom schemas and model-record updates.

Technologies: IFC