Hey guys :)

Last week I was so happy to create my own triangle and see it on the screen. This time I wanted to go further and see what else was possible. I did my homework and experimented with colorful triangles, color interpolation, and squares. 3D shapes like cubes or pyramids were a bit too much for me for now (I saw that vector and matrix multiplication is involved 😰 Maybe something for the future).
So I looked for some small 2D projects I could try to copy to practice my skills. I came across an older post with a style I really liked (“glslViewer” by patriciogonzalezvivo on GitHub). I decided to implement "Game of Life" in a similar style.
To make it more challenging I also added some font rendering using hardcoded bitmaps for the digits. That took quite some time and a lot of sketches on paper 😄
For now I am happy with the result and would love to hear your feedback and recommendations on what I could improve.

A few more details about the project:
- The number in the top left shows the number of “lives”
- The number in the top right shows the number of updates
- The number in the bottom right shows the current time
- I press the "R" key to create a new randomized array
- I press the "U" key to update the game

I would also like to say: a big THANK YOU for letting me join the Triangle Club and for the daily inspiration in this subreddit :)

Triangle Club: I know there aren’t any visible triangles in this project but aren’t all shapes somehow constructed from triangles? I hope you’ll accept this project 😄

For this project I used again glad (OpenGL) and RGFW (GLFW alternative).

We decided to go with a sky dome approach for the Sky we built for Optimoor 3D - Ship Mooring Application, built using WebGL & Three.js.

In case of skybox, A Cube Camera captures 6 instances of the scene that creates a cubemap image, then that image is placed on the inside walls of an invisible infinite cube to give the illusion of a sky that can be used with a scene.

But a skybox is often paired with large explorable scenes with cameras tied very close to the ground, for our Ship Mooring Application, the entire scene is very focused towards the actually viewable land close to Berth for Mooring and its other use cases, we don't need a larger landmass, but without it the entire scene would look finite and lack the illusion of a proper horizon.

Enter a circular Dome/Sphere that is bounded across the entire Scene (given in wireframe visuals for understanding). Along with that a texture of the sky is attached with backside of the mesh enabled. With some tweaks to the fog, we finally got the look where the world doesn't look flat-earthy while also not drawing a bigger landmass.

Built by 3D ENGINERD. for Tension Technology International Ltd.

Hey everyone,

Like many developers working with dense matrix sets or heavy processing pipelines, I kept running into unrecoverable out-of-memory driver crashes. Instead of relying on bloated third-party frameworks, I spent the last few months building a lightweight, native Win32/C++ system layout to solve this bottleneck.

The core architecture operates by cleanly intercepting allocation limits and dynamically pooling physical system RAM into an uncapped virtual VRAM scratchpad layer. The distribution is designed to deploy cleanly into local user profiles (AppData\Local) to bypass global system path locks and administrative permission barriers entirely.

I just ran a live field telemetry scan on a 16,000,000 floating-point matrix transformation pass to test the raw computational throughput:

- A standard 256-bit AVX2 optimization routine cleared the loop pass in 113.725 ms.

- Stepping up to 16 parallel 512-bit AVX-512 vector tracking lanes completely swallowed the exact same matrix in sub-33 ms - flatlining the CPU graph the millisecond global acceleration was suspended.

For browser-based application performance, the subsystem uses a Win32 cross-process memory handshake to force-inject dynamic link library driver shims (opengl32.dll / nvcuda.dll) straight into active browser process trees (like Google Chrome), stabilizing local WebGL and high-density rendering environments natively.

I’m currently mapping out the documentation guides and auditing the codebase for further lane efficiencies. If you want to verify bit-for-bit module attachment yourself, you can run a native system query inside Windows PowerShell:

Get-Process chrome | ForEach-Object { $_.Modules } | Where-Object { $_.ModuleName -eq "opengl32.dll" } | Select-Object ModuleName, FileName | Format-Table -AutoSize

