Dear r/GraphicsProgramming,

Before I commence: this effect is really reserved for the reflection component of transparent materials with the refraction being screen-space as well. My gloss trace resolution is low in both SDF-BVH and HWRT approaches and the SDF-BVH one produces blocky reflections which is not a good fit here.

So my engine already had a screen-space tracing approach. But it was fetching world positions from the gather resolve pass which was incredibly slow and sampling pressure heavy. It would sample world positions along a screen-space ray until said position would form a unit vector against the origin that was very directionally similar to the reflection vector. It had to do this for hundreds of fragments for the reflections to not cut-off prematurely. Which prompted me to gimp it to 10 iterations and relax the similarity requirement for the recent release, effectively killing the feature.

Having had to spend the last almost 3 years gutting Unreal for work, I was intrigued by how they simply just traced against the depth buffer. Additionally, their hole skipping approach via using coarser depth tiles was saving them tons of needless sampling. So these past couple of days I set out to produce something similar:

https://github.com/toomuchvoltage/HighOmega-public/commit/d304558dacbf495f286301bfc198e3f67b5886fe

The first thing I had to change was my depth mipping approach. I now had to effectively generate both MinZ and MaxZ depth pyramids. Previously only MaxZ would be generated (MinZ for the visibility buffer pass since it used ReverseZ):

https://github.com/toomuchvoltage/HighOmega-public/commit/d304558dacbf495f286301bfc198e3f67b5886fe#diff-5a79aee1ef1f826152e0b4ba07cfdced0a1956f2d60fdc82cf631f01c25f7dc4

https://github.com/toomuchvoltage/HighOmega-public/commit/d304558dacbf495f286301bfc198e3f67b5886fe#diff-da568e877110744c46e4bff11a4e3d6bff89e95d440085883e3e7b2ec6c6e297

The second thing was to effectively trace the 32x32 mip and capture hits within some threshold (0.006 to be specific):

https://github.com/toomuchvoltage/HighOmega-public/commit/d304558dacbf495f286301bfc198e3f67b5886fe#diff-60cfbc940e6376b2eeb022453df681a66e4a50b29d0a621cc34192b9238a2e5bR212-R230

If a hit was found, proceeding to step back and continue tracing the 64x64 mip within a smaller threshold (this really is my highest depth mip resolution before the full depth buffer):

https://github.com/toomuchvoltage/HighOmega-public/commit/d304558dacbf495f286301bfc198e3f67b5886fe#diff-60cfbc940e6376b2eeb022453df681a66e4a50b29d0a621cc34192b9238a2e5bR232-R255

And finally, trace against the actual thing in case there's a hit with the 64x64 mip:

https://github.com/toomuchvoltage/HighOmega-public/commit/d304558dacbf495f286301bfc198e3f67b5886fe#diff-60cfbc940e6376b2eeb022453df681a66e4a50b29d0a621cc34192b9238a2e5bR257-R274

Now the trace loops aren't water-tight. Which brings me to this paper: https://jcgt.org/published/0003/04/04/paper.pdf . It would be interesting to implement a full on DDA approach. It would probably remove the blocky artifacts near the edge of the screen where the probability of disocclusion is high. That said, I find some of the additions in the paper quite prohibitive. Depth peeling is interesting and quite possibly reduces disocclusion by a decent amount but is also very slow.

My approach is probably closer to something like this: https://sugulee.wordpress.com/2021/01/19/screen-space-reflections-implementation-and-optimization-part-2-hi-z-tracing-method/

One of the annoying things in this approach is the fact that I'm using the mip chain from the TwoPass culling pre-pass. Which blanks out under scene changes -- as in samples the skybox only -- for 1 frame. This is due to the tracking buffer being recreated. Fixing this means generating yet another mip chain for the main pass in TwoPass and since it doesn't happen very frequently, I'm going to leave it. Curious to hear feedback. And if you liked the post, consider buying a copy of my game C.L.A.S.H :D. Which runs on the same engine: https://store.steampowered.com/app/4796200/

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

Made a small Backrooms pool demo in Natiny. I’m not sure I fully captured the atmosphere I was going for, but overall I’m pretty happy with how it turned out.

