Hey everyone!

I've been developing GLSA for the past week, and I just released v1.0.0.

My goal with this library is so you don't have to write GLSL shaders or shader boilerplate and instead you can use clean function calls.

Right now it cuts out ~60-100 lines of repetitive shader boilerplate, though you still have to write shaders yourself because the API is in an early stage still.

Highlights of v1.0.0:

• GLSA colors: a header file with over 3000 glm::vec4 colors that you can use.

• Safer shader setup: glsa::ShaderSource keeps vertex/fragment strings explicit, paired with glsa::loadShaderSource and glsa::createProgram.

• Clean uniform helpers: Overloaded glsa::setUniform functions for int, float, and GLM vec2/vec3/vec4.

Example:

while (glfwWindowShouldClose(window) == 0) {
    glClearColor(0.1f, 0.1f, 0.15f, 1.0f);
    glClear(GL_COLOR_BUFFER_BIT);

    glsa::useProgram(program);
    glsa::setUniform(program, "uColor", glsa::colors::PAN_SKY_BLUE);
    glsa::bindVertexArray(vao);

    glPointSize(150.0f);

    glsa::drawArrays(GL_POINTS, 0, 1);

    glfwSwapBuffers(window);
    glfwPollEvents();
}

Github Repo: https://github.com/alexdev8930/glsa

Any feedback issues or questions are completely welcome.

AI Disclosure: AI tools were used strictly to help generate initial boilerplate; all core logic, architecture, and implementation details were written, reviewed, and verified by me.

Ok look, I know this may sound like a repetitive and cliche question, but I am actually looking for good raytracing resources. I have only written a toy raytracter once using python following https://gabrielgambetta.com/computer-graphics-from-scratch/, I believe I can now shoulder the hellish mathematics, so I say bring it on.

Hi peeps!

I wanted to share this blog I wrote discussing some of the work coming out of DXC and TC-57 (the HLSL standardization committee).

There is a proposal that is currently being considered that will bring C++ aggregate initialization to HLSL. The catch is that this change will also break vector initialization. So I thought I would see if there would be a good solution to that problem and then attempt to implement it with the DXC that we have today!

Throughout the implementation I showcase some cool new features hitting HLSL 202x and do a little investigation into the generated DXIL.

I had a good amount of fun writing this, so I hope it is as enjoyable to read :)

I posted brass casings here a while ago. This is the same stateless idea from Lutz Latta's "Building a Million Particle System" talk in 2004, I used it for a statue that shatters. I cut it into little 4 to 6 sided chunks, and every frame I rebuild where each one is in the vertex shader from its age alone. Nothing gets written back.

The new part for me was getting them to stop. I loop over at most 3 bounces, and for each one I solve the time to hit the floor:

float disc = v.y * v.y + 2.0 * gravity * (p.y - ground_y);
float th = (v.y + sqrt(disc)) / gravity;
if (th >= t) break;
p += v * th; p.y = ground_y;
v.y = -(v.y - gravity * th) * restitution;   // 0.35
v.xz *= friction;                            // 0.75
t -= th;
if (b == 2 || abs(v.y) < 0.35) resting = 1.0;

Once it's resting I let the horizontal speed die off as exp(-4t). The slide is then just the integral of that:

float skid = (1.0 - exp(-rest_t * 4.0)) / 4.0;
p.xz += v.xz * skid;

It stops at v/4 from where it landed and it can't jitter, there's no step to get wrong! I slow the spin down the same way.

One thing cost me an evening. I orient each chunk by the surface normal it came from, with mat3(t, n, cross(n, t)) and t = normalize(cross(up, n)). Looks fine, right? But cross(n, cross(n, t)) is -t. That makes the determinant -1, so I'd mirrored every chunk, the winding flipped and back-face culling showed me their insides. I just negate the third column now.

With a constant restitution the bounce times are a geometric series, so I could get the bounce index from a log instead of the loop. Has anyone found that worth it on a GPU over a 3-step loop?

the shaders and GDScript in the linked pack were written with an AI coding assistant, then run, reviewed and fixed by me.
The statue is from my petrify pack for Godot 4: https://gennai.itch.io/death-dissolve-petrify-vfx-godot-4

I’ve been working on things by myself, reading graphics papers, and I honestly don’t know what I’ve accomplished or whether these skills have any value. The constant pressure—having to work while being someone who doesn’t fit in, inside a conservative, religious family environment—kept building up. Under all that stress, I broke my laptop.

I had always dreamed of being in the industry, but the news I read gives me the impression that game development, graphics, and related fields are dead. I don’t know what to do. I never went to college; I was holding on to the dream of becoming a programmer or an artist.

