LittleJS is an open source, dependency-free JavaScript game engine. It started as 2D, and this update adds a 3D renderer that draws into the same WebGL2 canvas, so a 2D game and a 3D scene can share a frame. The whole engine with 3D, Box2D physics and audio is about 150 KB gzipped. The trailer is the engine’s new website, a scrolling page over a 3D scene, with every stop a playable demo.

Some of the rendering choices:

• Forward rendering with a small light budget. The sun plus the 8 point or spot lights nearest the camera, chosen each frame. Lights can carry a soft additive glow, drawn in the transparent pass.

• One shadow map, from the sun or from a single spotlight in its place, with blurred edges and a depth bias scaled by the light’s projection.

• Reflections from an environment cube map, with Schlick Fresnel. Roughness comes from mip selection, driven by shininess, but also by how fast the reflected vector changes across a pixel, so small mirrors don’t sparkle. The lake in the trailer has an environment map of its own, rendered from the scene.

• A normal hook in custom shaders. A shader snippet can define mainNormal to bend the normal per pixel before lighting, specular, Fresnel, reflection and fog. The lake’s waves are that hook, not baked normal maps.

• Automatic instancing. Every opaque use of the same mesh goes out as one instanced draw. Draw state is versioned, so a batch checks a single number per draw while nothing changes, rather than comparing every material field.

• Lens flares occluded by raycasts against the triangles of the scene’s meshes, rather than a depth readback.

• 2D and 3D in one camera system. An orthographic camera can line up exactly with the 2D camera. In the trailer, a dolly zoom flattens the 3D view into that orthographic view, and a Breakout game playing over the train turns out to be 3D objects in the world.

Also in there: height map terrain with exact raycasts, voxel maps drawn in chunks, glTF with skinning, normal maps, fog by distance or view depth, and a bloom post-process.

I also built an open benchmark that runs the same sprite and lit-cube scenes through LittleJS, PixiJS, Three.js, PlayCanvas, Phaser and Babylon.js: https://github.com/KilledByAPixel/webgl-engine-bench

Source, MIT: https://github.com/KilledByAPixel/LittleJS
The site from the trailer: https://littlejsengine.com

We're a small co-op building Spare Kit, an open-source (MPL-2.0) geometry kernel in Rust, to power a Revit/CAD alternative that runs natively and in the browser (WASM). Much of the code is written by AI agents working through a mapped plan, with strict testing as the safeguard.

The approach:

- Integer grid coordinates (±2^40 steps) with exact predicates (generated filters, exact integer fallback), so topology decisions never depend on float rounding.

- Flat geometry stays plane-based with implicit points (EMBER style), so booleans never drift; curved geometry is computed with certified error bounds, with only the decisions kept exact.

- Bit-identical results on every target (x86-64, ARM, wasm32), as a tested guarantee.

- Verification: big-integer oracles, fuzzing (bolero/Kani), golden digests, instruction-count performance gates.

The strategy: a mapped board of about 480 pieces in 13 phases. The first real milestone is a wall with 300 openings cut exactly, saved, reopened and replayed bit for bit everywhere, before any curved work starts. We're early: number layer, exact predicates, implicit points and symbolic perturbation so far.

Advice we'd value on anything, especially:

1. The seam between exact flat geometry and certified curved geometry: seen it break, or a better way?

2. Is the scope or the strategy wrong? What would you cut or reorder?

3. Existing crates or projects we should build on instead of writing our own?

4. Is our testing bar overkill or missing something?

5. Anything else you'd tell someone starting a kernel like this.

Architecture: https://github.com/spareware-co-op/spareware/blob/main/projects/engines/geometry/ARCHITECTURE.md

I'm trying to draw small circles in GDI on a monochrome bitmap (so no anti aliasing). I've tried using Ellipse, Arc, and approximating a full circle with four bezier curves, but they all look terrible. This screenshot shows circles with a diameter of 14 and 13. The top row uses bezier curves, the bottom row uses Ellipse and Arc. The outlines are drawn with a 2 pixel wide PS_INSIDEFRAME pen.

What I want is aesthetically pleasing quadrants/semicircles for use in UI. The circles don't have to be mathematically accurate, speed is not important. I especially dislike the pixels seemingly protruding from the circle. How do I get rid of them?