The caustics are probably a bit too bright, but I think they make the scene more interesting.

What do you think?

I need some help with some computational Geometry and Automatic Routing

for an interactive CAD application.

Would anyone be interested in chatting and seeing if it's something that is in your wheelhouse?

spent the last 4-5 week building Hypertracer, a CPU + CUDA path tracer with progressive sampling further implmneted GPU acceleration, and a real-time fly-camera viewer
built the renderer and viewer from scratch, with 6 scenes currently implemented and 1920×1080 can be rendered at 3000 samples

along with Ray Tracing in One Weekend, The Next Week, and The Rest of Your Life, all three books i completed
it was seriously so much fun :D

main resources i followed:
ray tracing : https://raytracing.github.io, https://pbr-book.org
repo: https://github.com/whoashish115/hypertracer

give it a star ⭐

Hi there, I am currently studying CSE and first time on graphics programming :)

Tried to build a glTF renderer using Vulkan in C, nothing fancy 😞
Somehow it turned into a flappy bird game with a simple physics engine, with UI and stuff.
Although it flaps without wings, it runs at 4.5k FPS on Ryzen 7 8745H, 780M iGPU

https://github.com/xRumi/yanGameEngine

Suggest me anything fancy.

Still an unstable feature!

Website: https://www.doriax.org/

GIthub: https://github.com/doriaxengine/doriax

Hi, Well so i just didnt know what roadmap i can follow or the one that i have on my head is ok..?,

So for a little context im studying System Engineers, (Computer Science is the equivalent in other countries), and im very interested in entering in the industry, i know its difficult and all of that but i still wanted. So for a summary of the roadmap i have in my head rn:

- Linear algebra (i already know this from my college classes)
- C++ learning again from the basics, in a udemy course (C++ for Complete Beginners is called)
- Learn 3d in raylib, making some games or something related there
- Opengl, follow the tutorials or read a book (help a friend to improve a costume engine)
And try to learn vulkan (with SDL3 to start)

Im still have about 3 years to get the grades so i still have time, but i just want to know if you have another recommendation about what help you to learn and get through this. Thanks

I’ve been working on a small Vulkan renderer mainly as a learning project and was wondering if anyone had some time to look over it and give me feedback on the overall structure and design.

I started with the Vulkan in 2 Hours video, and after working through that I felt like I picked up how the API worked pretty quickly. From there I started pulling parts out of the original setup and building my own renderer API around them instead of keeping everything directly inside Application.cpp.

Right now I have things like the renderer context, swapchain, shaders, pipelines, descriptors, images and textures, samplers, materials, mesh loading, dynamic rendering, a geometry pass, and a skybox/environment map working.

The hardest part for me so far has probably been understanding queues, queue families, command pools, command buffers, and the overall frame lifecycle. I feel like I understand most of the individual pieces, but figuring out how they should all fit together cleanly has been more difficult than things like pipelines, descriptors, or basic rendering.

Before I start getting into compute shaders, more rendering passes, async compute, and eventually a render graph, I wanted to stop for a bit and make sure I’m not building on top of a bad foundation.

The main thing I’ve noticed is that the public-facing side of the renderer, especially what you see in Application.hpp/.cpp, is starting to feel a little too verbose.

Texture and image creation is probably where I notice it the most. There are a lot of specifications, image views, descriptor registrations, layouts, barriers, and other Vulkan details being handled by the caller. I know Vulkan is supposed to be explicit, and I don’t want to hide everything behind huge abstractions, but I’m not really sure where the line should be between giving the user control and keeping implementation details inside the renderer.

I’m also wondering about the overall structure of the project. Things like resource ownership, descriptor handling, pipeline setup, pass setup, queue and command buffer ownership, frame lifecycle, and how much Vulkan should really be exposed through the higher-level API.

My current plan is to eventually add a SceneRenderer that handles scene rendering and pass submission, then later add a render graph to handle things like resource dependencies, barriers, layouts, and pass ordering. I’d also like to experiment with async compute once I get to that point.

I’m still learning C++ and graphics programming while working on this, so I’m mostly trying to catch bad design choices early before the project gets much bigger.

If anyone has time to look through it, I’d really appreciate feedback on things like:

• Whether the current abstractions make sense
• What parts of the API feel too verbose
• What responsibilities should probably move out of Application
• Whether the image and texture API should be higher level
• Whether my queue, command pool, command buffer, and frame lifecycle setup makes sense
• Anything I’m doing now that might make a render graph or multiple passes harder later
• General C++ or Vulkan design problems that stand out

I’m not expecting anyone to do a full code review. Even just looking through a few of the renderer files and pointing out anything that looks awkward or could be structured better would help a lot.

Project: https://github.com/AstrixsmCS/VkLab

Thanks.

-First I learned C++

-Then Made some Projects

-Jumped to Opengl learned the very basics of it

-Currently Building a Ray Tracer based on the Book Ray Tracing in a Weekend by Peter Shirley

-After Completing all 3 books of Peter Shirley about Ray Tracing I want to Do some other Graphics Programming Related projects

-Then Gonna Learn more about Opengl and after getting comfortable with that I will Make some projects

-After this I am looking forward to Learn Vulkan and Realtime rendering with it

Is this a good Approach?

I spent six days trying to implement this, met and fixed so many Quaternion-related bugs, and finally done. I can't express how happy I am right now.

As per the title, the entire rasterizer run on HTML Canvas and Javascript. It fit in one single HTML file (I like it that way). The textures are loaded from URL.

You can try it out here: https://hachihao792001.github.io/interactives/portal.html

I’m a CS student trying to figure out whether the direction of my current project is actually worth pursuing for aerospace/robotics research.

Live: https://bhuvanspace.vercel.app

GitHub: https://github.com/Sheel34/BHUVAN

The current version takes terrain data, processes things like elevation, slope, roughness, curvature and hillshade, and puts the result into an interactive 3D environment.

The software side is currently Python/FastAPI + NumPy/Rasterio/OpenCV on the backend and React/Three.js on the frontend.

I built it because I'm interested in digital twins and simulation for aerospace/physical systems, but I'm not interested in making a 3D scene just for visualisation or a game.

What I want eventually is an environment where you can actually perform an operation on a representation of a physical system.

The project is still very early. I haven't implemented robotics simulation, terrain-relative navigation, ROS, Gazebo, Isaac Sim, etc. yet. I'm trying to figure out what should actually come next rather than adding technologies for the sake of the stack.

I'm particularly interested in the intersection of:

digital twins, 3D simulation, aerospace/robotics, real physical operations.

One direction I've been reading about is terrain-relative navigation / TERCOM and how terrain itself can become part of a navigation or mission system. I'm not claiming the project implements this — I'm trying to understand whether the terrain pipeline I've built can be developed into something along those lines.

More importantly:

What would make this go from "3D terrain visualisation project" to an actual engineering/research system?

The current deployment is on free infrastructure, so the backend may take a little time to wake up. If it doesn't load immediately, wait a few seconds and refresh.

I'd appreciate criticism of both the technical implementation and the direction.

With dlss 5 coming out and a lot of discussion online painting it as almost like a filter that’s adding detail to games that isn’t there (e.g. making characters look chiseled), it looks like it’s designed to make realistic looking games look more real without the side effect of making stylised games look uncanny.

It’s got me wondering if it’d be possible for a developer to train a narrow model specifically how to take renders from their game at lower settings and transform them into something akin to high settings.

The idea being that during development they could output millions of rendered images with metadata about the scene, buffers, movement vectors, etc, then have an offline process rerender those scenes at very high quality.

They could use the renders as input to a training model, and generate their own dlss like system specific for their game that would allow lower end hardware to output higher quality graphics.

Is that fundamentally possible? I’m guessing the restricting factor would be cost or just simply not being able to generate enough data? Even so could you compound training for your own game on top of the vendors implementations of dlss/fsr?

I’m not really in the know about ai upscaling techniques so sorry if this is a stupid question

https://overboost.cz

Nothing in the world is a mesh: the arena, cars, ball and boost pads are SDFs marched in a compute shader. The one mesh in the game is the physics collider, generated from the same distance field so the two agree - and you never see it.

Keeping those in step turned out to be most of the work. The C++ SDF the car drives on, the shader SDF you see and the collider are three descriptions of one world, and nearly every bug this month was two of them disagreeing.

