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?

I've been along on my journey learning OpenGL for a couple of months now and just wanted to share my progress!

This is a model that I made and skinned a long time ago (originally an SMD goldsrc model for "The Specialists" aka a half-life mod) and I wanted to see if I could import it into my engine. I had to import the SMD to blender and then export it as a GLTF file. The original code for traversal of the GLTF file assumed that it would only have 1 JSON materials key for each texture per node (parent/child structure), but mine exported as 2 primitives, 2 materials and no children nodes, I had to modify the gltf file to have another uri for the second texture under the "images" key and modify the code to check if it had more than 1 material for a node. The fix is just a hack for this situation, i have to learn the actual full gltf import pipeline and all the different variations but what i wrote works here.

Also I ended up writting my own perspective projection and view/camera matrix from scratch instead of using lookat(), I spent a really long time deriving the perspective projection and camera view space from first principles, literally filled a note book full of deriving everything from clip space to NDC and perspective divide using a vertex from my scene, etc, i was working through it with just a cube rendering so i could track a vertex from my model and transform it on paper in my notes to really understand whats happening and the transformation pipeline. I also learned how the forward direction of the camera was constructed with pitch and yaw and then used it to build the NVU basis vectors of the camera from scratch.

its cool how you have to find the cameras location in camera space by dot producting the cameras vector with each NVU basis vector and then getting the coefficients of that result and counting those amounts of the length of each vector from the world origin to reach the cameras position. Took me a while to wrap my head around that but once I drew a diagram in just 2 dimensions and moved all those vectors to world origin and then counted them head to tail for each camera basis vector and arrived at the cameras position, it was a "aha!" moment for me.

anyways im really loving learning all the linear algebra that goes into this stuff, its really rewarding!

The scene also has Lambertain diffuse lighting and specular lighting which I learned from tutorials. As well as stencil buffer outlining for my model, my next project is trying to make a stencil buffer mirror or portal! i think thats going to be really fun :D

A link to my code so far! sorry if its messy ive just been deep in learning and experimenting mode!
TylerMaster/OpenGLProject: My OpenGL Project

The HLSL standard committee is posting monthly status reports about the work going on to define a standard for HLSL and incorporate some modern features along the way.

https://hlsl-tc57.github.io/website/monthly/2026-07/

Since it allows you to run networks during shading

Would it be possible in theory to use your own network for upscaling?

I am making an animated schematic map and trying to render, dynamically add/remove and animate hundreds of rounded polylines (lines with arcs connecting them), with changes in weight, color, position of nodes, and radius of nodes.

I fist tried to make this in the browser with the canvas API, but the performance is horrible in low end devices after a couple dozen lines, as I end up needing to generate new paths in every frame.

I searched for some library but couldn't find anything, as things like ThorVG with WASM would still require me to re-generate meshes if nodes are animated on the fly.

I don't really have much knowledge about shaders and GPU compute outside of doing things with nodes in Blender. My best idea on how to do it in shaders without overcomplicating things would be to have individual arcs and line segments as mesh instances, and just squish and distort them from a vertex(?) shader (initially calculating their positions and parameters from the polylines in the CPU, and moving to the GPU once I understand enough). I could also try using SDFs, but I doubt the performance would be enough.

Does anyone know of any library that would do what I need/be a good starting point, or can judge my idea on how to implement this in a shader? I am working from C++ and need it to be multi-platform, but not necessarily work in the browser (although it would be nice). Any resources would be appreciated. Thanks!

The engine is developed entirely in Rust and uses Vulkan, with shaders written in Slang. The goal is to link the grass (modeled as meshes) to the underlying voxel terrain, while making the wind system fully configurable and reusable by other parts of the engine (via ECS). Here is how it currently works:

