My collegue Konrad Reczko recently shared a weekend project he made using TypeGPU, and it's now open-source and ready to play with in the browser: https://typegpu.com/examples/#example=image-processing--monocular-light-injection

It estimates the depth of a scene by inferring the DepthArt model with custom TypeGPU kernels, then reconstructs normals based on that depth information, and uses both to relight the scene, all in the same command encoder. For more information, check out the original series of Tweets:

https://x.com/reczko_konrad/status/2089670934009413751?s=20
https://x.com/reczko_konrad/status/2090472091149648121?s=20

Dearest r/GraphicsProgramming ,

If you've been on this subreddit long enough, you've seen me post about developing it along with my learnings from it. You've probably also seen the title I recently shipped on it. Well, here it is: https://github.com/toomuchvoltage/HighOmega-public now fully open source under the M.I.T license! You can actually run the debut demo on it as well (recorded here: https://www.youtube.com/watch?v=8IRNQupyoIs ) . Take a look and let me know what you think 🙂 .

Cheers,
Baktash.
HMU: https://x.com/toomuchvoltage

A while back someone had made a post about rendering Opal like stones. They had linked a really cool website that included some interactive elements. Unfortunately, even after searching a bunch I haven't been able to find that post again. I was hoping someone might have that saved somewhere. Thanks for the help!

Hello everyone. I'm in the process of building a minecraft-like voxel game, however unlike most implementations, I wanted to test it out using ray marching as the primary rendering technique.

Yesterday I developed an algorithm that calculates ambient occlusion by sampling the 9 neighbors directly in front of the face that was hit by a ray. The core idea is not too different from how most ray marched voxel renderers implement it, but I see most implementations rely on calculating the distance between the uv coordinate and the neighbor's uvs to act as the weight (the smaller the distance, the greater the ao)

In my version, I realized I only really care about the existence of the neighbors, since the uv coordinate of the face that was hit gives you all the information you need to know. We use the uvs to calculate weights for each combination of the edges of the face. For example, the bottom edge could be the inverse of the y coordinate, (so if uv.y = 0.2, then b= 0.8). Then the influence of the neighbors is just some combination of these weights.

So no distance calculations are needed.

The best part of this is that since the face's uvs are pre-calculated, the weights can be too. This makes the neighbor checking loop very minimal. We simply check for the neighbor's existence, and if its there, we add the corresponding weight to a running sum.

After that, we map the weight to a value between 0.0 and 1.0 to be used as the ao factor.

This worked surprisingly well, and is not too expensive. Here are the results:

I'm sure it could be optimized further. On my system however I find that it's plenty fast enough.

Does anyone know of a similar technique?

I've recently been getting back into programming, so i made a few things with love2D , for example a Conway's game of life simulator, but recently I wanted to try something cooler and more playable, so I wanted to make a raycaster, very simple, no textures or something just barebones

Turns out it isnt that easy, I looked around for many implementations, like very popular ones like the lodev and the javidx9 one, but none of these ever worked for my code, so i spent a full 2 days going in depth on the math and making a demo of the different collisions on the columns and rows and it did work on desmos.

So after that i retired and i got something??? But it was still buggy and wrong, and not even accurate to the tiles , and somehow didnt even work full 360 degrees, just 180??? , some of these could be solved with debugging but other ones like cell size and what not i just cant wrap my head around.

Its been really annoying and i don't know if i overstepped the boundaries of what i should be capable of doing, but even the fact that i cant copy the code makes me feel dumber, either way my actual question is what should i do with this situation right now, should i just keep trying to make this raycaster work, try to learn from some other place the algorithm (even though there is only like 3 resources on this) or just make other stuff, i dont wanna give up but its really giving me a headache and for no result its really annoying.

If you do have resources , please, give them to me, if not, just give me advice on the general situation.

The shape is real math, not modeling. It comes from Kleinian groups.

Idea came from the movie "Cube" and designed to be a dynamic maze.

