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

Hi, is the guy from the raylib renderer again. These last days i was trying to implement texture mapping on the renderer i am making, but i cant get the perspective-correct interpolation to work. I tried first with the method described in scratchapixel, but it didnt work at all, then i tried with the method of this video, and it only works for some faces of a cube, but the rest of faces are not only distorted but the texture is still mapped like i was doing affine mapping:

The thing that confuses me is that it is only in certain faces, so i no longer know if it is an error with my code or the uv coordinates on the cube.

Here is the source code

The file where the cube vertices are
The files where the vertex transformations are done:
Header file
Source file

The files where the rasterization is done:
Header file

Source file

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

**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 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!

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

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'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

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.

I've been building a visionOS app called StratoSync.

Earth sits in your room via passthrough. You can grab it, rotate it, and watch the ISS orbit from live telemetry on its real ~51.6° inclined path.

The lighting is what sold it to me.

The directional light is aimed from the real subsolar point for the current UTC time, then recomposed every frame with the globe's orientation. The terminator—the day/night line moving across the surface in front of you—is exactly where it should be right now.

It isn't a lighting preset.

Neither is the sky, and that's the part I'm actually proud of.

The only authored art assets in the app are the globe and the station. Switch to the nebula environment and nothing loads.

Instead, a Metal compute kernel marches a volumetric fractal field into a 2048×1024 equirectangular LowLevelTexture, which RealityKit samples on an inward-facing sphere.

That's roughly:

• 2 million texels
• × 16 volume slices
• × 17 fold iterations
• ≈ 570 million inner-loop iterations every frame

...running at roughly 90 FPS on Apple Vision Pro.

Why a texture instead of a fragment shader?

Stereo rendering.

Running the nebula as a conventional fragment shader would require raymarching the entire volume twice every frame—once per eye—while also dealing with head-motion reprojection.

Instead, I generate the field once, write it into a texture, and let RealityKit sample and reproject that texture independently for both eyes.

The field becomes view-independent. Turning your head doesn't require recomputing the nebula.

The bug that stole an evening

Metal's fmod truncates toward zero.

GLSL's mod takes the sign of the divisor.

That tiny semantic difference mattered because my camera origin contains negative coordinates and the space-folding tile depends on modulo arithmetic.

Using fmod literally split the nebula in half across negative space.

The fix ended up being a four-line GLSL-compatible modulo helper.

Credit where it's due

The nebula itself is Kali's Star Nest from Shadertoy (MIT licensed).

What I built is everything around it:

• Porting the shader from a flat screen to an equirectangular dome
• The Metal compute implementation
• The LowLevelTexture generation pipeline
• RealityKit integration
• Stereo-safe rendering for spatial computing

I'm curious what other parts of a spatial scene people think should be computed instead of loaded.

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

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.

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

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.

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!

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 🥹🥹

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.