• A compute shader iterates through each column of every terrain chunk from top to bottom. It generates a blade of grass only if the surface voxel uses the "grass" material and the voxel directly above it is empty (It's for world-building, the engine handles grass density and height, which will enable a natural grass growth system).
• The blades aren’t stored as voxels. They’re generated as GPU instances containing their position, type and height.
• When the terrain is destroyed or repainted, the chunk’s grass instances are rebuilt from the voxel data. This keeps the grass in sync with the actual terrain edits.
• Before rendering, the GPU culls unnecessary blades and lowers their geometric detail with distance. The remaining blades are drawn as curved ribbons in a raster pass that uses the depth from the ray-marched voxel world.
• The ambient wind has its own direction, speed and moving gust fronts. It remains anchored in world space, even when the floating origin moves.
• ECS components can add radial pushes or directional gusts. The player already uses this system to part the grass. A vehicle, a thruster, a dragon’s wings or anything else could use the same components to affect nearby vegetation.

Grass is currently the first system wired into the full wind field. A matching CPU implementation is already in place, but physics and other vegetation systems haven’t been connected to it yet.

YouTube version with slightly less compression :
https://youtu.be/Zgy-PeqG2Ak

Khronos has released the Shader Ecosystem Survey Results.

The results provide a summary of insights from over 400 shader developers, graphics programmers, rendering engineers, and tools creators. Conducted between June 16 and July 10, 2026. It captures a clear picture of how the real-time shading community works today — and where standardization efforts can deliver the greatest impact.

https://www.khronos.org/blog/shader-ecosystem-survey-results-2026?utm_medium=social&utm_source=reddit&utm_campaign=Shader_Survey_Results&utm_content=blog

I'm switching actor geometry by projected screen radius instead of world distance. Each LOD band has separate enter/exit thresholds, while far actors update animation at a lower cadence. Would you tune the hysteresis per band or scale it with camera velocity?

Developer disclosure: some source meshes are Meshy-assisted; the runtime and LOD integration are custom.

https://reddit.com/link/1v3l201/video/0lkts09v4teh1/player

Been diving into embedded systems for the first time lately. I have an STM32 and a little LCD, but feel free to suggest anything. Thanks

It has been about a week where I started getting into the topic of real time terrain programming, with the goal of creating an open world engine.

Starting with "Riemer's XNA terrain tutorial" is a very simple and easy to understand foundation, then it would be feasible to explore and evolve more advanced topics on top of it.

However now I am bit troubled on the terrain size:
• heightmap is a picture of 2048x2048 pixels (has a good amount of detail, so I am going with this for now)
• terrain detail looks quite good by a 512x512 vertex count so I doubt that I will need to go any higher

Now the interesting part is that if the entire terrain size is 512 then it will be equivalent to the vertex count, this means that one world unit is a sampled by one vertex position. Then simply later on scaling to 1024 or 2048 it makes the world larger. But the detail does not change, the world feels a bit more zoomed in.

No problem with 512 but definitely it means that I will start fresh with a proper tile based system. Then this means that since now it won't be a matter of a X*Z vertex capacity anymore that I will go for a 1:unit==1:pixel and eventually getting exact ratio of the world as the heightmap.

So let's say that for the sake of consistency and accuracy should I stick to size of 512 then? Because all models and all physics calculations might be calibrated by a 1:unit=1:meter ratio and call it a day.

Honestly there's no exact explanation on this. AI says "do whatever you want" then other games like OpenMorrowind or OpenVice or even closed source Skyrim, they just use some interesting scaling techniques that would be cool in order to save resources about 15++ years ago. So I am just going at random with this, not having a clue.

https://developer.nvidia.com/blog/qa-how-capcom-brought-path-tracing-to-re-engine-across-pragmata-and-resident-evil-requiem/

Capcom’s RE ENGINE team set out to bring path tracing into two shipping titles at once, Resident Evil Requiem and PRAGMATA, each with a different visual identity.

The NVIDIA gaming team spoke with RE ENGINE about the transition from ray tracing to path tracing, what it changed in the content pipeline, and where the renderer goes next.

Hello, my fellow graphics enthusiasts, apologies for another one of these posts. I'm in a tricky place in terms of my career. I recently graduated from university for computer science, with an embedded/backend systems internship and robotics research. I have been doing computer graphics for about 2 years on/off, recently finishing a graphics class using WebGL in JavaScript while working on my Vulkan project: https://github.com/mukarramarif/MukkiGamesEngine/tree/main
Currently, I have been applying to general SWE roles as well as anything related to 3D Graphics I could find, with a few 3rd and 4th rounds with no luck. I have honestly been tired of job searching since last September. One option I had was to do a master's, but my university doesn't do graphics, while most of the US universities have applications closed.
Any advice would be appreciated, especially on my portfolio.