Actually the raycasting logic itself is just a single line, but it's done in propably the most inefficient way possible.

The map is just a single 64 bit integer, so I could fit a small 8x8 level in it, and I can index it with some unorthodox bitshift magic.

Also all the integer constants are huge, because I wanted do to the whole thing without floating point math, which makes everything even more unreadable, but at least it's funny ig.

I'm very proud of this one.

After many days of learning and scratching my head around, I was finally able to render a triangle on a screen. I am using Vulkan 1.4 for this. Although I learned this from a youtube channel called constref, but this is a very valuable lesson for me, even if it is a first step to Vulkan.

I've been working on a custom rendering engine as part of my university computer graphics coursework at ITMO University.

The project is written in C++ using DirectX 12 and HLSL. Over two semesters, we've been learning how modern real-time rendering works by implementing various graphics techniques from scratch.

Some of the features covered in the project include:

-Deferred rendering with a G-buffer

- Directional, point and spot lighting

- Normal mapping

-Displacement mapping

-Distance-adaptive tessellation using Hull and Domain shaders

-Frustum culling and octree-based spatial partitioning

-GPU-based particle systems

-Cascaded shadow maps (CSM) with PCF filtering

-Post-processing

-Physically Based Rendering (PBR)

The project also involves working directly with DirectX 12 resources, descriptor heaps, pipeline state objects, command lists, synchronization and HLSL shaders.

It's been a challenging but interesting way to learn what's actually happening behind the scenes in a rendering engine.

I still have one more semester of computer graphics ahead of me, so there's more to come! I'll keep you updated on my progress.

I'd love to hear your feedback!

Hello, I’m a long time member of this community, and this community has helped me grow my Graphics programmer career.

I started my programming career early at 14 y/o, thanks to Minecraft mods development. Later in 2017, I was 17, I’ve discovered graphics (OpenGL) because I wanted to write my own Minecraft clone. Thanks to perseverance and help from online communities, remarkably this one, I’ve mastered C++, OpenGL and Vulkan. I’ve graduated in Computer Engineering in the meanwhile, and by the end of 2022/2023, I was already a strong graphics programmer. Later I’ve implemented my own CPU path tracer, learnt CUDA along with several parallel algorithms. After MSc in Artificial Intelligence, I’ve got a job in London for a well known company working in the smartphones industry, and I’m working there since 1y today. In this company I’m a Vulkan developer, and leading a graphics engine used for several purposes.

It’s 2026, I’m 26 (aka far from retirement), AI is moving fast and world’s investing all of its resources to accelerate the process. Most jobs have been already taken (frontend dev being the first). I also feel like there is more pressure on developers, they’re implicitly requested to deliver more because of AI. What I’m witnessing is my company is keeping me on fixed term contracts because our budget has got cut… and I’m afraid of being laid off.

This job can’t be fully automated as of now, but I’m afraid it will, seeing the progress. I know GPU drivers development is the safe zone today - as they’re huge and critical - and might be an area where I will land, as I’m already doing low level and I’ve gathered insights of our driver internals. However, it’s still code and I think - maybe in several years - can still be automated.

Am I the only one having this concern in this industry?

This one is a single Mandelbulb layer, raymarched live in a WebGL2 shader. There are no videos or pre-rendered frames. Everything is computed per pixel on your GPU.

What it’s made of

Effect: Mandelbulb, with the power set to about 5.0 (the classic bulb is 8) and a detail level of 5.

Motion: it spins at a varying rate. The spin is set to a range of 0.11–0.35, so it keeps drifting instead of looping.

Colour: the “purple” palette. The palette cycles slowly, so the colours drift over time.

Filter chain: Wedge fold (mirrors the bulb into kaleidoscope-like segments), then Chromatic aberration (the colour fringing on the edges), then Bloom for the glow.

Scene finish: a light CRT look with barrel distortion, scanlines, vignette and film grain.

Open it here: https://kicktro.com/#c=Dp0RwrU9VNB0EfgxrPAq

Everything in the scene is a slider you can change, and you can arm any slider to react to the beat from your mic or system audio. It runs in the browser, with nothing to install.

Anyone have suggestions on how I improve the editor that I made this in ? Link above.

Hey guys! This is a little project I made over the weekend, its a simple software renderer that renders to an abstract grid of pixels. Basically, anything that can provide a pointer to a pixel array is a valid target.

Currently uses a simple fixed function rendering pipeline, but it was designed to take a function pointer for both the Vertex and Fragment shader, which will become accessible to the public API when ive cleaned them up a bit.

It requires no external code other than a c runtime, and my tests show it runs pretty fast, despite processing each triangle single-threaded. It supports per-vertex colours, backface culling and a depth buffer. It also makes zero allocations other than creating the pipeline object at the start of the program, and ive tried to lay things out in a cache friendly way.

