SVG-based semantic 3D rendering from ifc-lite geometry

[mehmet-ylcnky]

Hello everyone, great and extensive work here. Trully appreciate it.

I've been exploring an idea that builds on top of ifc-lite's geometry pipeline, and I'd love to get your thoughts, particularly both on feasibility and whether it's interesting as a downstream project.

The idea

Take ifc-lite's geometry output and render it as interactive 3D SVG, not a static IFC-to-SVG converter, but a live 3D experience (rotate, pan, zoom, click) where every building element is a DOM node you can inspect, style with CSS, navigate with a screen reader.

The approach of this project is like, instead of rasterizing geometry into pixels, it projects 3D geometry into SVG paths, recalculating the projection on every camera change. When you rotate the model, it re-projects all vertices, re-sorts elements by depth, and updates the SVG DOM. The result looks and feels like a 3D viewer, but the underlying representation is a structured vector document.

Every frame is a fresh projection of the 3D model. Drag to rotate --> the WASM kernel multiplies every vertex by the new camera matrix, sorts front-to-back, and patches the SVG paths. It's software 3D rendering, the same thing GPUs do in hardware but outputting to SVG instead of a framebuffer.

Important framing

This is not an attempt to replicate or compete with what ifc-lite's WebGPU renderer achieves. From understanding of the source code, seems like the renderer is already well-optimized for speed, scale, and visual fidelity.

This is an exploration of an alternative rendering representation with fundamentally different trade-offs. It will be slower, limited to smaller models, and visually simpler than ifc-lite's viewer. I accept those limitations by design.

The purpose is to explore what becomes possible when you trade rendering performance for semantic document structure, and to demonstrate that IFC geometry can exist as an interactive, accessible, embeddable vector document.

What it looks like

Instead of sending triangles to WebGPU, take the same MeshData[] that ifc-lite produces and:

