Skip to content
Antoine Boucher

Options

Profiles

← All articles
Project introduction

Dimension: connecting Rust mathematics to a renderer

2 min read

Listen to the audio story

Dimension: Rust math that feeds a renderer · 2:19 · AI-written script, synthetic voices

Transcript

Ava: A renderer is only as good as the math under it. Before a single triangle shows up on screen, something has to decide how matrices are stored and passed around.

Andrew: So where does Antoine start in his Rust project called Dimension?

Ava: With a crate called mathlib. It exposes dense matrix storage, sparse formats like CRS and CCS, vector types, matrix views and submatrices. It also has LU, Cholesky and SVD decompositions, plus root finding and numerical integration.

Andrew: That's a lot of linear algebra for a graphics project.

Ava: It's a workspace for mathematics and graphics experiments, so the two meet in the middle. The rendering crate uses mathlib for CPU transforms and camera math, and then a wgpu renderer prepares the GPU work.

Andrew: What does the scene look like?

Ava: A tree. Entities have parent-child relationships, so a local transform lives inside a hierarchy. Move a parent and you change the context in which its children are drawn. The render crate also exports cameras and render targets.

Andrew: And where does it run?

Ava: In a native window or on a web canvas through WebAssembly. Antoine keeps platform code apart from scene and numerical code, so both targets share the same building blocks.

Andrew: Does that mean it behaves the same everywhere?

Ava: He's careful there. It gives shared building blocks, but it doesn't prove identical behavior on every GPU or browser. Same caution about the GPU: the diagram shows the rendering path, not a claim that every numerical operation runs on it.

Andrew: Any speed numbers?

Ava: None, on purpose. There's an executor abstraction and an optional GPU feature, but that's a design choice, not a measured speedup. He says real comparisons would need a reproducible benchmark with an input size and target hardware.

Andrew: What else is in the workspace?

Ava: The root manifest lists crates for geometry, collision, kinematics, physics, networking, parsing and neural work. The README still focuses on the math crate, so he reads the manifest and module entry points to see the real structure.

Andrew: So the takeaway is to read the workspace, not just the README.

Ava: Yes, and treat it as exploratory code. The full write-up has the architecture diagram and a link to the code walkthrough.

Table of contents

Dimension is my Rust workspace for mathematics and graphics experiments. The useful starting point is mathlib: it exposes matrix storage, numerical solvers and the transformations that the rendering crate uses on the CPU.

Project architecture

Project architecture overview. Open the image to inspect the details.

1. Architecture

flowchart LR
  Geometry["Geometry"] --> Math["CPU transforms<br/>mathlib"]
  Math --> Scene["Scene and cameras"]
  Scene --> Render["wgpu renderer"]
  Render --> Native["Native window"]
  Render --> Web["Web canvas"]

The application supplies geometry and transforms. The scene layer organizes entities and cameras; the rendering layer prepares the GPU work for a native window or web canvas. This is the rendering path, not a claim that every numerical operation runs on the GPU.

Open the component-by-component code walkthrough.

2. Start with the storage

mathlib/src/lib.rs[1] exports dense storage alongside sparse formats such as CRS and CCS. The public API also includes matrix and vector types, matrix views and submatrices. Those choices matter before a renderer draws anything: they determine how a caller represents and passes its data.

The same entry point exposes LU, Cholesky and SVD decompositions, plus root finding and numerical integration. Optional GPU functionality sits behind a feature flag. The presence of an executor abstraction is a design choice, not a measured speedup; I have not included performance comparisons here.

3. Follow a transform into the scene

render/src/lib.rs[2] describes a wgpu renderer that uses mathlib for CPU transforms and camera mathematics. Its exports include World, EntityId, Transform, cameras and render targets.

The scene represents parent-child relationships with a tree. A local transform therefore belongs to a hierarchy: moving a parent changes the context in which its children are rendered. Serialization is optional and enabled through the serde feature.

The platform layer supports native windows and WebAssembly canvas targets. Keeping platform code apart from scene and numerical code gives those targets shared building blocks, although it does not prove identical behavior on every GPU or browser.

4. Read the workspace, not only the README

The root Cargo.toml[3] lists crates for rendering, geometry, collision, kinematics, physics, networking, parsing and neural work alongside mathlib. The README still focuses on the mathematics crate. I use the manifest and module entry points to understand the current structure.

This is exploratory code. Performance comparisons would need a reproducible benchmark with its input size and target hardware.

Browse Dimension on GitHub[4].

References

  1. antoinebou12. (). mathlib/src/lib.rs. [Source file or documentation] github.com.
  2. antoinebou12. (). render/src/lib.rs. [Source file or documentation] github.com.
  3. antoinebou12. (). Cargo.toml. [Source file or documentation] github.com.
  4. antoinebou12. (). Dimension. [Software repository] github.com.

References use this article’s publication date.