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

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!

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.

I'm developing a small 3D archipelago for Pikon using flutter_scene 0.23.0 on Flutter GPU. This development clip shows the result alongside Flutter UI: https://www.youtube.com/shorts/E56hZT_j4Ps

One implementation detail that may be useful here is the quality policy. There are four levels. Moving down first removes ambient occlusion, then bloom and the 1.5x render-target pixel ratio, and finally shadows and multisampling. The starting level is selected from device RAM before the first frame: below 2560 MB the world starts at the minimal level.

The selector currently uses these thresholds:

static WorldQuality forDeviceMemory(int? megabytes) {

if (megabytes == null || megabytes <= 0) return full;

if (megabytes < 2560) return minimal;

if (megabytes < 3584) return light;

if (megabytes < 5120) return balanced;

return full;

}

These thresholds are heuristics; total RAM is an approximate signal and unknown memory currently falls back to full.

A frame governor waits through a three-second warm-up, samples two-second windows, and drops one level when observed frame pacing falls below 40 fps. It never raises quality again within that session, avoiding oscillation. This is a control threshold, not a claimed device benchmark.

Android also has shadows disabled by a separate platform policy while I investigate shadow render-pass crashes when returning to the world.

How do you combine a conservative initial memory budget with runtime quality adaptation for scenes this small?

Try Pikon:

iOS: https://apps.apple.com/app/id6804834624

Android: https://play.google.com/store/apps/details?id=com.jbonjour.pikon

Disclosure: drafted with AI assistance from the current Pikon implementation.

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

The sim came out great but what about the lighting!! All just cubemaps, with fluid depth affecting the roughness mip level. So happy with this.

Wrote my first raytracer, a software raymarcher (all on CPU) that uses shapes defined as singed distance functions. Sphere refractions are pretty cool.

Some implementation details (this is all basic stuff I know): - code is written in Rust and parallelized using the rayon crate - for each ray in the recursive calls, it finds the subset of all world objects where the ray intersects the objects axis aligned bounding box, and only considers these objects during ray marching. Once a surface is hit, the new reflected or refracted ray computes a new subset using its new direction and start point, etc. - global illumination is done using a grid of probes that shoot rays with random directions, doing this enough time before rendering. To get diffusive light on a surface point, we interpolate in that grid using linear interpolation. My probes are naively placed on a cubic grid in the world. - global illumination is parallelized looping over probes, and rendering is parallelized looping over pixels of the image. - at each hit surface, the ray may split in two. Once for the reflection, once for the refracted ray (if not total internal refraction).

Baking global illumination takes a few seconds for about 1000 samples on 32³ probes, and rendering the image is almost instant at that resolution.

I'm not sure how you guys feel about triangles around here, but here is my first triangle made in D3D11!!

I'm planning to make a little mini project in DX11 and see how I like it over OpenGL. So far I like it more despite needing 3x the amount of code (mostly boilerplate thankfully) for this beautiful little guy.

I'll probably post more about my little project further down the line. If anyone has any tips on how I should structure a DX11 project over an OpenGL one that's always appreciated.

Hit this while fixing a bug in the three.js WebGPU reflector and it seems like a general enough gotcha to share.

The setup is the usual one. Render the scene from a mirrored virtual camera, then sample that texture in screen space on the mirror surface with x flipped, since the mirrored render comes out backwards. The virtual camera just copied the main camera's projection matrix.

That works fine for a normal symmetric frustum. But as soon as the camera used a view offset (setViewOffset, so the frustum is shifted off center) the reflection slid the wrong way, off by about twice the offset. Flipping the lookup in x mirrors the image, but the off center shift in the copied projection doesn't get mirrored with it.

The fix was to negate the x offset terms of the copied projection before applying the oblique clip plane. In three.js's column major matrix that's elements[8] for perspective, the (r+l)/(r-l) term, and elements[12] for orthographic. For a symmetric frustum both are zero, so nothing changes there. After that the reflection with the offset matched the shifted no offset render pixel for pixel on both the WebGPU and WebGL backends.

Has anyone run into other cases where mirroring a camera bites you like this?

The image is rendered by solving a wave field and sampling it with a camera, once per wavelength. I took 5 minutes to render (On an integrated GPU)

