A 3D renderer built from scratch using Vulkan, developed step by step while learning the fundamentals of modern graphics programming. youtube link https://youtube.com/playlist?list=PLU064qurTQo0&si=6u4Y1QV_OoGidode github link https://github.com/codingbot24-s/vulkan-renderer

Roblox doesn't give scripts any access to the GPU, so I wanted to see how far you could push rendering using nothing but the CPU, in Luau.

It's a path tracer with multi-bounce global illumination, next-event estimation, reflective metal, refractive glass with Fresnel, a day/night sky. It renders a real open map at 1080p, and it has a real-time mode you can move around in while it traces live.

Everything that makes a path tracer a path tracer is written in Luau: the sampling, the bounces, the materials, the tonemap, a custom upscaler. The engine is used for exactly one thing it can do faster than script ever could, ray versus scene intersection. Nothing else.

Benchmarks (Intel i5-11400H laptop, in the Roblox client, GPU unused, tested on Crossroads):

• Progressive: a converged 1080p frame in about two and a half minutes (80 passes, ~1.92s per pass with the custom upscaler on).
• Real-time: ~23 fps average, moving the camera the whole time, at the lowest preset.

It runs in parallel across 8 Roblox Actors. There's a progressive mode for the clean beauty render and a real-time mode for flying around. You can toggle between path tracing and a faster ray-tracing mode that drops the noisy GI bounce for a clean, stable image.

Source is up on GitHub, free to view, run, experiment with, and make videos about. Credit required, and ask me before putting it in a game. Link below!

GitHub: https://github.com/cosypa123/roblox-path-tracer

Happy to answer anything about how it works!

Realtime showcase, 1 spp 128x72p (default preset)

Hi all, last year I started with the Vulkan triangle tutorial with the goal of finally learning Vulkan by implementing Gaussian Splatting and neural network inference. Now, I'd like to present my first demo of my Vulkan based rendering engine supporting Gaussian Splatting with dynamic lights/objects and neural network inference for character animation together with stable diffusion inference.

Basically, a scene consists of compute graph nodes that are used to record everything into compiled CommandBuffers that are reused in every frame. The idea is to really have minimal CPU-GPU communication once rendering (or inference) is set-up, apart from updates of some uniforms etc.

Check also the obligatory space game demo https://www.youtube.com/watch?v=o4P5LyLtqBY with assets generated using stable diffusion and diffsplat (neural networks inferenced by the engine itself).

Feedback would be highly appreciated.

Disclaimer: I implemented the first version of the engine with simple Gaussian Splatting and network inference the 'traditional' way. Then, AI based coding really took off and most features on top heavily rely on Claude and GPT now. I have not looked into a single shader source for a long time. Still figuring out how to feel about it ...

Implemented 2D radiance cascades with 5 total cascades. There is some bloom and tile rim lighting added on top (though I want to find a better solution for the rim lighting). Still some work I need to do, but I'm happy with it so far. If anyone has feedback, that would be greatly appreciated!

1: Day/Night Cycle
2: No Lighting
3: Only lighting (with no filtering)
4: SDF
5: Cascade 0, probe every 2 texels, 4 directions
6: Cascade 3, probe every 16 texels, 256 directions

I've been testing my grass system across three completely different environments to see how the same underlying implementation performs across different scene requirements.

All three scenes use the exact same grass system, but the parameters are adjusted individually for each environment. Grass density, appearance, scale, wind response, and rendering distance are tuned to match the terrain and the overall look of each scene.

The system is built with Three.js and WebGPU, with a focus on rendering dense grass efficiently while maintaining real-time performance in the browser. It uses a tile-based approach, along with LOD and culling techniques, to manage rendering as the camera moves through the environment.

All three environments run directly in the browser, with no pre-rendered footage.

Try the Demo

I’m an undergraduate student in Math and CS, but I’m pretty sure that graphics programming is what I want to go into as a career. All that I have been able to do thus far is take the introductory graphics course at my university. How can I start getting into the field as an undergrad? Do I have to still seek out swe internships and whatnot if I know I want to pursue graphics specifically?

Of course, it’s a bit more complicated than just this, but you get the idea.
The lighting effect is created programmatically:
function lit(rows: string[], ramps: Record<string, string>): string[] {
const at = (x: number, y: number) => rows[y]?.[x] ?? ".";
return rows.map((row, y) => [...row].map((k, x) => {
const ramp = ramps[k]; // e.g. r: "qR" (robe: light q, dark R)
if (!ramp) return k;
const edge = (n: string) => +(n !== k);
const up = edge(at(x - 1, y)) + edge(at(x, y - 1));
const down = edge(at(x + 1, y)) + edge(at(x, y + 1));
return up > down ? ramp[0] : down > up ? ramp[1] : k;
}).join(""));
}

Also, typing big sprites letter by letter is slow, so some monster families are built from shape helpers (rect, polygon, oval) that rasterise onto the same grid and output the same strings.

Let me know if you have any questions.

Edit: the link to the game in case you want to check it out: playmadlands.com

Is it worth learning it as someone who is still relatively a beginner/early mid level c++ programmer for graphics or are other alternatives better?

https://play.google.com/store/apps/details?id=nikolalukic.beast.engine

Used android studio and chrome frame.

https://github.com/zlatnaspirala/matrix-engine-wgpu

previous version

