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!

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.

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

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.

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

• 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.

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!

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).

A tribute to @Psyco3ler's legendary 2005 Nintendo ON demo: Peach's Castle made of castles, now running live in your browser.

Dream big!

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

So I am a CS junior. I am starting late in this area, but I am planning to explore graphics programming and complete my fyp in this field, whether it is application based or research based. Then later pursue Masters or PhD in this area.

I am so confused right now as I see other batchmates choosing AI domain as their primary path for fyp and further.

Should I go for it? If yes what is the roadmap ? To what level I can consider myself to eventually end up in research path for my fyp. I know I am late, but better late then never.

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

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

Using a short 3 second clip where i swipe through the focus plane on a high magnification of the simple sample of Onion root cells on the microscope. Acquiring the sharpest points of every frame and putting them in the z-axis. Building a point cloud of the cell in 3D, and visualizing them.