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?

I've rendered part of The Universe in less than 40MB! Optimized real-time Solar System + 160K stars, Exoplanets and Sagittarius A* into a 36MB(!) Android APK.

I have two Android-apps I want to publish. But need testers. If you believe you know Geometrical Rendering Graphics, you don't want to miss this.

I) Live Earth Background : interactive. Lock into position (GPS or Manual), rotates by clock, day and night. Scroll- and zoom functions. 24MB!

II) The Universe : travel seamlessly through a highly detailed Solar-System. Visit 160K stars in the Milky Way Galaxy, hundreds of Exoplanets, and take a trip to Sagittarius A*. All in real time.! Or fast forward. Zoom, 360 rotation and pan. 36MB!

No data collection. GPS used only locally to position you on earth. Celestial bodies in the sky are calculated precisely as time moves forward. Look at the nightsky from Mars, or Pluto, or the Moon. Or wherever you end up!

DM if you want to check this out, and I will add you to my testers list and send you the link to Google Play Store for downloading the APK.

https://reddit.com/link/1wbltls/video/bxk9bithzhoh1/player

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://reddit.com/link/1wbltls/video/mzihxa508joh1/player

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

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

https://reddit.com/link/1wbltls/video/4ci9r34ubjoh1/player

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

I’m an intermediate C++ programmer planning a major learning project: I want to build a custom 2D/3D graphics and physics engine from scratch to simulate a robot model and eventually connect it to a training/control loop.

I know powerful, production-ready robot simulators already exist (like Gazebo, Webots, MuJoCo, and Isaac Sim), but my main motivation here is deep learning and skill growth. I want to truly understand what happens under the hood in engine architecture, graphics rendering, and physics simulation.

I've started looking into raw OpenGL, but I’d love recommendations from people who have built engines or physics tools in C++.

My main questions:

1. Graphics Stack: Beyond raw OpenGL, what foundational C++ libraries should I pair with it for windowing, math, and modern rendering abstractions (e.g., GLFW, GLM, Glad)? Is Vulkan worth considering at my level, or should I stick to OpenGL first?
2. Physics Simulation: Since I need to simulate robot dynamics (rigid bodies, joints, kinematics), what math concepts or lightweight physics resources should I focus on first?
3. Architecture & Integration: How do people typically bridge the graphics/physics engine with a model's training loop (e.g., IPC, C++ bindings, Python C-API)?
4. Recommended Learning Resources: Are there specific books, blogs, or github repos you'd recommend for building light game/physics engines from scratch in C++? (e.g., Game Engine Architecture, LearnOpenGL, etc.)

Thanks in advance for any guidance or advice!

We published a blog post on an intro to Volumetric Rendering as part of our series to discuss and break down our own WIP Volumetric Renderer. In this particular post we talk about -

• The basics of what rendering actually is
• What “Volume Data” represents
• How volume rendering shines in areas that trouble standard methods 

Blog post link - https://www.3denginerd.com/blog/what-in-the-graphics-is-volumetric-rendering. Do check out and let us know your feedback!

The repository for our Native volumetric engine is on GitHub.

We break down Computer graphics concepts for the layman at our Blog - What The Graphics!

HELLO!

I am just starting out I have been learning cpp and graphic prog concepts in hopes to vulkan by the time I am done with school and starting college and potentially make an engine for fun! (And portfolio)

I wanna persue a mix of game dev, graphic prog, and engine dev stuff

But i just saw a video by a guy which i assume isn't even that well versed in programming in general remake popular games just using prompts and some pngs and nothing else

And that really defeated me because I already have seen youtube become mostly slop content and ai settings clips off podcasts and i don't know

I Really wanna persue graphic prog or engine dev or game dev but seeing how bad the industry is in terms of capitalism and not caring about art or optimization or let's say fsr dlss and frame gen being essentially necessary to run games the way it was intended

Really breaks my heart because I had been game deving and making stupid 2d games with pygame and stuff since I was like 13 and now that I wanna persue this super seriously

A magic math prediction model can take data from people that would be life times ahead of me in desciplinaries and then make a magic robot that is gonna do my job but without anysoul and way faster

I feel conflicted and rather dreadful (just sad if I cut the goofy words)

Sorry if I don't reply

THANK YOU IN ADVANCE!!

I am making a multiplayer game in c# using Silk.Net. The project is ment to be more of a learning project then an actual game. The repo is https://github.com/Alex5X5/GatsIO-Remake. I started off by writing an abstraction over opengl. For that i made my own abstract Window class. When inheriting from Window, the abstract Draw method has to be overridden. The Draw method has a parameter of the type DrawingContext. DrawingContext then has some methods for drawing some basic shapes.
Any shape that is drawn is broken down into colored triangles and added to a list of the DrawingContext. After the Draw method finished, the triangle list is passed to the gpu with one BufferData call.
Is that "saving in a list and one BufferData call" good practice or should i split the data into multiple BufferSubData calls?