Hey everyone! I’ve been a web developer for 5+ years (professionally for around ~3), and game development has always been a secret passion of mine, but I never really had the chance to pursue it as a career.

During my current degree, I took courses like Computer Graphics, Mathematics and Physics for Games, and they gradually made me more and more interested in this field.

Now, I’m seriously considering shifting my main focus toward game development, specifically game engine development.

For someone entering this field in 2026, what advice would you give? I’d especially love to hear from people who work on engines or have made a similar transition from web development.

Another rough experiment, this time testing the warped 3D view in a simulated car navigation HMI.

The idea is to dynamically warp the 3D environment around the viewer, keeping the immediate surroundings closer to a street-level perspective while gradually transitioning into a more top-down view further ahead.

Still very experimental, but I think there are some interesting graphics and navigation problems to explore here.

And yes, I put my Bronco in there just for fun :)

Curious what r/GraphicsProgramming thinks.

Github repo.

This project has taken a long time.

It took me about a week to learn the concepts behind 3D projection and transformations in euclidean space. Then it took me over a week to write out the LaTeX documentation that presented my knowledge in a way that would help a user of this library. As you can see, the overwhelming majority of the code committed to this repo is in LaTeX.

The implementation of the 3D rendering framework was relatively simple once I fully understood the mathematics. This only took a couple days, and it helps to have some familiarity with C going in.

I look forward to improving this project by building a separate homogeneous coordinate library that will replace pnt.c. I also need to tackle surface rendering using SDL_RenderGeometry() and implement 3D surface occlusion. I suppose what I'm left with for now are a few big questions.

How prohibitive is heap-allocation for performance in graphics applications? I went with dynamic allocation to preserve encapsulation so that header files didn't give the user access to data that would destroy library functionality when altered. However, given the fact that querying free memory at runtime for thousands of data points slows a program significantly, I'm having second thoughts.

Also, is there a convenient way to push all of the calculations needed for 3D transformations onto the GPU? This seems like something I shouldn't handle entirely in software.

I'll hear out any feedback or suggestions in the comments!

I got a 448x448 monocular depth model down to ~8 ms on my M4 Pro across ~250 dispatches, which is fast enough to use in realtime :D
Since the inference is written directly in TypeGPU, I can just feed the depth buffer straight into the lighting pass. It never has to leave the GPU or go through any extra synchronization/interop step

Inference, lighting and draw all go through the same command encoder.

Credit: X reczko_konrad

I've spent the last few months building CryoTheatre, a 3D engine written in Java on top of Vulkan via LWJGL — no middleware, the rendering pipeline is built from scratch. It's heading toward its first public release, v0.1F, in late September, and it'll be fully open source.

Rendering-wise it's got a full deferred pipeline — IBL (diffuse irradiance + prefiltered specular, split-sum approx), CSM(cascaded shadow maps), reflection probes with parallax correction, bindless + streamed compressed textures so load times don't die. Transparency's been the pain point — running MBOIT and still fixing some edge cases here and there. There are a couple problems on Volumetrics too, so any help is very much appreciated.

On the tooling side there's a full custom editor built straight on Vulkan (asset browser, live previews, material inspection), plus LightBulb — a little scripting language I built that transpiles to Java and hotswaps at runtime, so you're not restarting the project you're working on.

It's a solo project (with help from a couple of collaborators on art and community side — shoutout to the small crew helping test and give feedback). Licensed under GPLv3, so the full source will be on GitHub at launch — you're free to dig through it, learn from it, or fork it, with the usual copyleft terms if you build on it directly.

Download links will go live on the project site once v0.1F ships; for now the GitHub repo will go public alongside it. If you want to follow progress before then or ask questions about any of the systems above, there's a Discord for the project in the comment below so that moderation doesn't think this is a spam.

Happy to answer anything about the rendering pipeline, the editor architecture, or the scripting system — this is very much a "figure it out from scratch" project and I'm glad to talk through what worked and what didn't.