1. Project vertices through a view-projection matrix in WASM (software rendering)
2. Back-face cull + depth sort (like in painter's algorithm, or similar)
3. Emit SVG <path> elements grouped per IFC element
4. Add semantic attributes: class="ifc-wall", data-express-id, aria-label
5. Allow orbit/pan/zoom by re-projecting on camera change

Expected result: right-click --> Inspect Element on a rotating 3D building:

<g class="ifc-wall" data-express-id="1847" aria-label="Wall W-104, load-bearing">
  <title>Basic Wall: Interior - 200mm</title>
  <path d="M120,45 L280,45 L280,190 L120,190 Z" fill="#e8e4dc"/>
</g>

What ifc-lite components this would use

I plan the project depends on ifc-lite for the hard problem (IFC --> triangles), and figured out following dependencies:

ifc-lite component	What I'd use it for
@ifc-lite/parser → IfcParser.parseColumnar()	Parse IFC file into data store
@ifc-lite/geometry → GeometryProcessor.processAdaptive()	Tessellate geometry → MeshData[] with expressId per mesh
MeshData.positions / normals / indices	Input to the projection pipeline
MeshData.expressId	Link SVG groups back to IFC elements
MeshData.color	Base face colors for SVG fill
@ifc-lite/data → EntityTable, PropertyTable	Populate SVG semantic attributes (element name, type, properties)
@ifc-lite/data → SpatialHierarchy	Structure SVG groups by storey/space
@ifc-lite/parser → extractPropertiesOnDemand	On-click property display

Everything after geometry extraction (projection, sorting, SVG generation, interaction, accessibility) would be new code in a separate project. ifc-lite does the heavy lifting, this project takes that output and explores a different way of presenting it.

I aim to a proof that IFC geometry can be represented as an interactive semantic vector document, a different answer to a different question than what GPU renderers solve.

Questions for you

1. Is MeshData[] from GeometryProcessor self-contained enough for this? I need positions, normals, indices, expressId, and colors per element. Do I need anything beyond what processAdaptive() yields, or does that cover it?

2. Is there anything in the 2D drawing pipeline (@ifc-lite/drawing-2d, projection_outline.rs) worth reusing? These exist for section cuts, wondering if any projection/outline logic applies to arbitrary-viewpoint software rendering.

3. Any concerns about depending on @ifc-lite/geometry's API stability? I'd pin versions, but curious whether MeshData / GeometryProcessor are considered stable surface.

4. Would this be of interest as a downstream community project? Happy to keep it fully separate, but wanted to check if there's appetite for it in the ecosystem.

5. Has anyone explored SVG or non-GPU rendering from ifc-lite before? Couldn't find prior art in the repo but wanted to confirm.

6. Am I missing any dependency for the project idea? or do you have any suggestion like "look at the topic/point X also"?

7. and finally, I am particularly interested in "this will/won't work because X" feedback. Better to hear it now before diving in.

Cheers!

[louistrue]

Hi @mehmet-ylcnky, good idea and well scoped. One thing up front: don't accept "slower, small models only" as a given. With the right granularity this targets real buildings. Answers in order.

1. Is MeshData[] enough?
For geometry, yes. packages/geometry/src/types.ts gives you positions (Float32, already world-space and Y-up, the WASM layer converts from IFC Z-up and reverses winding so don't redo that), normals, indices, color, expressId, plus optional shadingColor, uvs/texture, geometryClass (0=occurrence, 1=orphan type, 2=instanced type, you'll want to filter on it).

For semantics, no, by design. Name, GlobalId, type, properties are dropped at the WASM boundary. Join expressId against @ifc-lite/data: EntityTable.getName()/getGlobalId()/getTypeName() for your labels, extractPropertiesOnDemand(store, expressId) (a function, not a method) for click. So <g> attributes come from the data store, not the mesh.

Two things to design around now:

• Keep meshes un-merged (one expressId per mesh, the default). If color-merging is on, one mesh holds many elements split by per-vertex entityIds, which breaks your DOM-per-element model.
• Write projection as world = (origin ?? 0) + position. There's local-frame precision work in flight (per-mesh f64 origin, positions relative). It's off today and TS positions are absolute, but that's the one change that shifts what positions means without renaming anything.

2. Reuse from the 2D pipeline / projection_outline.rs?
Yes, this is the main answer. @ifc-lite/drawing-2d is already CPU, non-GPU, to SVG:

• mesh_outline_2d (rust/geometry/src/projection_outline.rs): winding-robust per-element outline union, collapses an element's thousands of triangles into a few contours via i_overlay. Biggest scaling lever (see Q7). It's cardinal-axis only today; the union is projection-agnostic and projectTo2DBasis already does arbitrary-basis, so arbitrary-camera outlines are "combine two existing pieces."
• SVGExporter: already emits <path> with data-entity-id/data-ifc-type. Basically your output format.
• HiddenLineClassifier: real software rasterizer (barycentric + depth buffer). Reuse for occlusion instead of a naive sort.

What's new is per-frame arbitrary-camera orchestration. The math is there.

3. API stability?
Fine to depend on. geometry 2.6.1, parser 3.2.0, data 2.0.3, all public, semver-governed, surface CI-snapshotted (scripts/api-surface.json). Renaming MeshData/GeometryProcessor is a major bump, not a silent break. It's additive-stable not frozen, fields get added more than removed, so pin a minor range and treat unknown MeshData fields as optional. The origin work in Q1 is the one to track.

4. Interest as a downstream project?
Yes, keep it separate. Screen-reader navigable, every element inspectable and CSS-styleable, embeddable with no GPU and no client JS (print/PDF/SSR/email). That last one is genuinely new here. drawing-2d already proves SVG-from-IFC.

5. Prior art?
In-repo yes: drawing-2d is non-GPU to SVG, HiddenLineClassifier is a CPU rasterizer. Free 3D orbit doesn't exist, that's your part. Outside, three.js SVGRenderer is the reference, but it's per-triangle, which is exactly what doesn't scale. Per-element outlines are the improvement.

6. Missing deps / look at X?

• Use SpatialHierarchy to nest <g> by storey/space and to cull whole storeys cheaply.
• Picking is free. DOM pointer events on <path> give hit-testing with no GPU readback. Lean into it.
• These meshes are double-sided with unreliable winding on purpose (culling z-fights coplanar walls). Your "back-face cull" by winding will drop real faces and keep wrong ones. Use the outline union or render double-sided.
• You'll inherit sliver triangles. The repo drops them (drop_thin), do the same or you'll emit zero-area paths.
• Units are already metres, no handling needed.

7. Will it work, and the speed point.
Will work: IFC to triangles is solved, projection is matrix multiplies, SVG-with-semantics is proven, DOM-per-element gives a11y + CSS + picking for free.

Won't work as framed:

• Per-triangle <path> blows up the DOM (dies around tens of thousands of nodes). This is the real ceiling, not the projection. Emit one outline path per element via mesh_outline_2d.
• Winding back-face cull is unreliable (above).
• Painter's sort breaks on interpenetration (beam through a wall has no valid order). Sort per element and tie-break with the depth-buffer rasterizer.
• Re-projecting in JS at 60fps is the wrong loop. Project/union in WASM, apply a cheap 2D transform to the group during drag, re-run the full pass on interaction-end.

On "slow, small models only": the compute scales, projection is cheap and parallel. The only thing that scales with model size is live DOM node count, and you control that. Render at element-outline granularity and bound the visible set with frustum + occlusion + screen-size LOD. Then the live path count stays in the low thousands whether the model is 10k or 10M triangles. Usable on all models is an engineering target, not a fantasy. The work is the culling/LOD pipeline and DOM diffing, not the projection.

Build it. Ping me and I'll point you at the exact files per piece.