It also paces itself. Rather than free-run and let frame times scatter, it picks a divisor of the display refresh and hunts the highest resolution scale that fits inside it - an even 30 reads better than a ragged 45. Measuring the refresh was the fiddly part: one sample once reported 224Hz on a machine doing 40, so it now takes the shortest frame that recurs over a window instead.

WebGPU/WASM, Jolt for physics, Slang compiled to both SPIR-V and WGSL.

discord: https://discord.gg/NytmdnPMr

Alguien puede ayudarme a determinar por qué al renderizar a un mip diferente de 0 no veo nada? El mip base funciona perfectamente. También ya confirmé que el viewport se actualiza y que el shader funciona.

Este es el código que tengo para crear el fbo y generar los mips, hay algo que me falte? Gracias de antemano :)

InitFBO::InitFBO(int w, int h, GLenum internalFormat)
{
    glGenTextures(1, &texture);
    glBindTexture(GL_TEXTURE_2D, texture);

    for (int mip = 0; mip < 8; ++mip)
    {
        int mipW = std::max(1, w >> mip);
        int mipH = std::max(1, h >> mip);

        glTexImage2D(GL_TEXTURE_2D, mip, internalFormat, mipW, mipH, 0, GL_RGBA, GL_UNSIGNED_BYTE, nullptr);
    }

    float borderColor[] = {0.0f, 0.0f, 0.0f, 1.0f};
    glTexParameterfv(GL_TEXTURE_2D, GL_TEXTURE_BORDER_COLOR, borderColor);

    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);

    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
    glBindTexture(GL_TEXTURE_2D, 0);

    // FBO
    glGenFramebuffers(1, &fbo);
    glBindFramebuffer(GL_FRAMEBUFFER, fbo);
    glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, texture, 0);

    GLenum drawBuffers[1] = {GL_COLOR_ATTACHMENT0};
    glDrawBuffers(1, drawBuffers);

    if (glCheckFramebufferStatus(GL_FRAMEBUFFER) != GL_FRAMEBUFFER_COMPLETE)
        std::cerr << "Error";

    glBindFramebuffer(GL_FRAMEBUFFER, 0);
}

Unity DirectX 12 Amplification Mesh Shader Minimal Example

I’m an experienced programmer, very comfortable in both C++ and Rust, coming from a robotics background, so linear algebra and computer vision concepts aren’t new to me. Graphics programming itself is new territory though, and I want to properly learn an API with the eventual goal of building a game engine.

I’ve narrowed it down to three options and I’m stuck:

- wgpu — modern, safe, and I already like Rust, so the ergonomics appeal to me

- Vulkan — the “real” modern low-level API, feels like the industry state-of-the-art

- OpenGL — the classic starting point almost every tutorial and book uses, but it’s old.

Also what are some nice guides/tutorials to get started?

After 200+ hours of development, I’m finally sharing the first public demo of Three.js Grassworks, a real-time grass system I’ve been building for Three.js and WebGPU.

Demo:
https://grassworks.techredux.co/demo

Three.js Grassworks is built specifically for WebGPU and is designed to handle large amounts of interactive grass while maintaining steady performance.

For the demo, I built a complete environment around Grassworks with terrain, trees, water, rain, player interaction, environmental effects, LOD systems, audio system, and more.

The main challenge was getting all of these systems running together while keeping the grass performant.

The actual Three.js Grassworks plugin is still being polished and should launch in the next couple of weeks. There’s a waitlist inside the demo if you’re interested.

I’d genuinely love feedback, especially on the visuals, performance, and how the grass feels when interacting with it.

I also recorded a full walkthrough where I go through the demo and talk about how I built it:

https://www.youtube.com/watch?v=Nhim18rc-XE

for the past 2 months or so ive been working on this path tracer that i made and it uses love2d as a base. it runs with a compute shader and supports opengl, metal and vulkan as love2d also compiles those on the fly. it has most stuff youd encounter like fresnel stuff, ior, gltf scene support and most gltf extensions. also it can export raw exr files which i find very unique tbh. also it does support transmission maps, roughmetal maps and emission maps. i still have to do normal maps but that seems very annoying to do lmao. today i even added dof and click to focus which i find extremely cool for no particular reason.

