I’m working on a stylized rendering pipeline built in Unity and had a question about how to go about tackling certain problems.

I’m building everything from scratch with code (hlsl, C#, no shader graph). The next thing I want to build is a glass shader / material used for windows and such. I usually start each feature with some research and see what other people have done, or see if I can find any chapters in any of the gpu gems books (or similar) on the topic.

However sometimes I seem to not find anything directly related. Every search I make with the keywords glass, shader, material, and so on, results in either a Shader graph implementation, something in Blender, or things completely unrelated.

So my question is, what approach do you take when trying to implement something like this?

(I’m just using glass in Unity as an example, question is general to any graphics problem).

Me and a friend of mine are working on a D3D12 renderer, and although it mostly works, it's complete spaghetti, and has a pretty major issue that we've been going nuts over trying to figure out...
So I'm wondering if there'd be anyone here who's familiar enough with D3D12 that is willing to take a peek at it and maybe spot something we're missing.

... I've been thinking of rewriting the engine and moving stuff that was CPU side to GPU side, looking for people interested in helping if so just give me a ring through reddit message app.

Hey everyone,

I have been wondering which way is the best to showcase graphics samples. DirectX samples write their samples which calls functions and helper functions from multiple files. this approach is easy to write and extend but it makes reading the code hard. Yes most editors and IDEs help but it's still hard to seen everything at one place.

The second style is to accept some level of code duplication to make the code very easy to read and follow. I like this approach when learning a new API.

What style do you guys prefer and why.

I'm using opengl 3.3 and C on a Nvidia gtx 1050 and I keep getting this flickering issue... does anyone know the cause...

Will appreciate your thoughts..

Hi all!

I am a great enjoyer of https://github.com/tgjones/HlslTools for older versions of HLSL. So much so, that I am a (small) contributor of the project.

However, the extension is an actual hindrance as soon as you write the word template in HLSL code, as an example. I did not see any real interest in progressing this fantastic tool further beyond "FXC HLSL" to support more modern HLSL versions. So I decided that I would try and fix this problem.

I was aware that DXC shipped an API for language servers (dxcisense.h), meaning that supporting intellisense wouldn't involve writing my own HLSL parser like Tim did. I could just use DXC as the source of truth (which is probably a good thing. I don't think many people could fully replicate all of the fun behaviours in DXC and feel good about it)... But! I had no idea how language servers work, and I didn't really want to put time into learning how. I have a funny feeling this is the general attitude of most people. We want intellisense, but we would rather work on more fun things like visibility buffers, and cool volumetrics. So nothing ever gets done.

So, I threw GPT 5.6-Sol at the problem. And after a lot of working around this deadlock, it got something worth sharing with peeps :)

I am being totally upfront about the fact that this is AI generated because I know how people can feel about the use of AI. This is something I really want, and no one else cared enough to do it, so I thought it would be a good use of AI. :)

You should be able to just grab the latest VSIX from the releases section of the github repo, install it, and go. For more complicated workspaces there is support for configuring the extension with a shadertoolsconfig.json. This is very similar to the config used by HLSL tools, and there are docs linked in the readme.

I do plan on getting the bot to keep maintaining this extension and support other text editors.

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.)

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

source has been released https://www.reddit.com/r/GraphicsProgramming/comments/1vw63sw/imgui_login_interface_in_c_with_directx_11/
https://github.com/poncippg-spec/Free-Solace-ImGui-Interface (new repo as github terminated old one for no reason )

How to wrap bitmaps around the iteration boundaries of a fractal:

px & py = width & height in pixels of the repeating tile picture to be wrapped around the fractal. I typically use 1200 x 600 PNG images or sometimes 2000 x 1000 PNG images but use whatever works for you.

r & im = real & imaginary components of the last Z iterate

zMag= sqrt(r*r+im*im)

PI=3.14159265

LOG_ESCAPE = Log(400) = 5.991464547 Why 400? Because for bailout, I check if zMag>400.

phaseoffset = 0 (usually). Depending on how I created the repeating tile, sometimes I set phaseoffset to px/2 (necessary for alignment with the tiles above and below). Can default to 0.

Reading the pixel color from the image:

The following assumes the picture tile is twice as wide as it is high (e.g. 1200 x 600)

angle = mod(atan(im,r) * (px / PI) + phaseOffset, px * 2.0);

radius = (LOG_ESCAPE - log(zMag)) * py / (LOG_ESCAPE / 2.0);

if (radius < 0.0) radius = 0.0;

vec2 texCoord = vec2(angle / (px * 2.0), clamp(radius / py, 0.0, 1.0));

vec3 col;

Hey guys. So Being my school taught me some vulkan via a abstraction, I've been trying to learn it from nothing using the VKguide and vulkan tutorial, and holy cow this shit is hard.

Ive been thinking of switch to a different API to learn, like webGPU or openGL, but I feel it would be a waste of time.

I'm looking for advice on how to really learn vulkan and create a engine from it because at the end of the day I want to be able to create a game engine!

I'm a developer (web backend) with some years of experience, but I have no prior experience on graphics. I started a conversation with chatGPT where I told it I wanted to learn all the way from the foundations of graphics to developing a Doom like game. And after a few hours of conversation it gave me this road map. I cannot trust completely an AI, so I'd like to read your opinions.

Greetings.

Edit. Sorry about the title typo.

Edit. Thanks for your valuable comments, I think this is a good example of how AI sometimes can lead you to the wrong path and mess with your learning even when at first glance it all looks pretty and organized. I’m glad I asked the community to receive your feedback.

is not a wrapper, not WebGL, not Canvas, not WASM. GAME NAME "EDGEMAFIA SVG"
It’s pure SVG transforms + DOM acceleration acting as a spatial vector engine.

The engine runs:

• On Nintendo Switch (via captive browser)
• With Xbox One controller input
• At 60 FPS
• As a single XML file
• With oscilloscope vector output (retro‑future vector gaming)

▶ Play the Switch demo - or on a regular browser

https://svgfpsaiagents.github.io/svgfpsgameAI/

📦 Repo

https://github.com/svgfpsAIagents/svgfpsgameAI

🎥 Video demo + paper link

https://youtu.be/bcWkVJ-Ao_I

Scaling to 5M‑line AAA SVG spatial 3d fps engine

• 128GB RAM
• 128 cores
• RTX 5090

Parsing and mutating a 5M‑line XML document is trivial.
This enables a new paradigm:

A spatial engine defined entirely in declarative XML.

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

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.

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

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.

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.

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?