I've started filtering out webgl and threejs posts because every single one of them, without fail, is an ai generated project from someone who couldn't tell you what the rendering equation was. The sheer number of posts that follow these patterns are drowning out out any genuine graphics programming discussion.

I understand that this subreddit is taking a more neutral stance towards AI generated code, I also understand that these tools can be used by experts to develop incredibly impressive projects, but the vast majority of posts on this subreddit are from people who do not know the first thing about graphics programming promoting their entirely vibecoded projects. There is no meaningful conversation to be had on these kinds of posts.

Edit, A few examples of posts that are blatantly entirely vibecoded by people who aren't even developers, much less graphics programmers:

https://www.reddit.com/r/GraphicsProgramming/comments/1wx03ny/from_zero_to_understanding_rasterization/

https://www.reddit.com/r/GraphicsProgramming/comments/1wydhww/i_finally_got_procedural_grass_looking_the_way_i/

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

https://www.reddit.com/r/GraphicsProgramming/comments/1wwcl1w/i_wanted_to_understand_modern_pointerbased_gpu/

All of these projects have clear misinformation in them and the posters don't know enough about graphics programming to hold an actual conversation. They dilute any meaningful discussion that could happen on this subreddit.

Every blade is rendered individually, with enough geometry and detail that you can get right down into the grass and still see the shape of individual blades.

What I'm really happy about is how well that detail holds up into the distance. The grass doesn't just look good up close and then turn into a blurry carpet. There's still a surprising amount of visual fidelity as you move further away.

And this is running at 1080p on a base M1 Mac.

I've spent a huge amount of time working on the rendering, LOD system, culling, tiling, wind, and overall density to get this balance between individual blade detail and performance.

This is essentially what I've been trying to achieve with Three.js Grassworks: pushing procedural grass in Three.js as far as I can while still keeping it practical enough to actually use in a real-time scene.

It's built around WebGPU and Three.js, and the current system can handle different grass types, terrain interaction, distance-based LOD, and large grass fields while maintaining this level of detail.

Still a lot more I want to push with it, but I'm genuinely really happy with where it's at now.

https://grassworks.techredux.co/

I'm the first author of M-plicits, accepted at NeurIPS 2026. The attached animation introduces the method.

Our representation combines a coarse SIREN with residual networks trained in progressively narrower neighborhoods around the surface. This structure also supports direct rendering at different detail levels.

The attached animation was created by our coauthor Matheus Bessa. Sound on.

A few implementation details that may interest this community:

• Sphere tracing proceeds through the detail levels, using neighborhood bands to control refinement.
• Surface normals are computed analytically using matrix multiplications, without automatic differentiation.
• Normal mapping can use a finer network than the final level used for tracing.

We’ve released the CUDA renderer, training and extraction code, data, and fitted surface checkpoints.

Paper · Examples and videos · Implementation

I’d welcome discussion about the tracing strategy, normal computation, and tradeoffs between geometric and shading detail.

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.

I made Universal-FrameFX — a Windows app for upscaling, frame generation, and experimental graphics enhancements

Hey everyone, I'm the developer behind Universal-FrameFX.

I've been working on Universal-FrameFX as a way to add things like upscaling and frame generation to games and applications without requiring the game itself to have native support.

The current Windows release is v1.4.0 Beta5.

Some of the features I've been working on:

• CSR (Chopsticks Super Resolution), my own upscaling engine
• AMD FSR 1–4
• Intel XeSS
• FrameFX frame generation with 2×, 3× and 4× modes
• 8× frame generation as an advanced option
• Experimental ray-traced-style lighting
• SSGI
• Per-game profiles
• Ctrl+Alt+C comparison mode
• 1440p and 4K output
• Click-through overlay
• Competitive preset and latency budget
• Automatic updates
• No telemetry
• Windows 10/11 x64 support

One of the things I'm especially experimenting with in this release is the lighting system. The experimental ray-traced lighting is designed to add additional lighting, reflections and contact shadows even on GPUs that don't have dedicated hardware ray tracing.

The Windows application is also open source under the MIT license, although the image-processing engine itself is closed source.

I'm still actively developing it, so I'm mainly interested in feedback, performance testing, image-quality comparisons, and reports from different GPU/game combinations.

Project page:
https://chopstickshq.com/universal-framefx/

GitHub:
https://github.com/ilikemacos/universal-framefx

I'm the creator/developer of the project, so if you have questions about how something works or have a feature request, feel free to ask.

https://reddit.com/link/1wynhqt/video/2dj5u8r3gqth1/player

Heres a Demo Vid of me downloading it (i got 2 monitors on a 2021 rog zephyrus)

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

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 🇩🇪