

Alpha: Trinium's performance paths are experimental. Results depend on your hardware and the scene being rendered.

More focused rendering work, with Rust where it can help.
Trinium explores ways to reduce rendering overhead by moving selected work into Rust and grouping terrain commands. It concentrates on the work needed to prepare and submit a scene, while Minecraft continues to handle the rest of its rendering and simulation.

In one terrain comparison using the same extracted scene, Trinium grouped submissions while preserving the rendered image:
| Measurement |
Individual submission path |
Batched path |
| JNI batches |
574 |
16 |
| GPU draws |
574 |
574 |
| Compared color and depth pixels |
Identical |
Identical |
This compares batching in one test, not overall FPS. Performance varies across scenes and hardware.
Rust visibility and sorting
Rust helpers handle selected section-visibility work and stable transparency sorting. Trinium also applies conservative camera-frustum filtering to supported vanilla chests, reducing rendering work for chests outside the view.
Terrain command batching
Selected terrain OpenGL commands pass through Trinium's Rust command transport and can be grouped into batches. This reduces the number of Java-to-native calls needed for those submissions.
Preparation caches
Mesh-owned preparation caches and model-buffer reservations reuse preparation work and buffer capacity as scenes are rendered.
Renderer status
When Rust GPU submission is active, the F3 screen displays Renderer: Trinium 3D Render.


Rust helpers process selected visibility and sorting tasks for Minecraft's renderer. On the active terrain submission path, Rust batches selected commands before they reach the GPU.