Visionary puts Gaussian primitive sorting on the GPU and skips Ubuntu

Ubuntu is excluded by an upstream fp16 bug, macOS by raw speed

The platform section is the most honest part of the documentation, and it names two different reasons. Ubuntu is not supported, and the reason is not a missing feature: a Chrome WebGPU bug means fp16 is not properly handled there, which breaks the fp16 ONNX pipelines the project depends on. Official support is promised once the upstream issue is fixed. macOS is a different problem, a hardware one. GPU performance on most Macs is limited for heavy Gaussian Splatting workloads, and unless the machine has a high-end chip such as an M4 Max or better, macOS is explicitly not recommended as the primary platform because the viewer may run very slowly or stutter. What is recommended is Windows 10 or 11 with a discrete GPU from NVIDIA or AMD, and a recent Chrome or other Chromium-based browser with WebGPU enabled. In practice that is one well-tested configuration rather than a cross-platform library.

The performance claim is about sorting, and one library is the yardstick

The efficiency claim in the abstract is narrow and specific: under identical 3D Gaussian Splatting assets, the renderer achieves better rendering efficiency than current web viewers, and the stated cause is GPU-based primitive sorting. The feature list says the same thing from the other direction, describing native WebGPU use for parallel sorting and rendering of millions of Gaussian particles. That is the whole architectural bet in one sentence. Sorting is the step that decides which splat is drawn in front of which, and doing it on the GPU rather than on the CPU is what separates this from the reference implementation it credits, web-splat, alongside 3D Gaussian Splatting itself, ONNX Runtime Web and three.js. If you are comparing against another browser viewer, the question to ask is not its shader quality but where it sorts.

Your algorithm produces Gaussians; the renderer still renders

The extension mechanism is a standardized Gaussian Generator contract, and it is what makes the platform's claim of supporting future algorithms coherent rather than aspirational. A plug-and-play algorithm is not asked to write a renderer. It is asked to generate or update Gaussians, and the contract lets it do that every frame, so dynamic scenes do not require a different integration path. Because generation happens per frame rather than at load time, the inference engine runs inside the browser, which is why ONNX Runtime Web is a dependency rather than an optional extra. The same per-frame inference also buys something adjacent: feed-forward generative post-processing, so style transformation and enhancement networks can run on the rendered result. The claim that this lowers the barrier to reproduction, comparison and deployment is the consequence worth weighing, since a method only has to export to ONNX to become comparable to any other.

Five format families behind one loader interface

The asset loader presents a single interface and identifies the format itself, which is the difference between a viewer that handles one splat format and one that handles a folder. Static Gaussian assets are covered in PLY, SPLAT, KSplat, SPZ and SOG. Standard mesh models are covered in GLB, GLTF, FBX and OBJ. The dynamic representations, meaning 4D Gaussian Splatting, neural avatars and scaffold-GS, arrive as ONNX. And a fourth route, spelled with a typo in the feature list as your own algorithom, goes through the export documentation. Trained 3D representations have to be exported to ONNX to work, and the repository ships conversion examples for the 4D, dynamic avatar and scaffold-GS cases. The root also contains a gitmodules file, so at least one piece of the tree arrives as a submodule rather than through the package manager. Getting an asset onto screen from a checkout takes three steps:

# Clone the repository
git clone https://github.com/Visionary-Laboratory/visionary.git
cd visionary

# Install dependencies
npm install

npm run dev

After the server starts, the simple example lives at the demo path on port 3000, and the demo tree holds two directories, a simple case and a showcase. Node.js is the only prerequisite, with version 18 or newer recommended. Sample assets, covering neural avatars with 4D Gaussian Splatting and two further example sets, are hosted on Google Drive rather than in the repository, so a first run needs a network fetch before anything appears.

Depth compositing is the part that mixes splats with meshes

Most of the feature list is about splatting, which is the interesting but solved problem. The bullet worth reading twice is the hybrid rendering architecture, described as automatically handling depth mixing, called depth compositing, between Gaussian point clouds and standard meshes, solving occlusion issues and supporting complex scene compositions. That is a real problem rather than a feature checkbox. A Gaussian has an oriented ellipsoid and a per-splat opacity rather than a depth buffer entry, so a mesh and a splat in the same scene have no shared way to decide which is in front. Compositing has to be done deliberately, per frame, and getting it wrong produces the specific artefact where a mesh floats through a captured room. The mesh formats in the loader and the compositing path are therefore the same feature seen from two sides.

The install hook rewrites the bundled ONNX runtime

Installing the package from npm runs a script that patches a vendored dependency. The manifest wires a postinstall to a fix target, which runs the script against the bundled runtime directory, and a second variant runs the same script against the source copy. Both the patch script and the postinstall wrapper are listed in the published files array, alongside the build output, the public directory and a dummy ONNX model. In other words the tarball ships the tool that modifies itself after extraction, not a pre-patched artifact. That is a reasonable way to distribute a vendored runtime, but it is the kind of thing worth knowing before an install runs in a locked-down build environment. The ordinary build is a Vite bundle followed by a separate declaration-only TypeScript pass that emits into the distribution directory, and the package name in the manifest is the core library rather than the project name.

Six docs scripts and two docs toolchains for a renderer

The script list is longer for documentation than for the product. There are separate targets to clean the docs site, fix docs encoding, copy docs files, build a multilingual variant and rename assets for a static host, plus a serve target. A documentation development run chains four of those and then starts a Python-based static site generator, and separate targets build the English and Chinese versions from two different configuration files, with one full target that also builds the library first. Meanwhile the repository root holds five separate HTML entry points: the main one, a demo view, two help pages in different languages, and the editor. The published documentation lives on a different host from the project page. None of this affects the renderer, and all of it tells you that documentation is a first-class part of the project with its own toolchain.

Editorial conclusion

Use Visionary when you need to view or edit 3D Gaussian Splatting assets in a browser without a native viewer, and when you want your own algorithm to plug in rather than fork the renderer. Before you commit, check your platform against the support notes, because Ubuntu is blocked by an upstream fp16 bug and most Macs are too slow to be worth it, leaving Windows with a discrete GPU as the realistic target. If you install the npm package, note that its install hook rewrites the bundled ONNX runtime, and read the export instructions before assuming your own model will load.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. Visionary-Laboratory/visionary on GitHub