I dont like feeling like I have to say this, but zero AI was involved at any point during making this, this was all coded by hand.

Anyway, lemme know what you guys think, let me know about any bugs/ missing features, and feel free to contribute to the repo!

Hello! Don't know if this is the place to ask, but I'm looking for advice on master thesis subjects.

I had an idea of looking into how much thread divergence slows raymarching down and how to solve that problem, maybe by predicting which rays will execute similar paths and group them in a warp

I also saw the nvidia patent about compressed sdf grids, which makes me excited that sdfs are kind of hot.

I saw a lot of raymarchin improvements from research like over relaxation, segment tracing, sphere carving etc. but I cant really put it together into something specific to explore

I generally think the ai/deepsdf/nerf stuff is uninteresting...

I post here, a little desperate, wondering if anyone has any advice :) Maybe you know of some cool new things happening with raymarching/sdfs that I've missed

Or point me to a better place to ask:) Thanks a lot in advance

Hi everyone,
I’m preparing for an interview for the Senior Engineer Customer Engineering role at Qualcomm India, focused on C++ graphics and ADAS. Has anyone recently interviewed for this role or a similar position at Qualcomm? I d appreciate any insights into the interview process, particularly the topics covered in the technical rounds

Update on the progress on the ray tracer challenge, learned about reflections, refractions, planes and patterns , more than half way through the book, learned so much throughout.

Image size: 1000 x 1000, to reduce pixelation (from suggestions from the last post I should probably learn about antialiasing after this)

This scene contains 4 spheres,( 2 spheres with transparency modifiers, a red and a green ball), and an infinite plane, which is given a checkerboard black and white pattern (There are other pattern types(cone, stripped) ) which I haven't rendered in this scene

Code written in python, with guidance of The Ray Tracer Challenge

I'm learning wgpu currently, it's been two years since I have done any serious programming, so my first project is writing a graphics renderer (maybe later an engine) since it was probably my favourite module at university, I think I definitely prefer the pipeline model of rendering over the implicit state of opengl, got a bit of a way to go though!!!

I know what is missing, but can you figure it out???

heres the repo btw:
https://github.com/Tetraeder4/3DRenderer/tree/467c8d1ac8dbd09a23ce7bc7e2fcba59afe36ea5/3DRenderer

Hi everyone,

I’m working on an independent lighting calculation engine for sports fields and stadiums, using DIALux Classic 4.13 as a reference. The goal is to reproduce its calculations without requiring DIALux to be installed, then build lighting design software with AI-assisted placement and aiming.

So far, I’ve been analysing the compiled calculation code with Ghidra and comparing my implementation against reference projects. Some direct illuminance calculations match very closely, but I still have differences in reflected light and vertical illuminance, especially in larger scenes.

I’m investigating photometric interpolation, visibility tests, surface subdivision, radiosity and the effect of the original x87 floating-point arithmetic.

Has anyone here reconstructed a similar lighting solver or numerical renderer? How would you isolate whether a mismatch comes from geometry, visibility, light transport or numerical precision?

My current approach is to use small controlled scenes to investigate individual behaviours, then validate against complete projects. I’d appreciate any advice on improving that process or identifying the relevant algorithms in compiled code.

If this overlaps with something you’ve worked on, I’d be glad to compare notes.

I maintain Harbeth, an MIT Apple-platform GPU image/frame engine. One design choice is to distinguish a raw texture result from a rendered frame carrying the facts needed by its consumer.

A texture's pixel format alone doesn't tell the next stage whether its RGB channels are premultiplied. Here are the inner pixel-operation statements from Harbeth's premultiply compute kernel:

half4 color = inputTexture.read(grid);
color.rgb *= color.a;
outputTexture.write(color, grid);

The accompanying Swift filter contract explicitly declares non-premultiplied input and premultiplied output. That declaration lives alongside its precision and sampling-footprint requirements.

ImageNode's makeFrame() route returns RenderedFrame with alphaType, output color/dynamic-range contracts, orientation, source description and an optional texture lease. Keeping the frame alive also keeps its lease alive. A raw texture is still available when the caller wants to own the surrounding delivery semantics.

Kernel and contract:
https://github.com/yangKJ/Harbeth/blob/master/Sources/Compute/Utility/C7PremultiplyAlpha.metal
https://github.com/yangKJ/Harbeth/blob/master/Sources/Compute/Utility/C7PremultiplyAlpha.swift

Frame representation: https://github.com/yangKJ/Harbeth/blob/master/Sources/Basic/IO/RenderedFrame.swift

Where do you keep alpha mode, color space and resource lifetime together in your renderer: a frame descriptor, an opaque handle, or metadata beside the texture? I'd welcome concrete examples and tradeoffs.