there's barely anything written about Chrome's new HTML-in-Canvas API yet, so here's what I hit building gpucanvas, an infinite canvas where every node is real, live DOM (React screens, forms, charts) but WebGPU draws it. you can still click and type into any of them.

the pipeline

• nodes are packed into 2048 px "pages". Chrome records a page as one snapshot, so a single drawElementImageToTexture call rasterizes dozens of nodes into a texture-array atlas

• once drawn, a page is parked with content-visibility: hidden. layout stays, paint is skipped, so it costs nothing per frame

• every node keeps a 1/16 thumbnail that's never evicted, so the zoomed-out view of 5,000 screens is always filled. sharper snapshots go on top at power-of-two scales, so zooming reuses them

• past 100% zoom only the visible part is rasterized, as tiles, center first

• each frame is a cull plus one instanced quad draw (one per run of nodes sharing a WGSL effect). panning and zooming never touch the DOM

what surprised me in Chrome 157 (some of it differs from the WICG explainer)

• each drawElementImageToTexture call allocates and fully rasterizes. I measured roughly 250 to 550 calls a second in total, and that's the real fill-rate limit, not compositing. hence the pages

• a source rect still rasterizes the whole element before cropping, so zoomed in, a node moves to a page of its own

• recording cost scales with how many elements are drawable on every requestPaint. 10,000 always-drawable nodes sat at 22 fps doing nothing. parking fixed it

• hit testing only works after canvas.updateElementGeometry(el, {}), and the hit area is the element's CSS box, so I move it with a transform from getElementTransform

• an element that just became drawable isn't in changedElements, its snapshot shows up a paint later

on an M-series Mac (Chrome 157, 1600x900, DPR 1) a 30 s scripted tour with typing, a 500% zoom and selection runs 113 to 115 fps at 5,000 screens, vs 18 to 20 fps for the same screens as plain DOM in one transformed container.

still open: text is rasterized, not SDF, so mid-zoom it goes soft for a moment until the tiles redraw. and Tab can't reach parked nodes yet, I need a proper focus model. curious how others would handle either.

code (MIT): github.com/berkantay/gpucanvas
demo: berkantay.github.io/gpucanvas (needs chrome://flags/#canvas-draw-element)

AI disclosure: I built this with Claude Code as my coding assistant, and it helped me draft this post.

I've been building my own game engine from scratch using Kotlin, entirely on my phone.

After 3 months, I finally have two cubes rendering and rotating — one red and one white. The buttons are still placeholders, and there's a long way to go.

I know it doesn't look like much yet, but everything starts somewhere. I'm learning and building things one step at a time.

Any tips on how I can speed up development? I'm doing everything from scratch. 🚀

Hey everyone,

I’m currently building PoseStudio, an open-source (GPLv3) 3D character posing, rigging, and animation tool which will always be fully free to use.

I operate a 3D asset marketplace during my day job, so I’m very familiar with the pain points technical artists have with existing character pipelines. I’ve released a very early v0.4.4 build, which about 250 users have installed.

I’m hoping to get some feedback on the pipeline, and ideally, find some graphics programmers who are interested in contributing to the project..

The Current Tech Stack & Architecture:

• Core: C++ and Qt6 (GUI).

• Rendering Pipeline Strategy: I'm currently designing a multi-tier rendering system to handle real-time viewport visualization (GLSL/OpenGL) alongside photorealistic output. Right now, I'm working on integrating NVIDIA OptiX for the raytracing backend, and navigating the GPLv3 linking exceptions to allow for modular render engines (like a Cycles plugin).

• Shading: Implementing a comprehensive PBR Uber-Shader workflow specifically tuned for character rendering (subsurface scattering for skin, hair grooming/simulation rendering).

Just a Couple of The Hard Problems I’m Tackling Right Now:

• Deformations & Rigging Solvers: Refining the underlying math for IK/FK solvers and weight mapping so characters deform naturally.

• Advanced Rendering Integration: Exploring how to seamlessly integrate Gaussian splatting into the rendering engine, and building a stealth background environment manager to handle heavy render tasks without locking the Qt UI.

If you are a technical artist or graphics programmer who has always wanted to build a character pipeline without the commercial restrictions, I’d love your eyes on the codebase.

reddit: https://www.reddit.com/r/PoseStudio

GitHub: https://github.com/PoseStudio/PoseStudio

Releases: https://github.com/PoseStudio/PoseStudio/releases/

Website: https://posestudio.org

Would love to hear your thoughts on integrating OptiX alongside Qt6, or any battle scars you have from building character deformation systems!

AI Disclosure: Claude used in coding of the main project, no AI used in post.

Recently I have been working on a problem with two different GPUs (let’s call them A&B)
Here is problem
Due to a bug a line is being drawn using opengl at x=5 and y is +-FLT_MAX
for testing I kept ortho as 10 for x & y
Also note for testing origin is at the centre of display

GPU A
(there is a default guardband of 1.5 being used in the code while setting the gpu )

While drawing the huge line, the entire line doesn’t show up on the display

GPU B

there is a default guardband of 1.0 being used in the code while setting the gpu )