https://www.reddit.com/r/GraphicsProgramming/comments/1wxnz45/the_mistakes_i_made_and_the_lessons_i_learned_in/

i continued the project. as noticed before the inside world (viewed from within a glass ball's interior) was very fascinating and there were endless strange scenes to explore. but the camera in the previous version was a pinhole one. it had infinitesimally small aperture and thus everything was in sharp focus. i was curious what it would look like if i could see the depth of those complex manifolds

i added real-time adjustable aperture and focus distance into the camera, constructed as image 1. focus plane, canvas and aperture disk were all parallel to each other. i manually adjusted the focus distance, just like using a real camera in manual mode. sometimes it was not easy to do it right and the resulting images were a little bit blur. so i added auto focus feature. when holding the space bar and hovering the mouse around the scene the program detected the correct focus distance (very simple, used distance between hit point and camera and multiplied it by cosine of ray angle)

there was still a problem. auto focus only focused perfectly on the surfaces of the balls. the reflections / refractions were usually NOT on the surfaces. e.g. if you put an apple 10cm in front of a mirror the reflection of the apple would be 10cm behind the mirror. if you auto focused on the exact surface of the mirror you wouldn't get a clear image of the reflection of the apple

i didn't have any idea how to tackle this problem. i used a workaround. usually it worked quite well or quite close if you auto focused at the boundary of the ball. examples as shown in images 2 and 3. please keep in mind that the checker box patterns on those balls were actually beneath (not exactly on) their surfaces

the depth effect revealed more information and added more realism to the images. as shown in images 4 and 5. in previous version with aperture=0 all the blurry regions of the refraction would become sharp and clear and you couldn't get any sense of depth

for comparison please see images 6 (with depth effect) and 7 (without)

why image 7 had more color information than image 6? it was because calculation resource was limited / kept roughly constant. for a zero aperture the program could let the rays bounce more times as it didn't have to generate multiple random rays within the aperture disk

now the most interesting part, let's go inside. the inside world becomes weirder than before (images 8, 9 and 10)

it's a trade off. image 10 had more color information than image 9 but no depth information. if you want both, set the resource (number of samples emitted from aperture x number of samples per emission x number of bounces per sample) to, say, 1,000,000 and hit the render button and go to sleep and get the result next morning...:)

program details

https://www.reddit.com/r/qbasic/comments/1w8go1e/elementary_ray_tracing_experiment/

As someone who is quite new to graphics programming I am having a bit of trouble deciding on what 2D api I should learn and use as a main. What do you suggest for both general stuff and games?

So my friend works mainly on rhino he was always frustrated on how evaluating and baking i so slow. We spent some time prototyping on moving to GPU but that felt impossible because math of libraries like opennurbs was designed to be on CPU. We stumbled upon some papers about SDF but with curves. the math is simple but requires soo much tuning. We built the same model in rhino and in our prototype. The output was identical but it took 8s on rhino but 350ms on our prototype. For the user its normal nurbs, curves, solids, polylines,...etc. for us its a different story with different algorithms

I'm weighing up whether to use matrices or quaternions for a 3d engine I'm making. I find matrices more intuitive to use but I have seen a lot of comments that they can lead to innacuracies over time. What do you guys think about this? Is there some nuance that I am missing or some situations that one approach is used over the other?

Hey! I decided to do my thesis on something related to realistic terrain generation, probably close to hydraulic erosion terrain. Issue is, I began looking through papers and I don't really understand anything. I know the basics of terrain generation, perlin noise, fractional brownian motion, that's about it. I was trying to read "hydraulic erosion from Benes, 2006, but I have a hard time with fluid dynamics but also the other concepts... Then I found out erosion terrain generation is fairly advanced

So my question is, as a beginner in terrain generation and graphics programming as a whole, what scientific articles/papers/videos/books (preferably papers) would you recommend for me to learn towards hydraulic erosion and even more advanced effects? I am a computer science student

This is some progress of a free game i have been working. This is fully software rendered on the CPU and OpenGL is only used to render the image. I use multiple threads to render the game at full 1080p. Using SIMD instructions helps a lot to get a decent frame rate. But i am still kinda dissapointed by the performance, i think Michael Abrash's binning technique would improve it, but right now, it is decent. I am getting around 70-140 frames with I5-12400.

For those working full-time as rendering, graphics, or low-level engine programmers, do you use AI-assisted coding tools like Claude, ChatGPT, or Copilot at all?? With all this talk about AI in the game industry recently I'm curious how widely it's actually being adopted professionally in these more specialized, low-level areas of programming.

If you do use it, how much of your workflow involves AI? Is it mostly for debugging, boilerplate, or understanding unfamiliar code, or do you actually use it to write and implement features?

And for those who don't use it, is that because AI isn't reliable enough for this type of work, or simply because you prefer writing the code yourself?

I'm interested in hearing what the actual industry experience is like, especially compared to all the noise surrounding AI coding tools.

A while ago I posted my C rewrite of pre-classic versions. Now I did the same with Classic: every version from 0.0.11a up to 0.30, plus the dedicated servers.

It renders the same way the original did in 2009: fixed-function OpenGL, a display list per chunk, glFog, no shaders. I tried to keep the output exactly like the original.

Uses GLFW, GLEW, zlib and stb. Play around, feedback is welcome!

github.com/degradka/mc-classic-c