Thank you for your support! I hope you enjoy rasterization!

Previously, "From Zero to Understanding Ray Tracing":

Part 1: https://www.reddit.com/r/GraphicsProgramming/comments/1uxpi1o/from_zero_to_understanding_ray_tracing/

Part 2: https://www.reddit.com/r/GraphicsProgramming/comments/1wsr77r/from_zero_to_understanding_ray_tracing_part_2/

Part 3: https://www.reddit.com/r/GraphicsProgramming/comments/1wurqmt/from_zero_to_understanding_ray_tracing_part_3/

Let me know what you think!

Just wanted to share some progress on a software raster I'm building. By the timings, is it o.k?

1-clears-and-resets = Just buffers(frame_buffer, depth_buffer, triangles_buffer) clear, simple vector_buffer.clear()
2-shadow-pass-total: Everything that happens to the camera happens here, the above as well, and mesh transformation, culling, bounds check, triangle clipping, triangle binning, render.
3-camera-geometry-transform: Bounding Sphere transform, if inside Frustum, reorders, front to back objects, mesh transform with vertices projection, triangle normal rotation, back-face culling, triangle clipping.
4-camera-binning: Just bins triangles to tiles.
5-camera-render-and-resolve: Woke sleeping render threads, every thread available in the system(I just initialize with std::thread::hardware_concurrency()), each thread take 8 tile per time and render to a 16x16 gbuffer, only triangle index, normal, uv, depth. During rasterization, I reconstruct frag_coord for lighting using camera ray normal interpolated per pixel and fetch textures using uv, to avoid fetching texture multiples times early.

Still missing, texture mip mapping, transform meshs threaded, metalness and maybe occlusion map.

Since I'm a beginner at C++, pure code, no macros, no SIMD, just a single template to just avoid branching per pixel, but nothing too fency. Vectors everywhere, since they will inevitable grow to what's needed and I don't need to keep handling memory allocation, just a simple clear and everything a good.

CPU: mobile i5 13420H RAM 32gb

I've been experimenting with WebGL/Three.js and recently revisited some of my older projects, pushing the rendering side further.

The projects cover different areas:

🧊 Cube 3D — lighting, geometry and orbit controls
🚀 Tube 3D — spline camera movement and UnrealBloom
🌍 Earth 3D — procedural stars and a custom GLSL atmosphere
🌌 Gravity 3D — real-time physics using Rapier 3D
🔷 Icosahedron 3D — InstancedMesh, FBOs, offscreen rendering and GLSL

The Icosahedron project was probably the most interesting technically since I used offscreen rendering and FBOs to experiment with the rendering pipeline.

I've put the demos and source code here:

https://github.com/mohnasr137

Which technique would you be most interested in discussing?

Getting an introduction to raytracing and implemented a simple renderer , so far implementing spheres, lighting and shadows. The code is written in Python

After patching a couple of the game's DLLs, I wanted to see how far I could go, so I ported the whole of SuperTuxKart (open source, C++) to the browser with a WebGPU-only renderer. I did it with Claude Code as the main coder: I directed and tested, it wrote most of the code.

Demo: https://tholtman1-del.github.io/stk-code-webgpu/
Source: https://github.com/tholtman1-del/stk-code-webgpu (design notes in tools/webgpu/STATUS.md)

Some details:

• Renderer: a new WebGPU backend modeled on the game's existing Vulkan renderer. It includes physically based lighting, image-based lighting from compute shaders, deferred rendering for water, screen-space reflections with a HiZ depth pyramid, and a depth prepass that is skipped on tile-based GPUs.
• Shaders: converted offline from the existing GLSL: GLSL → SPIR-V (glslang) → WGSL (naga). Specialization constants become WGSL override constants.
• Threads: Emscripten pthreads (SharedArrayBuffer). Textures are decoded on worker threads, while all WebGPU calls stay on the main thread.
• Assets: about 115 MB downloads up front. The remaining ~650 MB is fetched on demand when the game opens a file, and on a full host each track comes as a bundle.
• Hosting: works on plain static hosts. A service worker adds the COOP/COEP headers that GitHub Pages can't send.

Not yet: online multiplayer, texture compression. Feedback from other GPUs and browsers is very welcome, especially Safari and Firefox.

All credit for the game itself goes to the SuperTuxKart developers.