it's open source and you can find it here

I’ve just published version 1.6.0 of Horde Lantern RT, a small native Vulkan hardware-ray-tracing project. I’m posting the implementation details because the interesting part of this update is how the effects are integrated into the renderer and shared simulation, not just the final art.

The frame path is still:

• vkCmdTraceRaysKHR for presentation
• phone-safe rayQueryEXT work inside raygen
• recursion depth 1
• one frame in flight
• strict Android ASTC textures
• shared 60 Hz deterministic gameplay simulation

World-space fire

The torch fire is a bounded FireEmitter rather than a camera overlay or billboard. Each emitter has a stable ID/seed, world transform, flame/light sockets, strength, fuel, phase, colour temperature, radius, height, absorption and motion response.

The same emitter state drives:

• an RT-visible emissive flame core
• world-space raygen volume integration
• direct coloured light
• shadow visibility
• reflection contribution
• deterministic flicker
• movement-induced flame lean/turbulence

Only a small fixed number of emitters are selected per pixel/zone to keep the mobile path bounded.

Dielectric lantern glass

The reward lantern uses closed glass geometry and a reusable dielectric path supporting transmission, IOR, roughness, thickness and attenuation.

The transport uses bounded ray queries rather than Vulkan recursion:

F0 = ((ηi - ηt) / (ηi + ηt))²
F  = F0 + (1 - F0) * (1 - cosθ)^5
T  = exp(-σa * distance)

Entry/exit interfaces, Fresnel reflection, refraction, Beer-Lambert attenuation and transparent shadow transmittance are all handled within a finite layer budget. Difficult Mobile paths terminate at the explicit budget instead of recursing indefinitely.

Fixed-step physical carry motion

The lantern body hangs below a hand-held hinge. Its motion is authoritative simulation state, not sin(time) animation.

The solver uses pivot displacement/velocity, actual hand acceleration, gravity, damping, torsion response and soft/hard angular limits. Its structure is approximately:

// dt = 1.0f / 60.0f
velocity = (pivot - previousPivot) / dt;
acceleration = (velocity - previousVelocity) / dt;

angularAcceleration =
    gravityTorque(angle)
    + dot(acceleration, handBasis) / centreOfMassLength
    - damping * angularVelocity;

angularVelocity += angularAcceleration * dt;
angle += angularVelocity * dt;

This gives the expected lag when starting, overshoot when stopping, lateral response while strafing/turning, and bounded response during dodge and raise/lower transitions.

Asset and instance path

The sword, torch, chest and lantern are imported through a static GLB/PBR path. Immutable meshes own their vertex/index/material data and BLAS; scene instances own transforms and metadata indices. Raygen decodes material and geometry ranges through fixed-capacity metadata rather than adding another instance == N shader branch.

The same socket system is used for the sword, torch and reward lantern. The player animation/IK foundation is reusable, although the shipped first-person view still uses the accepted block-arm presentation while the authored gauntlet pass is refined.

The project is available here:

• Itch build
• Public Git repository

Disclosure: This is an AI-assisted project. I provided the architecture, requirements, technical direction, review, playtesting, and release decisions; OpenAI Codex generated and edited much of the C++/GLSL, tests, tooling, and documentation under that direction. Some 3D assets were generated with Meshy and processed locally. The renderer, simulation, validation evidence, and asset provenance are available in the public repository.

Hey everyone,

Demolink- https://tektonai.vercel.app/

My co-founder and I have been building a client-side spatial compute engine designed to bridge the gap between initial 2D floorplan concepts and interactive 3D massing.

Right now, the engine runs procedural spatial math directly in the browser—generating 2D vector layouts while simultaneously maintaining a 3D Three.js mesh tree with wall cutouts, roof geometry, and multi-floor zoning.

Where we need help:

We are aiming to launch a high-precision MVP. Before we double down on our next engine refactor, we want feedback from real spatial builders:

•What floorplan geometry breaks first when you tweak parameters?

•What features would move this from an "interesting WebGL demo" to something useful for early site visualization?

(Built under minimal resource constraints—expect bugs!) We appreciate your honest review and time that would help use make this perfect.