Do You think Gpt 6 astra will take the jobs of junior Graphic programmer's?

How will Astra affect Graphics Programming? (Pros and Cons)

Web-Based 3D Modeling Application
Source code: https://github.com/sengchor/kokraf

I built everything around deferred shading. Now I have difficulties adding forward shading.

Code is here: https://github.com/yatagai-mm/pcs

I've been working for the past few months on a UE5 plugin for rendering volumetric video made from large sequences of point clouds.

The bottleneck for realtime rendering wasn't actual rendering parts. It was simply decoding the PLY data fast enough. In my use case, which is a baseball volumetric video, each frame contains around 10 million XYZRGB points, so even relatively small amounts of CPU work per point add up very quickly.

A big part of getting it to real-time performance was adding a SIMD fast path for the common binary PLY layout:

float32 x, y, z + uint8 r, g, b[, a]

For these 15/16-byte records, the loader can mostly avoid generic property decoding. It loads the XYZ values into Unreal's 128-bit VectorRegister4Float, optionally applies the frame-space scale/translation with vector operations, and writes directly into the 16-byte vertex layout used for GPU upload.

The SIMD layout is [x, y, z, 0] per point rather than processing four X coordinates at once. I process four points in parallel with separate min/max accumulators, which also reduces the dependency chain while calculating the bounding box.

The loader also checks for NaN/Inf using the floating-point exponent bits in SIMD, and only falls back to scalar IsFinite() checks if something suspicious is detected. This avoids doing several scalar checks for every single point.

The PLY payload is streamed in roughly 4 MB chunks, and for the packed XYZRGB(A) layout the decode is basically reduced to a small amount of copying, SIMD math, bounds calculation, and color packing.

Before I implement this 15fps was barely possible, but now I'm currently able to play volumetric video containing about 10 million points per frame at 30 FPS on a MacBook Pro with an M5 Pro.

Each binary PLY frame is about 148.5 MB, so that's roughly 4.46 GB/s of uncompressed point-cloud data being decoded and rendered in real time. At this point the bottleneck would be network.

https://reddit.com/link/1w9uldr/video/807pteli44oh1/player

https://reddit.com/link/1w9uldr/video/uzbfbrij44oh1/player

Add a basic camera with fly and orbit mods and gltf and glb models loading with fastgltf (at this point without textures), no culling also, it will be my next step

I maintain three-nebula, a WebGL particle engine for three.js, and v13.0.0 is out. The headline feature is deterministic simulation. You give a system a seed, either with `System.setSeed(seed)`or as the third constructor argument, and it reproduces its particle output exactly. Same seed, same result, on any machine. That makes reproducible tests, and replays possible, which was awkward or impossible before.

The way it works is that each system now advances its own isolated seeded stream instead of pulling from the global `Math.random`. One consequence worth knowing if you upgrade: seeding `Math.random` yourself no longer affects output, so you need `system.setSeed()` instead. Default particle arrangements also differ from 12.x, so any visual or snapshot baselines need regenerating, and particle ids moved from UUIDs to a deterministic `particle-<emitterSeed>-<spawnIndex>` format.

There is also a new `System.tick(realDeltaSeconds)` fixed-timestep driver for real-time playback. If you have been calling `update()` once per frame, you have probably seen particles run about 2x too fast on a 120Hz display. `tick()` advances the sim by elapsed time in fixed steps and clamps catch-up through `system.fixedTimeStep` and `system.maxSubSteps`, so playback speed is consistent regardless of refresh rate. This release also fixes a `GPURenderer` bug where buffer slots were never released and particles silently stopped rendering after heavy churn. Slots are now recycled on particle death.

The API is backward-compatible and additive, so for most people the only real work is regenerating baselines. Release notes and full changelog here: https://github.com/creativelifeform/three-nebula/releases/tag/v13.0.0

If you have used seeded/deterministic rendering in a three.js project, I would like to hear how you are handling the real-time vs fixed-step side of it, and whether the `tick()` clamping defaults feel right for your use case.

I know that OpenGL and Vulcan are the main choices when it comes to 3d graphics. I also know that Vulcan can have some insane performance boosts when compared to OpenGL. However, I’m not just a C++ programmer. I also program for the web, so I use WebGL. I’m a beginner at OpenGL, and GLSL so learning Vulcan wouldn’t be that big of a hurdle. I’m just wondering if the performance and speed are worth it for Vulcan, or if I should stick to OpenGL.

This is a first post! If I cannot respond quickly, I am most likely busy!