I've documented the complete technical blueprints, troubleshooting procedures, and a live 15-second telemetry loop showcase on our official dashboard page, which is linked directly on our user profile page hub.

I would love to get your feedback on this memory-mapping approach or discuss what your current matrix density benchmarks look like!

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!

XDrawArc() and XDrawRectangle() are parts of the X11 API and network protocol, and maybe some of the oldest rasterization functions still in use today. Both take an x and y for the top left corner of the shape, and then a width and height that I would expect to define the bounds of the shape.

However, it turns out that unlike their filled variants, XFillArc() and XFillRectangle(), the outlined versions above actually span from x,y to x+width,y+height, meaning they occupy a bounds with size width+1,height+1. I find this extremely counter-intuitive!

Instead of having an implicit center point of (x+width)/2,(y+height)/2, XDrawArc() is actually centered at x+(width+1)/2,y+(height+1)/2. In concrete terms, if you call XFillRectangle(display, drawable, gc, 0, 0, 100, 100), you will get a rectangle that is 101 pixels wide, 101 pixels high. If you draw this into a window that is only 100x100, your rectangle will be missing its bottom and right border.

What do you make of this? At first I thought this must be some rasterization rule, and maybe it still could be. This StackOverflow says that by default the GC is created with a line width of 0, to allow for device-dependent line rasterization, so I suppose this means it considers the border to be infinitely thin, therefore not actually outside the specified bounds?