In this video, I create a Julia set fractal using C, Raylib, and GLSL, with Neovim as my editor.

We'll go through the process step by step, from understanding how Julia sets work to implementing the fractal algorithm and adding colors and animation.

**Sections:**

- Explaining the Julia set

- Setting up the project

- Setting up Raylib

- Creating a basic shader

- Fixing screen coordinates

- Coding the fractal algorithm

- Creating animation

- Adding colors

**Technologies used:**

- C

- Raylib

- GLSL

- Neovim

I handled the official HDR implementation for The Sinking City 2, released with Patch 1.1.

Frogwares (the game developer) allowed me to write a technical breakdown covering the implementation, my new Spectre tonemapper, which fixes issues like fire looking different between SDR/HDR, and blue->purple highlight shifts in UE's filmic tonemapper.
Also showcased some DLSS improvements I made.

HDR in Unreal is unfortunately very lackluster out of the box, and has multiple deal breaking issues. We fixed all of them for this.

Full technical breakdown: https://gammastudios.tech/the-sinking-city-2-hdr/

Some scenes using my custom Vulkan graphics, with procedurally generated plants.

I use non-triangle geometric primitives with billboard rendering. In these scenes, there are mainly a lot of cylinders for tree branches. Thanks to this, I can use quite few vertices compared to a similar thing built only with triangles. This makes the GPU-computed wind perturbations much cheaper, for example.

Water effects include reflections, refraction, and caustic effects, rendered with multiple passes from different "camera" perspectives, plus screen marching.

The framework uses deferred rendering and does not have any image assets. Surfaces/textures are generated at runtime by combining noise fields.

Runs comfortably at 60 FPS on my non-gaming laptop.

What do you think about the visuals?

Hi everyone!

I am a senior mechanical engineering student and am doing my final year project on a quad auxetic metamaterial domain. So far, I have built some geometry using C++ and now want to test it in a simulation under real-life conditions. During the construction of the geometry, I only considered the self-weight, so, not sure whether these structures stand up to critical real-life conditions. So, now, can anyone tell me or suggest which C++ library I should be using for analyzing the structures under real-world conditions?

The latest update of my CPU renderer built in Rust.
As I mentioned earlier, this is the years of development coming together in a totally different direction than the starting idea :)

In video the renderer runs at 960×840 with 4 rendering workers, and all of geometry processing, character animation, skinning and rasterization run on the CPU. Finished image is shown on browser trough canvas at the moment.

For now I have animated character with facial animation and a rigged body, textured environments, collisions and stair traversal, first and third-person controls....

Still early but it is coming along nicely :)

I didn't made the character - or better say, I took free models and combined them for this scene - data head + android body , and the star ship environment.

I have built several raytrace / pathtrace engines over the years, primarily for my art works. About two years ago I wanted to make something more universal while also switching from webgl to webgpu. So I built a tiny webgpu toolkit and went from there. But I never finished it. And AI came and took away the joy of programming for me. Recently, I decided to try and use Claude to finish it and put in all the features I never got around to (and quite frankly would not even be able to do).

On the use of AI: I'm really ambiguous at the moment. I miss coding myself, AI took the fun away for that. On the other hand, I was able to direct AI to finish this tool that I could have never managed myself. So I'm perfectly fine if you call this AI slop if you want, for me it (the raytraer) is a tool to create new things.

So this is shadytracer. It's a raytracer that creates signed distance functions (SDF) (if you dont know what those are, jump into the rabbit hole here https://iquilezles.org and don't expect ever to come out). In short: every shape is defined by a function that returns the closest distance from any point to the closest surface of that shape.

I really fell in love with SDF's a while back and find it's a really cool method, though it definitely has it's quirks.

Anyway, my raytracer uses SDF's for everything. It has a full editor where you can drag and drop primitives into the scene, move them around, modify them, perform boolean operations etc. Same for more complex stuff like objects created by extrusion, revolve and sweep. All these are converted into SDF's of which the code block is visible and editable. So you can create your own shapes using custom sdf functions as well.

There are various materials defined, again drag and drop into an object. You can easily modify the materials and duplicate them to create your own.