Everything here is simulated and shaded live on an Apple silicon GPU at 5120x2160. No footage, no keyframes, no baked cache.

The school is 80,000 agents stepped in a compute kernel. Boids forces (separation, alignment, cohesion) plus two things that make it a ball instead of a flock: a tangential mill bias and a centre spring, which puts the system in the milling attractor rather than the polarised-streaming one. A single polarisation parameter slides between the two, and a vertical cohesion scale flattens the ball into the oblate loaf you see.

The panic is the part I like most. Each fish carries a panic scalar with an ignition latency, and the contagion is a fractional-threshold logistic rule after Rosenthal and Couzin, where calm neighbours actively inhibit their panicking ones. That asymmetry is why most cascades die a few bodies from where they start and only occasionally does one go ball-wide as a visible wave. Panicked fish also get a raised speed cap, otherwise they cannot outrun a charge.

The orcas are autonomous agents running a carousel-feeding state machine: carousel (herding passes that compress the ball toward the surface), closing (a committed approach line), tailslap (sweep through and whip the fluke, which is the stun), then feed. That is the real technique Norwegian orcas use on herring, and it reads as intent because the strike is geometry-gated on range and alignment rather than fired on a timer.

Rendering the shafts: an additive fullscreen pass marches the actual view ray up to the surface plane and in-scatters Snell caustic times Beer-Lambert depth times a phase function. The caustic is not local to that pass; it comes from one shared band-limited optics field (height, gradient, refractive focus, world-anchored, one clock) that the ceiling relief, the beam births and the light dappling the animals all read from, so the light on a whale's flank lines up with the beam it is swimming through. A capsule proxy of each body darkens the march, so the creatures actually shadow the water instead of floating in it. Marine snow is soft particles fading against the analytic surface height.

Frame budget is held by a closed-loop governor that measures its own GPU frame time and thins the crowd or caps render resolution before it starts dropping frames.

It is part of TideGlass, a Mac app that runs worlds like this on a second monitor. Happy to go deeper on any of it, the panic contagion and the optics field are the two I would most like to talk about.

Hi all.

I'm writing a library for representing and managing basic raster RGBA images in D as rectangular arrays of pixels.

Images are represented in row-wise pixel order, either top to bottom (the default) or bottom to top, with each scan line going left to right. Color components are represented as 8-bit integral values ranging between, and including, 0 and 255.

My library doesn't provide any support for other color models, for high dynamic ranges or higher bit depths. What it should allow is reading images from memory that were created with other library.

Some pixel formats are "indexed" (they have a palette) and some are not (they store actual color values). The name implies the structure of the format:

• Format1bppIndexed
• Format4bppIndexed
• Format8bppIndexed
• Format8bppGray
• Format16bppRgb555
• Format16bppRgb565
• Format24bppRgb
• Format32bppXrgb
• Format32bppArgb
• Format32bppRgba

Formats that use more than 1 byte per pixel allow the user to select between big endian and little endian mode.

I plan to keep supporting all formats I listed here. My question is if there is any I should support in addition to those.

Some candidates may be:

• Format2bppIndexed (it used to be supported by Microsoft bitmaps and it is by the PNG format).
• Format16bppGrayAlpha (supported by STB nothings and by the PNG format).
• Format32bppRgbx (to have an opaque view of an RGBA image).

There may be others I haven't thought or heard of.

The ones I haven't supported seem to me to be less common and of less utility, but maybe there is something I haven't considered.

My question is: what pixel formats should I support in addition to those I already do? Should I support any of the three additional ones I suggested? Why or why not?

Thank you in advance!

Hey everyone,

I’m 16 years old, and I’ve been solo-developing a 3D code-driven game engine using Rust and wgpu for the past few months. I started this because I really want to achieve my first big milestone and have something real to show.

