Add https://mcraft.fun (advanced minecraft clone in web) - advanced voxel game (also current http://voxeljs.com/ demo seems to be dead)
And active theory which looks cool: https://activetheory.net/
Did you create or work on these projects, @zardoy ? Or just suggesting they get added to the showcase?
I’m not sure that activetheory is using threejs…
@manthrax mcraft.fun is an OSS project that I own, but what about activetheory it is more complicated… I didn’t work on the activetheory project but my friend was convinced they were using Three.js modules. I’ve thoroughly reviewed the app code (which is heavily inspired by the Three.js API btw) and indeed they are not using threejs renderer (most probably because they ran into performance issues). Anyway, thanks for pointing out! I will remove activetheory from the description.
1 Like
Oh cool you made the mcraft.fun! That’s pretty dope! Looks like a lot of good work went into that. 
And yeah, R.E. Activetheory. They are a very well known and prestigious group. They have used threejs in the past, and have also actively (no pun) developed their own suite of bespoke tools which have undoubtedly diverged from the pure threejs library we have today, although I think saying that it was because of performance reasons is a bit reductive, moreso as them needing certain customizations and modifications to support their own internal tooling and use cases, and also the desire to make their products feel more custom and bespoke… which they do… ( and is also part of why they are pretty much the top of the game in terms of commercial 3d web productions. )
If you break in their renderer, you can see a lot of the same class names and idioms that are also in threejs, but that doesn’t mean that it’s using threejs, just that the structures used in scene graphs are well established idioms. Matrix, Quaternion, Vector3, Scene, Object etc. were concepts conceived for the most part back in the 60s, 70s and 80s with E&S/ PHIGS and later in SGI, and Pixars RenderMan:
4 Likes
Wow! There is no way you know so much! Thank you so much for the clarification! To be honest we are also looking into building our own renderer specifically designed for rendering voxel graphics in extremely efficient way!
Nice! Sounds exciting! 
I’ve written a few voxel renderers in my day… I learned a lot from the process.
edit: I saw this video the other day… some interesting info in here: https://www.youtube.com/watch?v=40JzyaOYJeY
3 Likes
Hi! I’m so sorry recently found it in a search and noticed that I forgot to reply 
Well, we also learn a lot! We are making our brand new webgpu renderer from scratch without relying on any libraries or existing demos (except for this video that we watched like hundreds of times). And that’s a lot of trying different approaches to make rendering work on all platforms (including buggy Safari which gets WebGpu updates like once a year). On the other hand, there is a weekly newsletter “What’s new in WebGpu - chrome” which keeps mentioning new updates for new ways of optimizing voxel renderers, it’s really interesting to see how it’s all evolving.
Meanwhile, we are extremely slowly working on fixing major bugs and adding new optimizations in the renderer and even have frustum & occlusion culling and indirect rendering which works on all platforms including ios. There are a few links:
source code for the renderer: prismarine-web-client/prismarine-viewer/examples/webgpuRenderer.ts at ac111a8ae4b99cd09b34d843a9fe0b70a2d419a9 · sa2urami/prismarine-web-client · GitHub (ComputeShader and ComputeSortShader might be easier to understand whats going on, they are in the same dir)
4 mil blocks: Renderer Playground
a world with 16 chunks render distance (might take some time to load) Prismarine Web Client
we mostly test it in the playground for now, but I hope it can become a good MC renderer alternative one day, making a voxel renderer is fun 
1 Like
I remember the first and current voxel rendering pipeline with three.js was made by someone by following threejs fundamentals guide. The article was called making minecraft voxel renderer or something like that. The problem of using BufferGeometry is that you have to pass a lot of data for 4 vertices per each tile in the world, each of float32: color, normal, position, uv, index. That’s a lot of data to prepare/transfer and the biggest lag spikes happen in subData since that’s a lot to write. And also no instancing was possible to use, since each buffer geometry represents a 16x16x16 section of the world. Instead, we have the following pipeline for rendering full blocks in the world:
- Prepare all block data to gpu for each id (state) which includes information about texture tile index for each side, rotation and other info such as emit light level.
- Then we have two buffers for the scene:
- Chunks buffer: have x, z of the chunk of blocks
- Blocks buffer:
- position: x, z(0-16), y(0-1024)
- visible sides mask (tiles to not to render)
- tint (rgb 0-255) - biome color used on grass and water, but I think we will also optimize it later
- block id (state)
Of course all data in these buffers are compacted into uint256 so we have 0 lag spikes when writing data to gpu and it’s cheap to prepare that data and transfer between contexts. And we also have 0 cpu usage in the renderer pipeline. Eg we were trying 20x performance slowdown and could see the same fps in the loaded scene.
Though we are having some issues occlusion and transparent blocks, so we temporarily disabled transparency😅
So happy with webgpu experimenting so far, but we are running out of ideas…
1 Like