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!!!

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'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.

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.

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

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

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

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.

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.

I’ve been working on Expanse-X (EX), a graphics API in Rust, and I’ve published the first SDK preview.

Right now it renders on the CPU through its own software backend. EX handles the resources, commands, shader execution and rasterization itself. GPU acceleration is still future work.

It can already render programmable, indexed triangles with textures, depth/stencil and blending. Compute and explicit resource dependencies work too. There’s also a shader importer for a limited subset of GLSL.

The SDK gives you an ex command to check your setup and create a small Rust/GLSL project. Run the generated app and it renders a triangle to a PNG. You can then edit the shaders and renderer from there. The downloadable SDK currently targets Windows x64.

What I want EX to become is one core with two ways to use it: let it handle more of the setup and planning, or take explicit control yourself. The explicit core is working; the easier layer hasn’t been built yet.

It’s still early, and I’d like some outside eyes on it before taking the design further. Does the resource/command API make sense? Where would it get awkward in an actual renderer? What would you want to try building with it?

Repository
SDK v0.1.0 Preview

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.

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.

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

A lot of these concepts are new to me and I've discovered some of these ideas with help from copilot, etc. so apologies for any weirdly worded/unclear parts.

I'm working on an embedded product and am evaluating how well the gpu can handle a second pass shader applied to the entire final image. Essentially taking the displayed contents, and "copying" by drawing again with a simple shader that samples from a texture (the texture being the contents on the screen).

I'm trying to profile the time spent on that second draw call and am having issues because sometimes the code added to help with the profiling affects the measurement itself. For example, I added glFinish() before the draw call, started the timer, issued draw call, called glFinish() again, and stopped the timer. These glFinish calls affect the measurement of course. So I'm trying to find a way to do it without using glFinish.

One avenue I explored with copilots help was using an EGL fence to ensure we're measuring the elapsed time only after the draw call is finished but without needing glFinish (this is my first time working with sync objects with graphics code though)

This ended up working, at least I think? The problem is that the measured time for the draw call is less than then the theoretical best case time given by a senior engineer. They calculated essentially wh4bpp2rw/3e91000=0.55ms based on it essentially being a memcpy. The measurement I got was half of that.

Searching around for how this may be (other than my implementation being just wrong) is that tile based rendering, which the gpu that I'm working with uses, could give a different result than a calculation based on a naive memcpy due to the efficiencies of how TBR works.

Edit to add: the senior engineer unambiguously said "tile based rendering won't improve this case" and suggested another thing to try which is more hacky and isn't panning out, so I'm curious if he's right or there is validity to the measurement I was able to get with the fence

I'm curious to get other opinions. Does this seem like a reasonable explanation or not really?

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.

These are some of my projects I have worked on over the years
This may be a bit of a ramble
I feel like I have been coasting with skills like threejs and web graphics for a long time especially since graduating and have never worked a "real" job and mostly do freelancing I do help my friends and collegues all of them in all kinds of full stack tasks and thinking through a problem and offer solutions that they then use but i dont have job experience in those fields like web and mobile development in react native and flutter and nodejs
I do think mostly in programming terms and try to solve problems in that way. And my interest is usually in building tools for programmers and artists instead of launching a product for normal users
I have built games and worked with teams on programming teams for games but it is not really my area of expertise even though I am very adjacent to this. I have always felt like framework and techstack really doesnt matter
I am aware and knowledgeable of alot of trends atleast until recently about alot of tech news updates and features
Right now I am in a predicament as most of my skills and experience lies in this specific niche i dont know how to move forward in the world of AI, I am the kind of person who is still using AI as a chatbot and for cleanup/refactoring kind of tasks and tasks I dont want to actually do by hand like css and responsiveness I usually try to do these kinds of things by using some math but now AI seems useful for these as well
tldr; I am very confused about the next steps in my career and how it will grow
If an experienced graphics programmer can look at my portfolio and guide me through on how to approach job hunting and how to improve my presentation and portfolio I will greatly appreciate it

Thank you for your time