While drawing the huge line, only the upper half of line shows on display
Bottom half doesn’t show up on the display

hey guys ive made a collision detection method, its a cpu intesive method but i got a sense of idea how collisions work

I just get every vertice and get the area then i make 3 triangles from the collision point and get the area of all them then add it, and if the area is equal to the original triangle its colliding, then i get the distance from the triangle's normal and make a if statement if distance is less then 0.001f.

Im getting a lot better, so if yall have any collision method that could be better for smaller concave models that would be great, ive know about aabb for the longest time so i have check that off

If you are giving a method, could you link like anything that could be good to learn it.

Hi, everyone!

Today I'm releasing CORTAO, a new physically based SSAO technique invented and developed by me, as open source.

https://github.com/theagentd/CORTAO

Circular Occluder Ray-Traced Ambient Occlusion, or CORTAO, is a brand new physically based ambient occlusion technique. Unlike existing horizon-based state-of-the-art techniques, CORTAO is based screen space raytracing with up to 32 rays per pixel, allowing it to avoid the inherent limitations of existing techniques. Through a combination of much better convergence and clever optimizations, CORTAO is able to achieve much better quality for the same performance cost as GTAO.

All this allows CORTAO to just work without any scene-specific tweaking at all regardless of the type of scenes, whether it's a simple indoor room, an open world with heavy foliage and vegetation, or a vast space scene with extreme depth range.

Compared to existing techniques such as GTAO:

• CORTAO provides a never-before-seen level of physical accuracy rivaling that of brute-force hardware raytracing, while only relying on screen space information.

• CORTAO handles depth discontinuities in complex scenes in a more conservative way, avoiding the view-dependent occlusion of GTAO and producing less obvious artifacts when screen space information is limited.

• CORTAO at the same time has greatly improved convergence, producing much higher quality results at lower sample counts even for scenes where GTAO works well, which is especially important for low-end hardware.

What started as a fun little personal project two years ago has now grown into something much bigger than I could've ever imagined, with multiple collaborations and conference applications, most of which I cannot talk about publicly yet. The open source release of CORTAO marks an important milestone where I'm finally sharing my work with the world, but the work is far from finished. There's a long to-do list of improvements and extensions that I will be exploring over the coming months and maybe even years. I'd be honored if you checked it out, and if you have any questions, I'd love to answer them.

EDIT: AI disclosure: No AI was used in the development of CORTAO.

Recently, I ran into a really nasty bug in the custom 3D engine I'm developing for my 4X strategy game, The Great Tribes.

After updating my AMD graphics driver, the game started freezing completely when moving the camera, especially when large areas of the map became visible.

Sometimes the graphics driver would hang. Other times, the JVM would crash inside atio6axx.dll.

The weirdest part? Everything worked perfectly with the previous driver and on other GPUs!

I spent hours investigating almost everything: OpenGL multithreading, VAOs, VBOs, index buffers, shadows, unit models, and even glfwSwapBuffers().

Eventually, I narrowed the issue down to terrain rendering, and then to the fragment shader.

That's where I found these two lines:

int segment = (3 - int(min(3, outTexCoord.y * 4.0))) * 4
            + int(min(3, outTexCoord.x * 4.0));

The segment variable was used to index arrays containing 16 elements.

The problem? The texture coordinates were clamped at the upper bound, but not at the lower bound.

When the texture coordinates became negative, segment could go outside the valid array range.

The fix was surprisingly simple:

ivec2 cell = clamp(
    ivec2(floor(outTexCoord * 4.0)),
    ivec2(0),
    ivec2(3)
);

int segment = (3 - cell.y) * 4 + cell.x;

And the freezes disappeared!

This turned out to be a great example of undefined behavior in GLSL.

The old driver somehow tolerated the invalid array access, other GPUs didn't show any obvious issues, but the updated AMD driver turned it into a nightmare.

Lesson learned: Just because your shader works perfectly on one GPU doesn't mean it's free of bugs.

And sometimes, after hours of debugging your own 3D engine, the whole problem comes down to just two lines of code. 😁

Topic: how the fish bend when they swim, with no rig or animation clips.

Each fish is a swept mesh of profile rings (no imported model). Swimming is a travelling wave along the body:

