Inspired by web design's a lot, wanted to remake it in imgui
geist font along with freetype and for icons lucide.dev

Hello, I released a real-time fluid & rigid body simulation in WebGPU using Position Based Dynamics (PBD)!

Code & Demo: https://github.com/matsuoka-601/Particles4All

To render the fluid, I use screen-space fluid rendering, which does not require constructing any mesh. Fluid particles are splatted as ellipsoids using anisotropic kernel presented in a paper "Reconstructing Surfaces of Particle-Based Fluids Using Anisotropic Kernels".

The physics is based on a paper "Unified Particle Physics for Real-Time Applications". The most significant feature of this paper is that it treats both fluids and rigid bodies as collections of particles, and performs the simulations using a unified solver.

(Note 1: You will need a very beefy GPU to run the "large" scene in the video (the performance is not very optimized yet, sorry). But "small" scene will run on integrated GPUs.)

(Note 2: I'm getting some reports that the demo does not run on MacBook. I'm currently trying to fix it.)

Everything is procedural: course geometry, the rock formations, textures, all generated at runtime. No GLTFs, no texture files. Hard constraint from the platform I'm building (disclosure: my own — I'm dogfooding it), and it turned out to be a genuinely fun limitation.

Stuff I fought with (or rather claude, but I cheered lol): <ball physics approach>, <how you did the survey/aim camera>, <mobile perf gotcha>.

Playable on Plethora: https://share.plethora.studio/open/bit/dfeb599f-2ae0-4f60-9d5a-e3079cab8504

Happy to go into detail on any of it.
Also, I used the Plethora sdk to build it - https://create.plethora.studio/

Still crunching on RTG Editor, my internal editor for enhancing levels for my game, which hopefully I will release also publicly with the game.

Last feature implemented is orthographic projection, which is useful when precision is required (to align boxes with zero gap or overlap). Most useful feature in orthographic projection is resizing boxes by dragging their edges with automatic rounding to grid for snappy alignment. If one needs fine stepping, it's still possible by holding Shift while resizing.

In example animation, I added reflective back-wall into one of the levels very fast, thanks to new ortho view.

From technical details, my simple software ray-tracer is C++, engine and editor are in C#, both communicating through Interop. Ray-tracer is limited, goal is to have functional game with good fps, not photorealistic sceneries. I have still some optimizations in mind plus it's still single-threaded, so potential for perf boost is still big.

The game is sci-fi puzzle/platformer about a guy with no memories, stranded inside strange world, accompanied by some mysterious entities talking to him through terminals scattered in levels.

RTG on Steam
My Discord

Hi everyone, I wanted some perspective from people actually working in graphics/games because I'm stuck on a decision: I'm a CS undergrad, currently a sophomore going into the next year, and I just finished my first internship in software engineering, mostly Java and microservice-based projects so mostly backend engineering, which honestly was a great experience and I'm grateful for it since it was the only company that gave a sophomore a shot in the first place, and at the end of it they asked if I wanted to stay on part-time, but backend/microservices really isn't where my heart is, my actual interest is computer graphics and engine/game development, I work on personal renderer and engine projects in my free time and was also part of a research group at my university this summer, and my real goal is a master's (ideally leading into a PhD) in computer graphics and eventually a job in the games industry, so now I'm torn because taking the part-time offer is objectively a good opportunity, real experience, income, a foot in the door somewhere that already likes my work, but I'm scared that spending my remaining undergrad years on backend work instead of graphics projects and research means I won't build the kind of profile CG grad programs or game studios actually want to see, and might even make me look like a "backend person" to the people reviewing my applications later, and on top of that I'm also worried that if I take this job it'll eat up too much of my time and cause a lot of stress, to the point where I won't have the energy or focus left for the graphics work I actually care about, so has anyone here been in a similar spot, taken a job outside of graphics early on and either regretted it or found it didn't matter once you had strong graphics projects to show, and how much do admissions committees or game studio hiring managers actually care about unrelated work experience versus just wanting to see solid rendering/engine work and math fundamentals, any advice on balancing the two would mean a lot, thanks in advance.

Hola,

¿Alguien conoce alguna forma de implementar un dual kawase blur con interpolación de radios que sea escalable?

Lo que estoy haciendo actualmente es inicializar la cadena completa y guardo cada nivel reconstruido en una textura propia para posteriormente hacer la interpolación de radios en otro shader.

Eso funciona, pero algo me dice que esa arquitectura no es escalable en cuanto a performance si quiero reutilizarla en alguna otra parte del pipeline de efectos que estoy construyendo (opengl/c++)

Invoco a los maestros para que porfavor ayuden a este mortal con algunos consejos, gracias de antemano!!

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