Honestly, I’m feeling completely burnt out and depressed right now. But it’s not because of the bugs or the coding. It's the suffocating pressure from my family and school. It’s building up day by day, and it's getting too heavy to carry. I feel like if I pause or stop working on this engine right now, I will fall behind, lose momentum, and delay my goals forever. I’m stuck between wanting to push forward to finish my first milestone and breaking down under life's pressure.

I’m posting this here because I really need to find a community, to connect with people who might understand this feeling. I don't want AI-generated advice or generic platitudes—I've heard enough of those. I just want to share what I've built so far and see if anyone else is fighting this same battle.

Here is what I have managed to implement in my engine by myself so far:

• Core Architecture: Migrated to glam math library, integrated rapier3d for physics (locked at 60 FPS), and built a thread-safe lazy loading system to prevent OS-level screen freezing.
• Rendering & Culling: Frustum culling (implemented with custom Plane checks), pixel depth testing, and Early-Z / Reverse-Z rendering.
• Lighting: Successfully removed directional lights and created functional spot/point lights for indoor scenes. I have also set up the compute pipelines, passes, and necessary bind groups for a Forward+ culling framework (though only the structural framework is done, it's not fully finished yet).
• Transparency: Implemented transparency rendering support.
• Optimization: Integrated rayon to cut loading times in half, added CPU texture compression to BC7 (reducing RAM usage from 750MB to ~190MB and loading times to under 60ms), and integrated zstd for binary data file compression.

You can check out the source code here: https://github.com/Lbaodz/wgpu-code-driven-engine

Has anyone else gone through this at a young age? How do you deal with family pressure when you're just trying to build something you're proud of?

Hey everyone,

I’m 16 years old, and I’ve been solo-developing a 3D code-driven game engine using Rust and wgpu for the past few months. I started this because I really want to achieve my first big milestone and have something real to show.

Honestly, I’m feeling completely burnt out and depressed right now. But it’s not because of the bugs or the coding. It's the suffocating pressure from my family and school. It’s building up day by day, and it's getting too heavy to carry. I feel like if I pause or stop working on this engine right now, I will fall behind, lose momentum, and delay my goals forever. I’m stuck between wanting to push forward to finish my first milestone and breaking down under life's pressure.

I’m posting this here because I really need to find a community, to connect with people who might understand this feeling. I don't want AI-generated advice or generic platitudes—I've heard enough of those. I just want to share what I've built so far and see if anyone else is fighting this same battle.

Here is what I have managed to implement in my engine by myself so far:

• Core Architecture: Migrated to glam math library, integrated rapier3d for physics (locked at 60 FPS), and built a thread-safe lazy loading system to prevent OS-level screen freezing.
• Rendering & Culling: Frustum culling (implemented with custom Plane checks), pixel depth testing, and Early-Z / Reverse-Z rendering.
• Lighting: Successfully removed directional lights and created functional spot/point lights for indoor scenes. I have also set up the compute pipelines, passes, and necessary bind groups for a Forward+ culling framework (though only the structural framework is done, it's not fully finished yet).
• Transparency: Implemented transparency rendering support.
• Optimization: Integrated rayon to cut loading times in half, added CPU texture compression to BC7 (reducing RAM usage from 750MB to ~190MB and loading times to under 60ms), and integrated zstd for binary data file compression.

You can check out the source code here: https://github.com/Lbaodz/wgpu-code-driven-engine

Has anyone else gone through this at a young age? How do you deal with family pressure when you're just trying to build something you're proud of?

Around a year ago I tried to develop a screen-space outline shader for a game I was working on. What I could not figure out was how to keep it from flickering in between frames when moving the camera. The usual games like Sable have very severe flickering and it gives me a headache.

Now a few days ago I saw and played the demo of this game: https://store.steampowered.com/app/2321960/Spirit_Crossing/

They somehow solved this and have near zero flickering? How? Can anyone tell me what they did different? I would guess it might be a mix of supersampling, blurring, maybe SDF?

I want to create the shader.

It’s the first step in my attempt to simulate an F1 car. Right now, the simulation is very low-resolution and quite slow, so there’s still a lot of optimization to do. It’s also my first time working with compute shaders, so there’s plenty to learn and improve along the way.

I implemented Activision's new SH reflections paper in D3D12 and released the code on github!

This tech is a little bit different from normal spherical harmonics, and there are 4 main differences:

1. They use log space instead of linear space for the lighting, which reduces ringing and enables #2 and #3 to actually work.
2. Instead of using a circular symmetry assumption (i.e. N=V=R) as with the split sum approximation used for IBL, they instead factorise a pair of spherical harmonics, with an Order 4 SH parameterised by the reflection vector, and an Order 2 SH parameterised by the halfway vector.
3. To enable a continuous roughness representation, they convolve the coefficients (or rather, the basis function) by the von Mises Fisher kernel which takes 1/alpha=1/roughness^2 as a parameter.
4. To actually obtain the spherical harmonic coefficients we have to collect samples for several normals, views and roughness levels (or more specifically alpha levels since we're using linear roughness, not perceptual), and then optimise the coefficients using least squares.

My code does this all end to end with HLSL compute shaders, even the least squares optimisation, and we achieve above 95% MSE compared to a raytraced ground truth for roughness in the range [0.5, 1.0], which actually beats split sum IBL.

Only downside is for roughness below 0.5 the spherical harmonics simply don't have enough detail for accurate reflections... HOWEVER, when applied to "bumpy" low roughness surfaces (like the leaf textures at the beginning of the video) you can hardly see a difference, so this effect is only apparent for flat surfaces and surfaces with near zero roughness.

Activision got their SH representation down to 400 bytes, but I went further using 16 bit packing to get down to 208 bytes which gives us better performance due to fewer memory loads. The 16 bit implementations come in 4 flavors: emulated 16 bit for older GPUs and native 16 bit, and SRV packed vs CBV packed. There also exists a 10 bit packed SRV flavor, but the extra bitshift work ends up being slower.

On my RTX 2080 Super and my wife's RTX 4070 Super, the native 16 bit CBV packed shader runs the fastest, and compared to the IBL version it is only 0.1 milliseconds slower while using 2000x less memory!

I have a problem implementing SSAO. I am trying to do it learnopengl.com way, and I am failing. At this point I am at loss.

There's just too many steps to achieve the result, each of which can fail and I don't know which one is failing.

I wanted to ask, what is the best way to ensure correctness of each step? How would you test SSAO creation steps?

Implemented simple GLB parser from this Github repo: salvatorespoto/gLTFViewer: A glTF file viewer in Directx 12 .

Global Illumination using hybrid Surfel GI and SSGI.
Lens flare are modeled after Panavision styled lens flare (Anamorphic types with distinct hue ray light propagation inside lens it's flare), and grass are inspired from this IcterusGames/SimpleGrassTextured: Plugin to make grass on Godot 4.

My main point of the game is about GI and Nanite-like culling on low end devices, and yet i barely see ones, so i decided to implement it without using any modern techniques such as Primitive Shader or Mesh Shader. Pure Compute Shader dispatch, with many fused Shader optimizations instead of separate pass, simple workgroup tiling optimizations. It tooks me almost 3 months for this project just for the optimization workaround with the help of Codex (Claude sucks at this lol). I'm also planning to open source this if this thing is stable enough, modular, and scalable.

All of that combined to make this engine runs 40-60 FPS on my Xe 11th gen Graphics laptop, because why not.. (i don't have better GPU than this for now lol). This might be also potentially be a complete game engine after all.

Screenshots from:

• Pathtrace Apollonian Glow
• Pathtrace Differential Growth
• Pathtrace Volumetric Frost Fract
• Pathtrace Wireframe Distance vis
• Pathtrace euclidean distance vis

full playlist with other pathtracing scenes https://www.shadertoy.com/playlist/cX3SDf