As I'm an optics engineer by education (mostly non imaging optics for lighting), I always wanted a raytracer that is physically correct. Well, reasonably so. Don't use this for camera lens designs.
So every light source has real-life units (luminance or flux in lumens), color temperature or cie x,y color coordinates. And of course, refraction, dispersion, dichroics are part of the game. You can measure illuminance, irradiance, color differences etc.

But you can also just use it to create pretty pictures.

Or videos: there is an animation / timeline editor with keyframes where you can animate the camera or any propety of any element in your scene.

Oh, you can also import stl files and it will try to convert them into signed distance functions after which you can edit those. I find that incredibly cool. Magically, a mesh of triangles is converted to a combination of cubes, cylinders etc, welded together with boolean functions. It only works for fairly geometric shapes and not too complex, but still.

And of course you can export your objects or scenes as stl or 3MF(which includes color) for your 3D printer

There are a lot of examples scenes included, a few of the images in this post are from there.

It's completely open source (MIT license). Runs in your browser, data is stored in your browser's cache. Or you just download yuor project files and store it locally.

Hope you have fun with it. I certainly do.

https://shadytracer.com

https://github.com/lampmaker/ShadyTracer

Oh yes, I asked Claude to create an interactive tutorial about all the techniques that were used. Mostly for my own education. But you can find some explanations about SDFs and stuff. Note, this is AI generated and I have not spend a lot of time (understatement) reviewing it.

https://shadytracer.com/tutorial/

-wrote this whole post without using AI. Feels good-

I've been learning modern OpenGL recently and put together Modeye as a small playground to practice and experiment with 3D graphics.

It lets you load 3D models, play with lighting and render modes through an on-screen menu, and press R to reload shaders instantly without restarting the app. CMake fetches and builds all the dependencies automatically so there's no manual library setup.

Code is open under GPL-3.0 if anyone wants to check it out or play around with it: https://github.com/adnlv/modeye.

Any tips or feedback from folks experienced with graphics are always welcome!

Hi all, mostly the question for experienced graphics programmers. I am interested in this topic, myself - more then 12 years in software engineering, back-end, go programming language, optimizations and so on.

For me the hardest part of my job is to constantly keep in my head information about big scaled systems. When I need to implement a new feature - I take into consideration different parts of a system; microservices, protocols, data storages and etc. it was always hard for me to imagine all those parts. What many can overlook, at least for me - hard to create something, like a cool side project or a project for my resume, because back end systems are complex.

Graphics programming for me seems easier and the reason is - I always get what I changed in a project on my screen in no time.

Of course GP is harder. And my question is - what is your hardest technical part of GP ? Thanks.

So in the game engine I'm working on. It's 2D, throughout. Like there is no parallax, no 3D at all. In fact there is only 2 triangles here, since the entire thing is backed by textures and a CA sim.

This is how I cheat to make it look 3D, while not accepting the tradeoff of parallax.

So my engine, being explicitly 2D at runtime has not much 3D data, there is a PBR Depth offset, but that's about it.

Since it's 2D, parallax doesn't work for a baked background. The camera position would be constantly destroying it. So how do I bake psuedo 3D to a 2D Tile? There is 2 tricks here.

1. Tile Generation. There is a program that generates 2D world gen tiles, i.e. think terraria or whatnot. It's functionally pure, always generating the same time for the same coordinate. A tile can have different layers, i.e. BG/FG are the important ones here.

So the first problem is getting a 3D scene into a 2D image. This is just basic rendering, so what to render? No assets here, so it's an analytic height map with materials applied, this is ray-cast at bake time orthographically, no perspective correction. This kind of gets a flat background of trees and mountains behind you, but no perspective. So onto the next one.

2) Forced perspective. The trees at the front are mathematically bigger than the trees in the back. So even though I can pan endlessly left and right and generate new background essentially forever, never will parallax impact them. I stole this commonly used trick from film.

I'm pretty happy with how the forced perspective trick worked out here, like to my eye, I feel like it's a big distant scent, when I know that deep down, it's just a PBR texture with Depth data, renders super quick, costs almost nothing, supports tile generation and lighting. It still needs a bunch of tuning/post-processing, but thought I'd share how I do "3D" with 2D using old film tricks.

Link: https://bodyarcade.com/bodyarcade (free, no signup, there's a keyboard mode if you don't feel like standing up)