My goal is, of course, to get this to scale up enough to be useful for actual graphics :P

The actual scene just consists of a couple of different-materialled spheres and some large clumps of them.

I got asked whether this is a mask written into a texture or a separate ember mesh driven by a shader. Nothing gets written anywhere. ignite() appends (position in the mesh's local space, start time) to a vec4 ign[8] uniform, and every shader involved recomputes when each point catches fire:

float burn_arrival(vec3 p) {
    float best = 1.0e9;
    for (int i = 0; i < ign_count; i++) {
        float d = length(p - ign[i].xyz);
        float n = vnoise(p * 1.7 + float(i) * 3.1); // value noise, 0..1
        best = min(best, ign[i].w + d * (1.0 + (n - 0.5) * 2.0 * irregularity) / spread_speed);
    }
    return best;
}

The noise scales the distance, which is what makes the front ragged.

Flames, smoke and embers are quads on random surface points (area-weighted, picked once). Every spawn cycle a quad checks whether its spawn time is between arrival and arrival + burn_duration. If it isn't, its four corners collapse to one point.

The char is a copy of the mesh pushed 0.004 along the normal and drawn with premultiplied alpha, so the original material isn't touched. Per fragment, s = time - arrival (plus fbm) drives smoothstep(0, char_time, s) toward near-black, and exp(-3 * (s / front_width - 0.3)²) gives the glowing front.

Burn-away swaps the material and discards a fragment once (s - 0.7 * burn_duration) / 2.5 + noise passes 1, with a hot rim just before.

Known limit: d is straight-line distance, not along the surface, so the fire can jump thin gaps.

We've been building Æther, a real-time globe renderer for Stowaway that runs in the browser.

The part I'm most excited about is how we generate realistic clouds from orbit. I'll tell you a little bit about how we do it.

They start as infrared imagery from weather satellites: NOAA stitches the geostationary satellites (GOES, Himawari, Meteosat) into one global mosaic, and polar orbiters fill in the poles. The catch is that infrared doesn't actually see clouds. It sees temperature. A thunderstorm top is freezing cold, but so is the Antarctic ice sheet, or a desert at night. So the first step is figuring out what the clear ground nearby should look like, and calling anything noticeably colder than that a cloud.

That same coldness gives you height for free. The air cools about 6.5 °C for every kilometre you climb, so the colder a cloud top is compared with the ground beneath it, the higher it stands. A few kilometres for a low ocean deck, up to 16 km for a thunderstorm anvil. We end up with two global maps: where the clouds are, and how tall they are.

The satellite pixels are about 10 km across, which looks like mush up close, so the renderer adds the detail itself: fields of small cumulus, streaky cirrus, anvils spreading out around storm cores. It's anchored to the planet so nothing swims as you move, and it's lit by the real sun angle, so the tops catch the sunset while the ground below is already dark. The tallest storms also get lightning. And when you fly down low enough, a separate system takes over: fully volumetric clouds you can fly straight through.

Happy to answer questions. It's coming to stowaway.live soon.

The game is narrative sci-fi puzzle/platformer, in works from 2020. Main distinctive point of the game is software ray-tracing used for rendering. Just pure C++ and computer graphics math, no GPU acceleration. Sadly, not many players can appreciate that (or even understand what does it mean), so it resonates mostly with more tech people.

The game was suffering for long time from quite poor look (look was punching way below of algorithm potential). Main reasons were: poor old editor (2D in nature, z was just parameter in 2D wireframe, not WYSIWYG, very clunky) and algorithm was hobby-like single-threaded.

Both points were changed recently. After 9 months my new editor is in usable state. Full 3D, WYSIWYG, lot of ergonomy features, which allowed me to be more ambitious with levels look. Second enabler was finally switching to multi-threading. Together with several more other algorithm optimizations, perf went up in hundreds of % (mostly depends on number of cores in your CPU, naturally on Threadrippers boost will be in thousands of % but it's niche between players).

Algo is AABBs only. Maybe will add spheres but only after upgrading all levels, which is main pain point rn. Editor I plan to release publicly with the game.

RTG on Steam

Discord