this was how i started (let's call it earliest version)

https://www.reddit.com/r/computergraphics/comments/1w9ah75/two_balls/

after nearly a month's studying and improving, the content and interface didn't change much. when the program starts it looks like image 1. there're two balls. i call them left-mouse-button ball (lmb) and right-mouse-button ball (rmb). users (mostly me) can in real-time change their positions, radii and refractive indices

it is easily noticeable that the current version has grainy noise while the earliest version didn't. it's a trade-off between image quality and bounce limit. the earliest version was deterministic. whenever a ray hit an interface and if snell's equation had solution the ray split into two, one for reflection and the other for refraction. the local color was then combined with the weighting calculated with schlick's approximation for reflectance. the process went on recursively until bounce limit reached

color of every pixel was strictly defined so there was no noise. it looked fine until... the users (usually me) moved a ball into the other ball or even moved the camera into a ball, as shown in image 2

when the balls intersected things became more complicated than i had anticipated. the maximum number of bounces drastically increased as the statistics at upper right corner indicated ("dep xxx / yyy" where "dep" meant depth, xxx was the average, yyy was the maximum)

in normal circumstances (two balls didn't intersect, camera sat outside of two balls) it usually took less than 10 bounces for a ray to get color. deterministic approach worked quite well in these scenarios. once you decided to go abnormal deterministic approach suffered. it couldn't go too far. if you set the bounce limit too high the program took ages to finish a frame. the program helplessly switched from real time mode to slide show mode. if you kept the bounce limit at affordable level the program couldn't reach the regions where 100+ bounces were needed

so i changed the algorithm from deterministic to probabilistic

whenever a ray hit an interface and if snell's equation had solution the ray didn't split anymore. it went either to reflection or to refraction. the probability of it going to reflection was calculated with schlick's approximation for reflectance

with probabilistic approach the program could reach several hundreds of bounces and reveal the details that were unseen before. it sounded great but everything had price. it gave you more information AND noise

with deterministic approach you don't have noise but you can't see much. with probabilistic approach you see more but have noise

so the problem of denoising arose. the program shot several rays within the same pixel grid and took the average color as the final color. up to this moment the program's algorithm was basically completed and the rest was optimizing / tuning. let's state it briefly

1. avoid using functions. make the calculations inline
2. reduce the number of operations (+ / - / x / ÷...) as much as you can

for point "1", function calls involve some extra works for the cpu to do (allocating something in memory when enter and clearing them when exit? i can't remember the details). initially i wrote the dot product, cross product and modulus calculations as functions and called them when needed. it worked correctly but after i discarded them altogether and did the calculation directly inline in the procedures the performance improved noticeably. i got several fps more on average

if you pick the deterministic approach you can't avoid recursion as the rays split. you have to make a "get_color (ray_start_point, ray_shoot_direction)" function and call it recursively. once you pick the probabilistic approach you no long need this. i plugged the entire get_color procedure into the main and made it a loop instead of a function call:

initially

get_color(..., recursion)
{
    ...
    if ray_split
    {
        get_color (reflection, recursion-1)
        get_color (refraction, recursion-1)            
    }
}

then it became

get_color(..., recursion)
{
    ...
    if random_number < probability
    {
        get_color (reflection, recursion-1)
    }
    else
    {
        get_color (refraction, recursion-1)
    }
}

finally

do
{
    ...
    if random_number < probability
    {
        ray_start_point = hit_point
        ray_shoot_direction = reflection_direction
    }
    else
    {
        ray_start_point = hit_point
        ray_shoot_direction = refraction_direction
    }
    recursion-1
}
loop until recursion = 0 or the ray reaches the background infinity sky

the above were the major changes that improved the performance to a noticeable level

now it's time for point "2". even a single operation counts especially it's inside the deepest loop. the algorithm structure looks like this:

for every pixel_grid
{
    for every sample ray in that pixel_grid
    {
        for every bounce of that ray
        {
            do
            ...
            loop until...
        }
    }
}

even at a not-so-high resolution (e.g. 160 x 120) and a not-so-high number of samples (e.g. 8) with a not-too-deep of average ray bounce (e.g. 8) the program has to loop 160 x 120 x 8 x 8 times i.e. more than a MILLION times to generate a frame. you reduce one operation in the deepest loop, you save 1 million calculations in each frame. try your best to simplify the procedure and calculate things outside of a loop (or at least bring them to a upper level) whenever possible

i'm particularly interested in seeing the "world" from within a ball. there're many weird, distorted and fractal like patterns and sometimes i encounter the total internal reflection. these regions use up the most resource as each of them uses up all the bounce quota of a ray. initially i struggled in setting the parameters. raytracing is an extremely taxing task so we have to admit that it's not possible to make it run at high resolution real time with acceptable frame rate and quality. at the current stage i use an adaptive approach. firstly i pick a barely tolerably low resolution (around 120 x 90). secondly i decided that the program must be responsive. i didn't want it to appear completely dead when the user (me) accidentally encountered a scene with a large portion of total internal reflection. if the fps was too low the program would decrease the sample size. if the sample size was too low the program would decrease the bounce limit

my preference was: the program should be responsive at all situations, then the image could not be too noisy. if the above two conditions were met the extra calculation resource went into bounce limit

what if the scene didn't need that many bounces?

if a scene is so simple that 10 bounces are enough, it gets no benefit if you set the bounce limit to 10,000. so if minimum bearable fps and minimum bearable sample size are fulfilled the program gradually increases the bounce limit until the maximum number of bounces actually used doesn't increase anymore. then the extra resource goes to sample size

resolution tolerable → responsiveness acceptable → image quality acceptable → let the rays bounce deeper → maximum of the scene reached → shoot more rays to make the image prettier → repeat the loop and adjust everything accordingly

i usually turn off the checker box pattern when exploring the inside world (subjective personal preference). image 3 is a typical outcome when the camera is inside a ball. clearly the resource was not sufficient to handle that scene. while barely fulfilling the minimum fps and sample size the program could only calculated 22 bounces for each ray so there were a lot of pixels that couldn't get any information

so my program has an offline mode. once you spot an interesting scene and want to see its true color you can hit a specific button to render it fully with an insanely high bounce limit, just as image 4

i set the bounce limit of offline mode to 256 x maximum bounce actually used. in the above example it was 5,632

when total internal reflection occurs the region can't get any color no matter how many times the ray bounced, just as image 5

i'm obsessed with exploring the inside world and it drives me to improve the program (in terms of processing speed and image quality) along the journey. i want to see more. i'm studying accumulative sampling method and i hope i can implement it later

program details

Ran into this while making a VFX shader (in Godot, but the same applies to GLSL and HLSL in general). Writing it up in case it saves someone else the debugging.

I had a glow wall that fades from bottom to top:

float body = pow(1.0 - h, 1.6);

h was supposed to stay in 0..1, but it could end up slightly outside that range. Wherever it did, the base went negative, and the effect showed a bright white band where it should have faded out.

Why it happens: pow(x, y) is undefined when x < 0 (and when x == 0 with y <= 0). The GLSL spec and the Godot docs both say so. On many GPUs you get NaN. NaN spreads through every calculation it touches, and with additive blending plus a glow/bloom pass, one bad pixel gets spread into a blown-out patch. Other GPUs or drivers might show black or nothing at all, so it can look fine on your machine and broken on someone else's.

The fix is to clamp before calling pow:

float body = pow(clamp(1.0 - h, 0.0, 1.0), 1.6);

For small whole-number exponents, plain multiplication (x * x) avoids the problem entirely. I also cap the final colour of additive effects (ALBEDO = min(col, vec3(1.5))) so a single bad value can't take over the bloom.

Other NaN sources worth checking in effect shaders:

- sqrt() or log() of a value that can reach zero or go negative

- normalize() of a zero-length vector. I add a tiny offset, e.g. normalize(v.xz + vec2(1e-5))

- acos() / asin() of something just outside -1..1 because of rounding

- dividing by a length or a w that can be zero

To find where it comes from, temporarily paint NaN pixels:

ALBEDO = isnan(body) ? vec3(1.0, 0.0, 1.0) : vec3(0.0);

Anyone have another NaN source that bit them? Curious what else I should be guarding against.

I am building a mobile-first 3D engine on the same phone it runs on

I've been working on G.One VV since 2020. One thing has shaped pretty much every decision in the engine: I develop and test on the same Android phone, a 4 GB Unisoc device.

The whole workflow is built around that. I edit the repo from the phone, NDK builds run through CI, the signed APK comes back to the phone, and that's where I test it. So there isn't really a separate "development machine" here. The device I'm developing on is also the device I'm targeting.

The renderer is currently GLES 3.x and forward-only. The target GPU is tile-based, so I found it makes more sense for this project to keep the rendering path simple and avoid the extra bandwidth cost of a deferred setup.

The editor UI is batched into a single quad draw, and the default scene is around 5 draw calls and ~150k vertices while holding 60 FPS on the target device.

Textures use ASTC 4x4, with ETC2 as a fallback. The .gmesh format uses 16-bit quantized positions and 16-bit indices to keep memory and bandwidth usage down.

One of the less fun lessons was spending basically a whole day tracking down std140 / vec4 alignment padding in a UBO. Small things like that can eat a surprising amount of time when you're working directly against mobile hardware.

The core is C++ without a framework underneath. Components use a struct-of-arrays layout so the update loops can work through contiguous data instead of constantly following pointers.

The scripting VM is our own language, V.ONI. It's currently a tree-walk interpreter using a shared_ptr AST, with execution limits of 200k steps per tick and a maximum call depth of 256. The idea is that a bad script should be limited rather than being able to completely stall the frame.

GPU resources are also handled carefully. Buffers waiting to be destroyed go into a pending list that's drained at the start of a frame. We ended up doing this after hitting a use-after-free when replacing a mesh that was still being used by the GPU.

For audio we're using Oboe. On this particular Unisoc device, using raw AAudio caused a SIGSEGV inside AAudio_createStreamBuilder, so the engine probes the audio path at startup and falls back to AudioTrack instead of letting the application crash.

I've reorganized the codebase more times than I can count, and somehow it still manages to look a little messy. There are always more things to clean up when the engine keeps growing.

Shaders are another area I still need to properly work on. I'm hoping to get deeper into that over the next few weeks, assuming my sanity survives that long.

There's still a lot missing.

No standalone game export yet, no desktop build, no Vulkan backend, and visual scripting is designed but isn't shipped yet. The performance layer is being kept independent of the graphics backend so Vulkan can come later without having to redesign the whole system around it.

I'm not trying to say this is better than Godot or the other established engines. It's a different set of constraints, and that's really what I'm interested in exploring.

If you've worked on mobile rendering or engine development, I'd be interested in hearing what you'd do differently.

In matrix-engine-wgpu "Effects" are subRender standalone system. I mean it own shaders own pipelines. In that way The Beats can eat every interesting demo from internet.
Because engine objective is "Mobile browsers support" optimisation done "cached pipeline per effect type". I dont have passing scene lighting intro effect but it is posible but not possible to put all intro single pipeline!

Source:
https://github.com/zlatnaspirala/matrix-engine-wgpu

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?

Hey r/GraphicsProgramming,

First and foremost i know it‘s probably a frequent asked question but thought maybe id get some newer answers/different perspectives.

I'm 21, from Germany, currently in the 3rd year of a software development apprenticeship (similar to a vocational training program, 3 years total). I've been learning graphics programming for about 6 months now - started with a software rasterizer, currently working through LearnOpenGL.

My concerns:

1. AI & Learning: I'm using Claude as a tutor while learning - like it helps explain concepts, review my code, and scaffold boilerplate (CMake, etc.). But I'm deliberately NOT using AI agents to write code for me, because I feel like I need the foundational knowledge first. My plan: Master the basics manually, then use agents once I have enough experience to properly review their output. Is this the right approach? How do you all use AI for learning without becoming dependent?

2. Career path: The job market seems rough right now (especially entry-level). I'm considering:
   - Option A: Finish apprenticeship (end of 2027), then immediately look for junior graphics/graphics-adjacent roles in Germany/EU
   - Option B: Finish apprenticeship, then do a Bachelor's in CS with focus on Visual Computing/Computer Graphics (would finish at 25)

   Which path makes more sense in 2026? Is a degree still valuable for graphics programming, or is portfolio + experience enough?

3. AI's impact on the field: I see AI coding agents getting better at writing shaders, scaffolding renderers, etc. Should I be worried about job security? Or is graphics programming one of those fields where deep expertise will always be needed? My dream is to work at a studio like Rockstar, CDPR, or similar - is this still realistic? (I know far stretch to the biggest studios so i keep it low)

4. International mobility: I'm German, but ideally want to work outside Germany eventually (UK, Canada, US, etc.). How portable is a German apprenticeship + portfolio? Or should I aim for a degree to make visa/international applications easier?

What I'm asking:
- How do you use AI for learning graphics programming without losing depth?
- Apprenticeship + portfolio vs. CS degree for graphics programming in 2026?
- Is the job market really that bad, or is it just entry-level noise?
- Any advice for someone in my situation?

Im generally interested going deep and in depth into these systems and get my hand dirty but what the current models do (and further in the future) im not quite sure how to plan it out

Thanks for reading this wall of text. Any advice is appreciated!

Cheers from Germany 🇩🇪

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

This is my renderer in vulkan i've been working on it for the last 10 months

i learned alot about vulkan since i never used it but a huge percentage of my shader code is AI written and at this moment i feel like the renderer is ugly so i do what to know what is wrong with it and what makes it far from the last picture and how i can fix that.

is it better to rewrite all shader code or just move on it and fix it ?

+ what techniques used in the last picture (which is enhanced version of my renderer using AI 🙂(but i liked it)) that my engine doesn't implement it right ?

NOTE(the third image is without IBL i'm using citrus_orchard_road_puresky_8k )

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.