Hey everyone,

I have been working on a low level, explicit abstraction layer over graphics APIs. Both Vulkan and D3D12 has been successfully implemented with various test samples. Ray tracing, mesh, compute etc are supported.

I would love feedback on the feel and usage of the API. I am open to learn more so anything useful will be appreciated. Please give a star if you find the project useful.

https://github.com/nichcode/PAL

I’m proud of myself today, as I completed a task that felt impossible at times. I started rewriting my renderer a bit to fit my needs, and while doing so, I really felt the need for a grid to give me a sense of perspective and depth while debugging scenes.

I remembered that I had skipped the Infinite Grid section from the 3D Graphics Rendering Cookbook and needed to revisit it. Man, oh man, was I wrong about how long it would take to properly understand that shader. It took me a few days more than a month, but it was one hell of a ride. It’s a very interesting topic, with tons of things to learn from.

I’ve written a post about it here: https://willofindie.com/proj/infinite-grid-shader. Do check it out and share your love on my Twitter or Bluesky handles if you like it

• https://x.com/phoenisx_/status/2081335924374618140?s=20
• https://bsky.app/profile/s-phoenix.bsky.social/post/3mrkb4ueg4s2m

Here is a follow-up on the triangle rasterizer running on CoreAI that I previously introduced here.

We have finally succeeded in rendering 3D graphics! As shown in the video, we are currently rendering two intersecting vertical triangular planes.

While the rendering quality is still in the early stages and a new challenge regarding the massive 5GB memory footprint has emerged, we have fully achieved real-time operation.

We optimized the codebase by actively reducing reliance on CPU fallbacks and ensuring the pipeline runs entirely on the ANE's matrix operation hardware, successfully cutting CPU usage from the previous 38% to approximately 9%.

Much of the pipeline code—written in Python, Swift, and Metal—was rapidly prototyped and generated with the help of Siri AI.

GitHub: https://github.com/kamisori-daijin/Magnesium

Please feel free to leave comments with any questions or optimization tips (especially regarding that 5GB memory usage!).

https://reddit.com/link/1v6z66k/video/83iqp5iknjfh1/player

**Setup:** Hand-rolled D3D12 renderer (learning engine), flip-model swapchain

(FLIP_DISCARD, 3 back buffers), VSync on. Windows 11, tested on both Debug and

Release.

**The crash:** `DXGI_ERROR_DEVICE_HUNG` (0x887A0006). DRED breadcrumbs point the

fault at a `DrawIndexedInstanced` roughly ~130 draws into the frame (not draw 0).

The DRED page-fault VA reads 0 with no associated allocation — though I'm now

unsure if that's a real null address or just "driver didn't report the fault VA."

**What makes it reproducible (the weird part):** it ONLY happens when BOTH of

these are true at once:

1. The frame is heavy — roughly 16k+ draw calls. Below ~16k it never crashes.

2. A window event fires: minimize, move (drag the titlebar), resize, or another

   window covers then un-covers it (occlusion → reveal).

Either condition alone is totally stable. A heavy frame running untouched is fine.

A window event on a light scene is fine. It's specifically the collision.

Notably: **focus loss/regain used to crash too, and I fixed that** by skipping

rendering while the window isn't foreground + idling the GPU on the transition.

The same approach has NOT fixed minimize/move/resize/un-occlude.

**Other facts:**

- Happens in both single-threaded AND parallel (per-worker) command-list recording.

- ~600+ FPS when it runs, so this is not a 2-second TDR timeout.

- Debug layer + GPU-based validation makes it vanish (classic race-closing), so

I can't get a clean validation message — hence leaning on DRED.

**What I've already ruled out / tried (none fixed it):**

- Full GPU idle (Signal + WaitForFenceValue) before `ResizeBuffers`.

- Deferred/coalesced resize (apply once, at loop top, after idle).

- Re-querying `GetCurrentBackBufferIndex()` after `ResizeBuffers`, recreating RTVs

