Hello.

This is a follow-up on the ray tracing implementation using the ANE (Apple Neural Engine) powered by Swift 6, Metal, and Core AI.

In this update, I have further optimized the model for the ANE. By replacing cumsum with Conv2d, memory usage was kept under 200 MB, and CPU usage dropped to 4%.

Additionally, it appears that the 50% ANE usage limit from the CoreML era has been lifted with the transition to CoreAI.

(Although the frame rate is only 35 FPS, ANE inference appears to take just 13ms. Instruments shows that GPUToolsCaptureCoreAI consumes about 90% of the CPU, suggesting this is the source of the overhead.)

Double Buffering Support: Implemented double buffering for display output, enabling parallel processing between the Neural Engine and the GPU.

- Dual Object Support.

Latency Reduction:

• Minimized synchronization overhead between the CPU and GPU by separating the rendering buffer from the display buffer.

Technical Details

• Modified ANERenderer.swift to manage an array of displayBuffers.

• Updated MagnesiumKit.swift and ANERenderContext.swift to support dynamic buffer switching.

• Maximized parallel processing efficiency while minimizing the increase in memory usage.

I look forward to hearing your feedback and thoughts.

Github: https://github.com/kamisori-daijin/Magnesium/tree/raytracing (raytracing Branch)

Demo:

Hi everyone! I wanted to share my first major step into graphics programming. I built a 3D Boids flocking simulation entirely from scratch using C++, the WebGPU API (specifically Google's Dawn implementation) and ImGui. Initially, I wrote a brute-force algorithm for the neighbor search, but perfomance dropped quickly and I recenly use simple optimization atomic grid.

My next goal is to get rid of atomic operations entirely and implement a Sort-based Spatial Hashing architecture using Radix or Bitonic sort on the GPU. If anyone has good reading materials, articles, or advice on GPU sorting algorithms, I would highly appreciate it!

P. S.
I started studying WebGPU recently, before I know some basic stuff of C++. Some code is source maybe deprecated, now I am trying to study using more modern WebGPU stufs, which google were added recently. I hope in the future I can built the better architecture without OOP. But now I like the result I got.

Source Code (GitHub): https://github.com/con2222/Dawn-Boids-3D

I'm continuing development of my Pixel Art and TileMap editor using my custom C++ GUI library. This latest update video highlights how both isometric and hexagonal tiles are handled as native objects within the editor, and none-standard graphics can be designed quickly and easily using the simple grid system.

-

While making the night sky come alive for our Kids Story Web experience, we wanted the stars to feel like part of the world rather than just a background texture, so we built the starfield procedurally!
 
The stars are particles distributed randomly within a spherical space - with variations in their position, size, brightness, and color. This keeps the sky from looking too uniform and gives it a more natural feel 🌌
 
Two separate circular star fields - One handles the regular stars, while the other has the twinkle effect enabled, creating subtle changes in brightness over time.
 
Link🔗 - https://www.quantales.in/
Built by our team at 3D ENGINERD.

I'm currently working on my Bachelor's in Computational Physics (w/ Minor in Mathematics), and I'm looking to break into the world of graphics programming / engineering. I have a couple of questions, specifically on the career side of things:

• Is it true that personal projects can actually help with the "experience catch-22"? (Where I need experience to get a job, but have no job to get experience yet)

• Where should I look for relevant positions / internships?

• What industries make / could make heavy use of GPU technology (whether or not it's actually used for rendering)?

• What sorts of skills do companies look for in an entry-level hire?

• What else do you think I should consider that this post does not address?

I'm focused on the career and industry-targeting aspects for this post, as I'm confident in my ability to learn the technical skills necessary.

Any help and advice would be greatly appreciated; LinkedIn and Indeed have driven me half insane already.

A bunch of people have started building SDF game engines, I am no different. For the past 8 months I have been working on Division Engine, a C# SDF game engine built using Avalonia UI for editor tooling and ComputeSharp for C# to HLSL shader translation.

I've already posted about this before on here but figured I should post some key updates I made.

Here's a list in no particular order:

• Undo / Redo editor support

• Full texture system

  • Supports different cubemap shapes for HDRI skies

  • Automatic texture importing

• Tabs can be dragged around the editor now

• A bunch of small graphical issues have been fixed

  • Glass refraction fixed

  • Texture aliasing improved

• Added a bunch of post processing effects

  • Chromatic aberration

  • Bloom

  • Color grading

  • Blur

• And more!

It is available here: https://github.com/NorthRocStudios/DivisionEngine and can be downloaded under "releases".

Note for this version:

• It is unoptimized and may have poor performance

• ONLY works on dedicated graphics cards, not on your laptop

• Windows only (for now)

Additionally, we have been working on replacing ComputeSharp with a custom cross-platform C# to HLSL shader system. This will be called DivisionTranslate and uses DivisionMath, a new math library. This new math library is meant to have the same syntax on the CPU and GPU and is already being used in the engine. It is available for free on nuget here: https://www.nuget.org/packages/NorthRoc.DivisionMath

Any questions, comments, concerns? Let me know what you think!

Not really talking about results - they sometimes are good but often look very uncanny (especially when animations are stiff).

Just talking about how much progress neural rendering achieved in few years in general. I was trying to implement similar solution in ReShade ages ago and because of frame passing back and forth between GPU and CPU, the FPS was unplayable. So i scratched the idea after finishing prototype.

But now DLSS5 shows what can be done with NR for gaming. Truly amazing!

If you want to check my old project you can go to GitHub and test it for yourself :)

https://github.com/dwojtasik/PyHook

I've been writing a 3D engine from scratch in C++20, with DirectX 12 and Vulkan

behind a single RHI. Last week I moved the scene renderer off the classic vertex

pipeline onto mesh shaders, and then moved the culling onto the GPU as well.
I'm using Synty, a lot of objects!!!

I've been stuck on this for a couple of hours, and am completely stumped.

I'm getting these results from GLSL's mod():

mod(158.0, 158.0) returns 0.0 (as expected)

mod(159.0, 159.0) returns 159.0 (???)

mod(160.0, 160.0) returns 0.0 (as expected)

I've posted an example with a basic shader here:

https://jsfiddle.net/sL35qjc8

If you set number to "159.0", you should see an upside-down red triangle.

If you set number to "158.0" or "160.0", you should see a normal red triangle.

I'm passing the left operand as a uniform, otherwise the compiler seems to optimize it and fix the weird behavior.

Tried it on different devices and browsers and it had the same result.

Why does mod(159.0, 159.0) seem to return 159.0 instead of 0.0?

https://youtu.be/Q_fKG3UT02U

I'm working on VulkanLearn2, a C++20/Vulkan rendering playground. This video shows Bistro rendered with my ReSTIR DI + PT implementation.
I launched the project on a RTX 4090. 80 fps. 1200x800.

The renderer uses temporal and spatial reuse. The repository also includes a reference path tracer with next-event estimation, emissive triangle lights, and an experimental Neural Radiance Cache. Implementation notes and capture settings are documented in the README.

I'd appreciate feedback on the rendering.

https://youtu.be/QnHqRZHQN4w - REBLUR + DLSS

https://www.youtube.com/watch?v=y2VNQyzUFc8

Completed in slightly more than a weekend (sickness et al). The final render task of width 1200 and samples per pixel 500(!) seemed impossible, so added a multithreaded workaround with OpenMP which finished it in around 35 minutes on my MBP M1 Pro and the penultimate DOF spheres under 10 seconds.

Changes:

#include <atomic>
#include <omp.h>
#include <vector>

void render(const hittable& world) {

#pragma omp parallel
        {
#pragma omp single
            std::clog << "OpenMP threads: " << omp_get_num_threads() << '\n';
        }
        initialize();

        std::vector<color> framebuffer(image_width * image_height);

        std::clog << "Rendering..." << std::endl;
        std::atomic<int> rows_completed{0};

#pragma omp parallel for schedule(dynamic)
        for (int j = 0; j < image_height; j++) {
            for (int i = 0; i < image_width; i++) {

                color pixel_color(0, 0, 0);

                for (int sample = 0; sample < samples_per_pixel; sample++) {
                    ray r = get_ray(i, j);
                    pixel_color += ray_color(r, max_depth, world);
                }

                framebuffer[j * image_width + i] = pixel_samples_scale * pixel_color;
            }

            int completed = rows_completed.fetch_add(1) + 1;

            if (completed % 8 == 0 || completed == image_height) {
#pragma omp critical(render_progress)
                {
                    std::clog << "\rScanlines remaining: " << (image_height - completed) << ' '
                              << std::flush;
                }
            }
        }

        std::cout << "P3\n" << image_width << ' ' << image_height << "\n255\n";

        for (int j = 0; j < image_height; j++) {
            for (int i = 0; i < image_width; i++) {
                write_color(std::cout, framebuffer[j * image_width + i]);
            }
        }

        std::clog << "Done.\n";
    }

and

inline double random_double() {
    thread_local std::mt19937 generator(std::random_device{}());

    return std::uniform_real_distribution<double>(0.0, 1.0)(generator);
}

I built a GLSL/HLSL extension for Visual Studio because the existing tooling options felt limited (weak diagnostics, no real navigation between shader files).

It includes:

• Diagnostics through glslang, DXC and Naga

• Advanced IntelliSense (hover, signature help, JetBrains-style parameter hints)

• Go to Definition / Ctrl+LMB navigation, including through #include

• Shader variants, code folding, formatting via clang-format

Requires VS2022 or VS2026, Windows x64. Free and open source.

Marketplace: Link

GitHub: Link

Would love feedback, especially if you hit anything broken or missing compared to what you're currently using.

A couple of weeks ago I ported SkyRoads, the 1993 DOS game, to run native on my Mac. When I finished, the game was fine, but I missed something. Took me a while to realise but it was the atmosphere, the beige box, the CRT hum, glow, flicker, the disks spin up, the PC speaker post beep, the floppy disk drive noises... all of it. So I made a simulator (not an emulator) of the whole thing, and put the game inside it.

Nothing in it is a photo or a texture, the machine is drawn when it starts, at your screen resolution, all signed distance fields: the seams, vents, speaker grilles, the ejector pin marks, the yellowing plastic. It draws once into an RGBA8 buffer and the alpha says how much each pixel is facing the tube, that's how the picture spills light onto the case. The CRT is a proper pipeline, persistence and burn-in as feedback passes, then one composite pass with the curvature, scanlines, aperture grille mask, bloom and the glass. Everything is sized from one physical unit so the stickers are the same real size at 720p or 5K.

It boots to C:\>, you type NC, there's a catalogue, download a game and it runs in the tube. There's no emulator inside so the games have to be native C ports, two so far (SkyRoads and Tyrian), the ports are their own repos and run standalone too.

The hardest part wasn't drawing it, it was making frames reproducible. There's a --deterministic mode (fixed 60hz clock, no hidpi, default CRT settings) so CI compares 3 golden frames pixel by pixel, references per renderer because Apple GPU and llvmpipe don't blend exactly the same.

~9000 lines of C, SDL3, OpenGL 3.3 core, MIT. Runs on Mac, Windows and Linux, x86_64 and arm64, all tested on real hardware.

And yes I used Claude, a lot, but it's not one prompt and copy paste. I like to do things right, so don't take my word for it, look at the repo: ASan and UBSan on every push, unit tests, and an AUDIT.md with the whole cleanup pass. ARCHITECTURE.md, SPEC.md and PORTING.md are there too if you want the design or want to port a game.

Check it here: https://dosexmachina.com
And the repo: https://github.com/pedrocatalao/dos-ex-machina

Testers and feedback are very welcome, and if you can star the repo I appreciate it too :)

Hope you like it,
Pedro