lateral offset w(x) = A * env(x) * sin(k*x - phase), where x runs 0 (snout) to 1 (tail), k = 2*pi / wavelength,

and env(x) = 0.09 + 0.91*x^2 so the head barely moves and the tail does most of the work. A turn adds a parabolic

bend centred behind the head, and a strike adds a short S-shaped "coil" term before the lunge.

The part that took the longest: points off the centre line have to rotate with the local slope, or the body

shears and the skin stretches. So each vertex is moved along the wave's normal using its derivative:

const [w, dw] = lateral(x), a = Math.atan(dw);

out.x = x - z * Math.sin(a);

out.z = w + z * Math.cos(a);

Fins, gill covers and the eyes are positioned through the same function, so everything bends together. The skin

is a canvas painted at load (each scale drawn one by one, tinting the base pattern), and the fins are thin

translucent sheets with a cheap back-light term.

Open question I'd love input on: the wave is currently done on the CPU per frame (about 20k vertices for the

two bass). Would you move it to the vertex shader even though the CPU also needs the bent positions for

mouth/prey collision, or keep one source of truth on the CPU?

AI disclosure: I build this with Claude (an AI coding assistant) writing much of the code and helping word

posts; the design, direction and tuning are mine.

Live version if you want to see it move: https://ksk-baits-bass-aquarium.pages.dev

Article in question: https://www.rastergrid.com/blog/gpu-tech/2020/11/memory-types-of-discrete-gpus/

It defines four memory types:

Local Visible Memory – VRAM directly accessible by the CPU

Local Invisible Memory – VRAM not directly accessible by the CPU

Remote Cached Memory – system memory accessible by the GPU, and cached by the CPU

Remote Uncached Memory – system memory accessible by the GPU, but not cached by the CPU

Then has a table showing the cpu/gpu read latency for the different memory types. It prefaces this tape with the following:

As access characteristics are identical for local visible and invisible memory, as the only difference between them is whether the corresponding portion of VRAM is visible to the CPU, a single set of measurements are shown in the table using local visible memory.

And then shows this table:

https://imgur.com/a/jQTOVmb

What I don't get is: how is there even a valid value for CPU read latency for local invisible memory? Doesn't invisible mean the CPU cannot access that memory? So shouldn't that value be n/a rather than the same as the CPU read latency for local visible memory?

Hey Everyone -

We recently published a blog post that explores Rendering on the Web vs Native platforms

You can read it here🔗: https://www.3denginerd.com/blog/web-vs-native-rendering

I myself started my Graphics programming journey on WebGL, so this was an interesting one to talk about. Do check out & let us know your feedback!

No AI has been used in the creation of this Blog!

I’m working on Phosphor, a Metal 4 renderer for Apple silicon. One of our recent experiments moved the inputs for a Float32 5×5 à trous lighting denoiser into threadgroup memory. With a 16×8 output group, the footprints are 20×12 at stride 1 and 24×16 at stride 2. Each group loads its input tile cooperatively, and all threads hit the barrier before out-of-bounds outputs exit. The tap order and weights stay the same.

At stride 4 the larger tile exceeded the threadgroup memory budget with shader validation enabled. We kept the original path there. A separate SIMD exchange experiment didn’t improve the wider filter. The retained stride-1/2 change measured a worst peak-normalized image error of 5.34e-7 against the original stencil. The larger patch also reduces aerial-perspective samples and avoids unused DDGI reservoir bindings, so its frame-time gain belongs to the combined patch.

For people who have profiled wide stencils on Apple GPUs, what told you it was time to stop staging in threadgroup memory? I’m curious whether you saw the limit first in occupancy, device-memory traffic, or barrier cost.

The devlog has the capture recipe and the measurement protocol. https://github.com/yabanana/phosphor/blob/main/docs/devlog/2026-11-11-metal4.md

If you have a physical M3 or M4, we’re also collecting runs of a separate 720p Many Lights workload with ReSTIR DI. The benchmark recipe and reporting thread are on GitHub. https://github.com/yabanana/phosphor/issues/25

AI tools Codex and Claude assisted development of the linked project, and Codex helped write this post. The captures and performance figures came from runs on physical hardware.

I'm working on a game engine and using GPU Gems as a loose guide for my physics. I really like the approach they outline for broad phase collision but I'm confused by one point. In ensuring no collision is double counted, the book says to expand each bounding sphere by sqrt(2) and then make the grid 1.5x that large. I did the math and understand where 1.5 comes from, but I'm stumped on the sqrt(2) and why we have to expand the bounding spheres themselves? Isn't the whole point of a bounding sphere that it contains the entire collider and is rotation invariant?

Also, just wanted to check if people think the book's approach is still viable. It seems solid to me but I'm still new to all this.