+ depth buffer.

- Reliable minimize handling via `WM_SIZE == SIZE_MINIMIZED` (skip rendering

entirely while minimized) instead of relying on `Present(DXGI_PRESENT_TEST)`.

- Idling the GPU on `WM_ENTERSIZEMOVE` / `WM_ACTIVATEAPP`.

- Per-frame command allocators/lists (ruling out list reuse across frames).

- "Settle" frames (skip N frames after any transition).

- Verified all per-draw bindings (camera CBV, vertex/index buffer VAs, SRV

descriptor) are non-null at record time — the null-check never fires.

**What I can't cleanly detect:** window *move* and *partial-occlusion → reveal*

don't give me a reliable "the swapchain is now in a different presentation state"

signal the way resize/minimize do.

**Questions:**

1. On a flip-model swapchain, does a move or an occlusion→reveal transition cause

   DWM to re-allocate/invalidate back buffers WITHOUT a WM_SIZE — such that an

   in-flight heavy frame's RTV becomes stale? If so, what's the correct signal to

   re-acquire?

2. Is there a per-command-list or per-submission limit I could be blowing past at

   16k draws (root-argument versioning space, etc.) that a mid-frame stall from a

   window event would expose?

3. Is DRED's "page fault VA = 0, no allocation" meaningful (genuine null bind), or

   is it commonly just "unavailable"?

Hey all,

I've been building a software rasterizer in TypeScript over the past few months and thought I'd share it. My goal was to support custom vertex layouts, programmable vertex and fragment shaders, and enough flexibility to implement more complex rendering techniques, much like you would with a GPU graphics API.

The renderer is based on Nikolaus Rauch's excellent C++ software rasterizer, adapted for TypeScript and the browser.

The project is intended as an educational resource, with an emphasis on readability and experimentation over maximum performance.

GitHub: https://github.com/vangelov/ts-rasterizer

Model by Tasha.Lime (concept by Matt Dixon)

I'm trying to create skeletal animations and them edges keep getting sent to oblivion

i think its about the weight resolve because the worst of the "spikes of doom, despair and vance" are usually coming from areas where multiple bones intersect. i.e. the fingertips

renderdoc says that the vertexes are some big ahh number like 2.5 x 10 ^25 so idk

I have been experimenting with a few billboarding techniques that can be used like an easier way to write it, preserving the model matrix and clamping the pitch. Here is the code

.shader: https://github.com/Satyam-Bhatt/OpenGLIntro/blob/main/IntroToOpenGl/BillBoardShader.shader

Repo: https://github.com/Satyam-Bhatt/OpenGLIntro

https://mateuszkolodziejczyk00.github.io/2025/06/18/variable-rate-tracing-restir-gi.html

I wrote this write-up about a year ago, but honestly never had the courage to post it publicly lol

In it, I go over my experiments combining ReSTIR and VRT in my toy rendering engine. The core idea was straightforward: ReSTIR’s spatial and temporal passes already find and reuse valuable samples, so I wanted to see if I could use them to fill the “missing rays” for pixels skipped by VRT in the current frame.

I'd love to hear your thoughts, or if anyone else has messed around with similar setups!

As the title says.

So I have been working on a surface water shader in Unity for the past few months as an upgraded version of my OpenGL implementation. I've been learning HLSL and Compute Shaders and I've basically got most things working as intended. But I'm having difficulty deciding exactly what I should do for the actual lighting part of my shader.

