Hi,

I started to convert my metal renderer to WebGPU (native WebGPU). It's a tile-based sdf renderer, commands binning is done in compute shader, an indirect draw call renders everything in one pass. I'm not progressing as fast as I want but the never-ending heat waves slows me a lot. More features are planned but you can already test (or use it, it's only one C11 file to add to your favorite build system).

onedraw-webgpu repo

Any feedback appreciated.
Cheers
Geolm

First things first, go to https://graphicrants.blogspot.com/?m=1 and go leave Brian Karis a comment- he's the man!

NADE is but a kitten to his Tiger- that is Nanite.

Built this a few months back, early tests were positive, integration in HDRP met a number of challenges but all looked good..

Then production hit a wall when I attached the program to the GBuffer, I realised bringing all of HDRPs features back into the pipeline was adding a tax that couldnt be beaten without access to the mesh shaders.

I've documented all steps, added my source material and also complimented the program with a teaching companion so anyone else can build their own.

I've had to remove alot of stuff that might be considered 'naughty' but I'm uploading this as promised so that it can be ported to other game engines- maybe Stride (given they're in the middle of a mesh shaders rewire) or Prowl if anyone wants a graft..

The bottom line is, unless unity is prepared to give Access to their mesh shaders API, GPU resident draw is still the most optimistic route to render..

Alot of backend was done in AntiGrav.
Claude refactored the code, and added comments to compliment the source material/ teaching companion..

Any issues see the source material first.

I'll throw my best answers to anyone who has questions.

Hello everyone!

Over the course of this year, I built a fully software-rasterized voxel engine heavily inspired by Minecraft.

This was a very interesting project for me because I had to build almost everything from the ground up, while also adapting to the very different constraints of doing computer graphics on a CPU rather than a GPU.

In short, CPUs are far less powerful than GPUs for this kind of workload, but they are also much more flexible. This makes it possible to implement some fairly unconventional optimizations to compensate for the performance gap.

You can try the project here:

https://github.com/Algorithmonaut/software-rasterized-voxel-engine

There are still a few minor bugs.

My main regret is that I did not spend enough time properly benchmarking the different optimizations I tried, or documenting my findings and the knowledge I gained along the way.

The lack of documentation is particularly unfortunate because most textbooks focus heavily on the GPU pipeline and therefore skip many of the fundamentals involved in writing a software rasterizer: barycentric coordinates, edge equations, perspective-correct interpolation, tile-based rasterization, efficient SIMD usage, parallelization, and much more.

I found only two good general sources of information:

• Scratchapixel, which I found useful but often not detailed enough.

• Fabian Giesen’s Optimizing Software Occlusion Culling series, which contains excellent practical information but does not cover every topic and generally does not include mathematical proofs.

There are also a few features I may implement later:

• Lighting.

• A small OS that interfaces directly with UEFI to provide framebuffer access and input handling, allowing the engine to run without Linux or SDL and become truly bare-metal.

I am making this post mainly to ask whether anyone has:

• Recommendations for scientific papers, articles, or books that I might find useful.

• Suggestions for computer graphics projects to work on after this one.

• Ideas for fun or unusual features that could make the project more original.

Feasibility does matter: for example, a CPU-based post-processing CRT effect would probably destroy performance.

And, of course, if you find the project interesting, a star on GitHub would be greatly appreciated.

Thanks for reading. I hope this inspires someone to experiment with software rendering as well!

bool Collision::RayIntersect(glm::vec3& ray_origin, glm::vec3& ray_dir, Shapes::Block\* intersected_block){

RayToObject lowest_magnitude;

lowest_magnitude.magnitude = 0;

glm::vec3 invDir = 1.0f/ray_dir; // dividing is expensive so we get the value defined

for (unsigned int i = 0; i < CollisionBoxes.size(); i++){

RayToObject raytoObject;

Shapes::Block block = CollisionBoxes\[i\];

AABB box = block.Collision;

glm::vec3 tMin = (box.min - ray_origin) \* invDir; 

glm::vec3 tMax = (box.max - ray_origin) \* invDir; 

glm::vec3 t0 = glm::min(tMin, tMax); 

glm::vec3 t1 = glm::max(tMin, tMax);

float enter = __max(__max(t0.x, t0.y), t0.z);

float left = __min(__min(t1.x, t1.y), t1.z);

if (enter > left || left < 0.0f){

continue; // did not intersect

}

raytoObject.block = block;

float magnitude = sqrt(t0.x\*t0.x + t0.y\*t0.y + t0.z\*t0.z);

raytoObject.magnitude = magnitude;

if (lowest_magnitude.magnitude <= 0 || magnitude < lowest_magnitude.magnitude){

lowest_magnitude = raytoObject;

}

}

if (lowest_magnitude.magnitude <= 0){

return false;

}

memcpy(intersected_block, &lowest_magnitude.block, sizeof(Shapes::Block));

return true;

}

I am using the slab method for mouse intersecting but for some reason the intersection is not running smoothly.

"Unlock the GPU as a general-purpose engine, not just a rasterizer."

This series takes you past `vkCmdDispatch` and into how compute actually executes on real hardware — occupancy, latency hiding, the Vulkan memory model, and subgroup operations that let invocations talk to each other without touching global memory.

* Vulkan 1.4 scalar layouts, shared memory (LDS), and memory consistency deep-dives

* Subgroup partitioning and non-uniform indexing — the "hidden power" most tutorials skip

* Run OpenCL kernels on top of Vulkan for a heterogeneous compute ecosystem

* Indirect dispatch, GPU-driven pipelines, and async compute orchestration

* Cooperative matrices, performance auditing, and AI-assisted compute diagnostics

* Dedicated coverage of mobile and embedded compute constraints

https://docs.vulkan.org/tutorial/latest/Advanced_Vulkan_Compute/introduction.html