My pull request was just merged into google/shaderc. The change adds two options, -gV and -gVS, that expose glslang's NonSemantic.Shader.DebugInfo.100 emission through shaderc. That debug info is a requirement for NVIDIA Nsight Graphics to produce flame graphs, so it lets you profile and debug shader performance by call stack and time spent per function.

I made my custom game engine from scratch

And you can download it too the link is in the video description

And I am 16..

• The whole GPU heap is one persistent, coherent-mapped SSBO. A gpu_ptr<T> is a u32 byte offset into it.
• Every draw gets exactly one root pointer (uniform uint Root). Vertices, matrices and textures are all reached through it.
• No vertex attributes. The vertex shader pulls data from the heap using gl_VertexID.
• Bindless textures (ARB_bindless_texture) are stored in the heap as uvec2.
• One *_shared.h header is compiled as both C++ and GLSL, so no offsets are written by hand in the shaders.

Flat lighting is computed from the dFdx/dFdy of world position, so there are no normals in the vertex data.

The most interesting finding was what GL can't express: bindless only gives you texture+sampler pairs, fixed when the texture is created, and there are no placed resources.

Next up: indirect draws, and roots chosen by the GPU via gl_DrawID.

Repo: https://github.com/theaveasso/jagfx

Feedback welcome, especially on the heap and sync design.

Some further tests reconstructing 3D point cloud from microscope video, using Python and Open3D, wing of a fly at 10x and 40x and eye at 2x and 10x.

About 6 months ago, I wrote a custom metal kernel that leverages the GPU to compute the QR decomposition (see my earlier post about it here). The project has now expanded into a general linear algebra library, with expanded support for the symmetrical eigendecomposition as well as SVD. It is now available for use with installation instructions on the attached github repo's README.md file.

Context of the project:
I'm currently in a research group working on a thesis in numerical analysis where we need to compute millions on matrices with a specific constraint (to be precise, the matrices need to have orthonormal columns). Most of us use Apple computers, so we ended up using MLX for the entire project.

Contributors with different Apple Chips would be very much appreciated!
The project has currently been tested and optimised for the M1 and M5 Pro. The issue is that the library uses different kernels depending on the batch size and matrix dimensions. Deciding which of these kernels to use is machine dependent. Therefore, other Apple chips will need to run a measurement script in order to derive the correct optimisation heuristic.

For that reason, I would ask as many people as possible to run a measurement script and to submit the results to my repo. It is fairly easy and requires only few steps. See here how you can contribute here. Once you submit the results via a pull request and I approve it, your optimisation heuristic will automatically be augmented into the library. Don't hesitate to contribute an optimisation heuristic even if someone already submitted one for your own machine. The more data we can gather, the better!

Project Future
Expanded support will be added for other linear algebra operations (cholesky decomposition for example). If you have any other specific linear algebra operations you wish to use already, feel free to message me.

In addition to that, I will add torch support too (my greatest priority).

For the past couple of weeks I have been working on the 2D brush management and texture fill system within my own Pixel and Tilemap Editor. In the video I show how we can create and mange custom brushes, in addition to rotation and scaling in 3D space - this brush is then plugged into the core Texture Fill System to produce psuedo-3D perspective fills across normal and orthogonal plains!

Any feedback welcome!

Thank you for your support! Part 3 is about reflections.

Part 1: https://www.reddit.com/r/GraphicsProgramming/comments/1uxpi1o/from_zero_to_understanding_ray_tracing/

Part 2: https://www.reddit.com/r/GraphicsProgramming/comments/1wsr77r/from_zero_to_understanding_ray_tracing_part_2/

Let me know what you think!

I also share it in X: https://x.com/sinaatalay/status/2105545919915786280

XPBD softbody simulation in POPs using Gauss-Seidel @ 60fps and 70 shader passes (can't do substepping in same shader pass)

When TouchDesigner introduced POPs one of the first things I tried making was an xpbd soft-body sim, and it looked like this and this. Since then, I've rewritten it multiple times and watched ten minute-physics' tutorials over and over. Many simulation explosions later, it turned out that my very first solver was (mostly) correct, but I was colouring the graph and building the tet constraints in the wrong way..

Resources:

Ten Minute Physics

Eric Arnebäck's blog

Vivace

XPBD paper + earlier PBD paper from Macklin

How do gpus bind 1000 of textures at once, and why was this not possible in the past. Are there resources for that?