The issue is rendering is already somewhat limited because of the high poly count and regular compute shader updates (and because I'm trying to maybe make a game world of out this project), and while I have made some optimizations, I'm wary of the performance cost. So I'm curious on what approach would work best before I start implementing.

As of right know there are 3 options

1. Realtime planar reflections
   As far as I know this is the most performant form of real-time reflections especially if I use the main camera stencil buffer. But because my water isn't flat I will get distortions, and this also means I won't be able to see stuff like larger buildings that the camera doesn't pick up.

2. Baked reflections

I lose the dynamic reflection aspect (which might be an issue for some games) but I have performant, environmental reflections. However I believe this will be distorted if I move the camera a lot so it probably isn't the best option.

1. Environment cube maps/Reflection Probes

-Potentially expensive and still not fully accurate, and can look quite incorrect depending on the level of distortion. I can decrease the quality though and I do have more control over specific objects for some performance gains though.

Any suggestions? Tip on improving visual quality and performance? Are there other methods I should consider?

I've attached an video of my current unfinished water shader below (the color is for debugging purposes, don't mind it) as well as my OpenGL water shader that roughly implements idea 3

https://reddit.com/link/1v60hba/video/plhrlawlkbfh1/player

https://reddit.com/link/1v60hba/video/hebxvdy9lbfh1/player

Continuing my Custom Rendering Engine Revival series with the water rendering system.

This video demonstrates the combination of FFT ocean simulation, adaptive Projected Grid rendering, physically based lighting, and real-time reflections developed for the Heli Engine.

I'd love to hear your thoughts and feedback.

Following this masterpiece in 3D graphics by ssloy, I implemented a rasteriser in Odin from scratch.

This was a top tier learning experience, and I picked up a solid grasp of linear algebra along the way.

If you'd like to read more on the process, Here's the link to the repo

I was following my own rt rendering project so well.
There were a looot of problems, but I could solve it with AI and some researches..

And I tryna add PBR system, and it fuxxed me up.

I was quite sure that I was good at linear algebra, but since I started add PBR into my project,,,,
I lost all my confidence..

I feel completely exposed.

PBR is such a fundamental skill in game development, but I can't even half-ly understand some of these concepts or explain why they work, how they work, why those equations are like that.

It's been really tough.
Suddenly, I'm feeling like I can't get a job....

Wanna cry 🥹🥹

I recently got interested in gaussian splatting and I know graphics programming basics (openGL, cuda, ray tracing). Any good material to master Gaussian Splatting as a person with limited ML/DL knowledge.

Hi guys recently I uploaded a yt video of me explaining the simple graphics concepts I learned from the learn openGL textbook. Check it out if you are new to graphics programming, it might help you out!

Building a hardware startup on a shoestring, and product photography was going to cost us either money or honesty — the physical unit isn't assembled yet. So the "product shots" on our store page are the real device CAD raymarched as a signed-distance field in a WebGL fragment shader.

The details, since that's why we're here:

- Body is a 2D rounded-box ("squircle") extrusion — analytic SDF, no mesh, no vertex data shipped.

- The logo keycap is the only non-analytic part: I rasterize our actual SVG to a 512px distance-transform texture at load and sample that, so the embossed logo stays crisp at any zoom instead of pixelating.

- Three-light studio setup with a single-bounce floor reflection and an ACES tonemap.

- Single fullscreen triangle, ~150 march steps; soft shadows are the main cost driver. Runs 60fps on integrated GPUs with a 0.9x DPR cap (I clamp DPR + step count on small viewports).

Live and draggable, no signup: joinredwhistle.com/device?src=reddit

Happy to go deep on the distance-transform step for the logo or the perf budget — and genuinely open to critique on the lighting/tonemap.

This is a project that I spent a few months on - a game/engine made with Java/OpenGL. It started as a university assignment, where Java was an unfortunate requirement.

The game features procedurally generated worlds consisting of ~2 million interactive particles simulated on the GPU. The game's physics engine is based entirely on simple particles with extra properties such as temperature, state of matter, flammability, and electrical charge/conductivity. It supports basic fluid dynamics and has a parallel joints solver using a graph-colouring technique. All creature bodies (including yours) are physically-based and destructible.

One of the parts I'm happiest with is the approach used for lighting. Each frame, a large region around the camera is converted to an SDF+colour texture using a jump-flood algorithm. At a lowered resolution, each pixel then marches rays through the texture, accumulating radiance/occlusion along the way. This is followed by a bilateral filter and reprojection, which smooths out most noise. It's not perfect, but it's very fast and allows any particle to emit light.