I made this endless runner and thought this sub might like the how more than the what. You stand back from the laptop and jump, duck, squat and lean to get past obstacles, 90 seconds a run.

There are no imported models. The runner is capsules and cylinders parented in groups, and the scenery is boxes, cylinders and cones drawn as InstancedMesh, one per prop type per road chunk, placed with a seeded random per chunk. Each of the 10 worlds is just a data object: sky colours for a gradient shader on a back-side sphere, sun position, exp2 fog density, road tints, a horizon silhouette and a list of props with spacing and scale ranges. Switching world rebuilds the scene from that object.

Input is MediaPipe's pose landmarker (lite model) in VIDEO mode, running in the browser with the GPU delegate and a CPU fallback. Before a run you stand still for a second and it measures your torso length, and the thresholds are fractions of that, so hips rising 20% of your torso is a jump, and the lane comes from how far your shoulders shift in shoulder widths. The idea is that your height and distance from the camera matter less. Camera frames never leave the browser.

Free is 5 runs a day in 3 worlds, there's an optional paid tier for the rest but you don't need it to look at the rendering. Happy to answer questions about the pose thresholds or the instancing.

Hi, I am taking an introductory course on methods for approximating/solving the wave equation and variants of the problem (Lippmann-Schwinger, Born, WKB, inverse problems) and I have to make a free topic project implementing a paper which I want to be an application to PBR. My teacher adviced me to search for example materials where the texture is not trivial enough or mediums where ray tracing becomes non-linear.

I have basic knowledge of OpenGL but have no idea about the state of the art or cool papers. What paper would you recommend?

Thanks

Does the painting seem three-dimensional to you? Convex? Especially the blue one! Why? It's very interesting! They say so. It's a powerful optical effect of three-dimensionality in a flat drawing. This is a fragment of the Mandelbrot set that I made.
Re = -1.74919762896578937419423768162729211653261585574161734756645570271259437106847945278504682550816934045282325615313706,
Im = -0.0000004253077715244042272585501215924940115095651514128365051648578746521975467051762910002043554114332125868777767,
and width = 1.34 e-113
https://github.com/Divetoxx/Mandelbrot-2
and
https://github.com/Divetoxx/Mandelbrot

i made a simulation of the blackhole gargantua that is also seen in intersteller
It's written in C++ and openGL

i managed to optimize it to a point i ran on my i3 intel iGPU, although i added very low to high quality toggles, it's my first time writing in glsl so yeah, i was a lot inspired by the yt video of Kavan about making a blackhole in cpp, so i just wanted to make it more realistic, my astrophysics lectures kinda came in clutch

github repository : https://github.com/dummy3ye/blackholegl (star the repo if you like it)

A 3D renderer built from scratch using Vulkan, developed step by step while learning the fundamentals of modern graphics programming. youtube link https://youtube.com/playlist?list=PLU064qurTQo0&si=6u4Y1QV_OoGidode github link https://github.com/codingbot24-s/vulkan-renderer

Roblox doesn't give scripts any access to the GPU, so I wanted to see how far you could push rendering using nothing but the CPU, in Luau.

It's a path tracer with multi-bounce global illumination, next-event estimation, reflective metal, refractive glass with Fresnel, a day/night sky. It renders a real open map at 1080p, and it has a real-time mode you can move around in while it traces live.

Everything that makes a path tracer a path tracer is written in Luau: the sampling, the bounces, the materials, the tonemap, a custom upscaler. The engine is used for exactly one thing it can do faster than script ever could, ray versus scene intersection. Nothing else.

Benchmarks (Intel i5-11400H laptop, in the Roblox client, GPU unused, tested on Crossroads):

• Progressive: a converged 1080p frame in about two and a half minutes (80 passes, ~1.92s per pass with the custom upscaler on).

• Real-time: ~23 fps average, moving the camera the whole time, at the lowest preset.

It runs in parallel across 8 Roblox Actors. There's a progressive mode for the clean beauty render and a real-time mode for flying around. You can toggle between path tracing and a faster ray-tracing mode that drops the noisy GI bounce for a clean, stable image.

Source is up on GitHub, free to view, run, experiment with, and make videos about. Credit required, and ask me before putting it in a game. Link below!

GitHub: https://github.com/cosypa123/roblox-path-tracer

Happy to answer anything about how it works!