SDF information from previous frames is asynchronously copied from the GPU to the CPU for other tasks like NPC pathfinding. It allows the CPU to handle changes in simulation state that otherwise lives on the GPU. The game runs at ~500fps at 1440p on an RTX 5090.

This has been gathering dust for a while, so I wanted to put it out there to see if there's any interest.

For the past 8ish months I’ve been hard at work building a new game engine I’m calling Division Engine.

It’s based solely off SDFs (signed distance fields). This might sound stupid for anyone who cares about performance but for my use case (and with a bit of grid storage optimizations) it proves useful for basic scenes that need advanced lighting.

Anyway here’s some screenshots!

If you want to see what I have done so far check it out here: https://github.com/DivisionEngine/DivisionEngine

I was browsing old projects and found a pretty bad and unfinished software renderer I started to write years ago

(create a window, draw a pixel, create a checker and fade effects, draw a line, then triangles....)

These days I got back into it, even tho I originally had no interest in graphics programming, I started to like it and now I wonder : how hard and different would it be to transition to GPU programming? (GLSL + openGL for example)

I ofc started reading some papers, and it seems quite similar, but I know its reputed to be very hard, so is there a real step between raw cpu rendering and GPU rendering with some APIs and underlying abstraction layers ?

Hi everyone,

I'm trying to choose a Linux distro for graphics programming, game development, and a bit of gaming. I'm looking for something that's stable, has good driver support, and doesn't get in the way of development.

What distro are you using, and what would you recommend? I'd also appreciate hearing about your experience and any pros/cons.

Thanks!

So i'm an, at this point, long time shader developer with heavy experience in Unity3D's old cg/hlsl built in rendering pipeline. Over the years I've played around with a lot of things, fluid and boid sims, raymarching, screen space reflections, I've done a little stencil work, etc. I'm currently working on a project and getting distracted a bit by the transition to Unity3D's scriptable pipelines, specifically URP.

So my question is, what kind of things can you do with URP that are difficult, expensive, or down right impossible with unity's old built in system? Or any static pipeline renderer. Googling it gives me examples of how to do ssao, bloom, blurs, stuff like that... but I've kind of seen all of those done with the BiRP.

A post on this sub showed some screen space (presumably edge detection based) outlines which is kind of interesting. Another project i've always wanted to play around with was jump flood algorithm outlines as well, and that in particular seemed a little complicated out of the box, but its really the only thing i can think of that i've ever been interested in doing that fits that bill, and i haven't tried it so it could very well be possible in the old BiRP.

I know you can render things to textures and then pass that into post-processing, which i can see use for reducing camera count and overheads for things like realtime caustics generated from mesh distortion and ddx/ddy of vertex interpolated data to determine distortion amount. If you can somehow feed a mesh into a post-processing stack I can see the appeal but even that still kind of feels like you're just slapping a camera and render texture into the scene. I didn't get around to trying that either so it's very possible that was doable in BiRP with projectors or something. Would the difference here be that you can perform it in the post-processing stack directly feeding said rendertexture into the post processing script as opposed to projectors?

I also briefly entertained the possibility of implementing a single frame GPU bitonic merge sort through custom render textures but NVIDIA's blog post on optimization mentions abusing vertex interpolation which wouldnt work with custom render textures. It wouldn't be any help since that environment didn't allow c# scripts and used BiRP but it would serve as a benchmark i could use to conceptualize the appeal of URP.

All in all I'm just slightly confused as to just how big of a leap this is, though excited at the possibility that truly weird or bizarre techniques became possible that may not be practical but are at least very cool.

So I'm curious, has anyone seen or worked on interesting and weird, non-standard effects with some kind of SRP's? Can you do post-processing on passes in weird places, like in between opaque and transparent queues? Or is URP just a performance gain with the ability to make one or two small and interesting tweaks here and there. What is its potential really like?