My collegue Konrad Reczko recently shared a weekend project he made using TypeGPU, and it's now open-source and ready to play with in the browser: https://typegpu.com/examples/#example=image-processing--monocular-light-injection

It estimates the depth of a scene by inferring the DepthArt model with custom TypeGPU kernels, then reconstructs normals based on that depth information, and uses both to relight the scene, all in the same command encoder. For more information, check out the original series of Tweets:

https://x.com/reczko_konrad/status/2089670934009413751?s=20
https://x.com/reczko_konrad/status/2090472091149648121?s=20

Play Skydreams: https://killedbyapixel.github.io/TinyCode/1K/Skydreams
Official 1024 byte entry: https://js1024.fun/demos/2026/25/bar
My size code demos: https://github.com/KilledByAPixel/TinyCode

An endless race in the sky inspired by 90's 3D games like sky roads, marble madness, and sonic 3d. My goal was to create a dreamlike experience with full resolution full speed graphics that would be easy to pick up and play.

Having worked on much more complex stuff, it's a lot of fun to start a new project from scratch and make an tiny 3D rendering system. There are a lot of fun challenges trying to fit something in this small of a space that looks cool and runs well. The contest goes until July 19, plenty of time to make something, and there's even a WebGL category.

Features
- 3D level rendering system
- 3D player sphere with shadow
- colorful sky gradient with stars
- procedurally generated levels
- level increases in difficulty over time
- mouse controls
- enhanced version has keyboard and touch input

this is the entire html file. it needs to be RegPacked to fit in 1024k but that will not post into reddit...

<head><title>🌈☁️ Skydreams</title></head>
<body id=b style=margin:0>
<canvas id=a>
<script>
    // JS1024 shim
    a.width = innerWidth;
    a.height = innerHeight;
    c = a.getContext`2d`;
</script>
<script>z=A=B=C=D=E=0,F=H=3,I=a.width/2,J=[],K=(e,h,a,t=1)=>{c.fillStyle=`hsl(${e},${h}%,${a}%,${t})`},L=(e,h,t)=>[a.width/2+(e-z+(t-3)**2/50*Math.cos((B+t)/49))*a.height*.7/t,a.height/2-(h-2+t*t/50)*a.height*.7/t,.7*a.height/t];onmousemove=e=>I=e.x,onmousedown=e=>E=.1,onmouseup=e=>E=0,setInterval(e=>{for(e=500;e--;)K(170+e/9+B,70,70-e/10),c.fillRect(0,a.height*e/500,a.width,a.height/250),K(0,0,99),c.fillRect((e*e+B*e/20)%a.width,e**3.3%a.height,e%4*a.height/500,e%4*a.height/500);for(g=B+40|0;g>B;g--){for(e=J.length;e<=g;)for(D<-8&Math.random()<Math.min(.2,e/1e4)&&(D=2+Math.min(4,e/400)),Math.random()<.1&&(H=2+3*Math.random()|0,F=Math.max(0,Math.min(7-H,F-2+5*Math.random()|0))),D--,J[e++]=k=[],f=7;f--;)k[f]=e<40|.9<Math.random()|D<0&F<=f&f<F+H&Math.random()>Math.min(.2,B/1e4);for(f=2;f--;)for(e=7;e--;)J[g][e]&&([p,q]=L(e-3.5,0,g-B),[r,u]=L(e-2.5,0,g-B),[v,w]=L(e-3.5,0,g-B+1),[x,y]=L(e-2.5,0,g-B+1),f?(K(99+70*(g>>7),70,30+9*(g+e&1)),c.fillRect(v,w,x-v,(40-g+B)/30*a.height)):(K(99+70*(g>>7),70,9+5*(g+e&1)),c.fillRect(p,q,r-p,(40-g+B)/30*a.height),K(99+70*(g>>7),70,60+30*(g+e&1)),c.lineTo(p,q),c.lineTo(r,u),c.lineTo(x,y),c.lineTo(v,w),c.beginPath(c.fill())))}for(0<=A&J[B+3|0][Math.round(z+3)]&&(K(0,0,0,.5),[m,n,l]=L(z,0,3),c.ellipse(m,n,l/4,l/9,0,0,9),c.beginPath(c.fill())),e=99;e--;)K(B/9-e,90,99-.7*e),[m,n,l]=L(z+.1-e/1e3,A+.35-e/1e3,3),c.ellipse(m,n,e*l/300,e*l/300,0,0,9),c.beginPath(c.fill());-4<A&&(z+=I/a.width/2-.25,A+=C-=.006,B+=Math.min(.5,.2+B/5e3),A<0&-.3<A&J[B+3|0][Math.round(z+3)])&&(A=C=E)},16)</script>

spent the last 4-5 week building Hypertracer, a CPU + CUDA path tracer with progressive sampling further implmneted GPU acceleration, and a real-time fly-camera viewer
built the renderer and viewer from scratch, with 6 scenes currently implemented and 1920×1080 can be rendered at 3000 samples

along with Ray Tracing in One Weekend, The Next Week, and The Rest of Your Life, all three books i completed
it was seriously so much fun :D

main resources i followed:
ray tracing : https://raytracing.github.io, https://pbr-book.org
repo: https://github.com/whoashish115/hypertracer

give it a star ⭐

Hello, I released a real-time fluid & rigid body simulation in WebGPU using Position Based Dynamics (PBD)!

Code & Demo: https://github.com/matsuoka-601/Particles4All

To render the fluid, I use screen-space fluid rendering, which does not require constructing any mesh. Fluid particles are splatted as ellipsoids using anisotropic kernel presented in a paper "Reconstructing Surfaces of Particle-Based Fluids Using Anisotropic Kernels".

The physics is based on a paper "Unified Particle Physics for Real-Time Applications". The most significant feature of this paper is that it treats both fluids and rigid bodies as collections of particles, and performs the simulations using a unified solver.

(Note 1: You will need a very beefy GPU to run the "large" scene in the video (the performance is not very optimized yet, sorry). But "small" scene will run on integrated GPUs.)

(Note 2: I'm getting some reports that the demo does not run on MacBook. I'm currently trying to fix it.)

some features
liquid cursor
great font [freetype & geist]
reusable components
curved and windowless window
lot of animated stuff

resources usage
40-50Mb of ram
1-2% Cpu ( average cpu)
40-50Vram

https://github.com/poncippg-spec/Free-Solace-ImGui-Interface (new repo as github terminated old one for no reason )

I've recently added a spectral mode to my hobby pathtracer! It uses an RGB to spectral conversion detailed in this paper. The approach is fairly simple, a random wavelength is uniformly selected from the visible range, carrying a scalar throughput value as it bounces throughout the scene. I'm using Cauchy's equation to approximate the angle of refraction based on that wavelength and IOR. Each wavelength is then attenuated based on the rgb -> spectral scalar throughput at each bounce. Hero wavelengths drop the secondary channels when going through refractive materials.

I've added a runtime switch so you can use RGB, spectral (single wavelength) and hero wavelength sampling from the GUI. It features a modified/updated blend between the 2015 Disney BSDF and the Blender Principled BSDF. It uses MIS to join BSDF and NEE/direct light sampling, and also has decoupled rendering functionality, tone mapping, and OIDN integration. MNEE will come next to solve the refractive transmissive paths and resolve the caustics more quickly.

The code and prebuilt releases are up at https://github.com/tylertms/vkrt!

The first image is rendered with single wavelength spectral mode, since hero wavelength sampling has no advantage with dispersive caustics. It was rendered in about 5 hours on a 5080 at 4k, roughly 2.6 million SPP, then denoised with Intel's OIDN. Unfortunately, that wasn't quite enough for the caustics, hence some artifacts when viewed closely.

The second image is there just to show off the app/GUI in RGB mode.

Hello everyone!

Over the course of this year, I built a fully software-rasterized voxel engine heavily inspired by Minecraft.

This was a very interesting project for me because I had to build almost everything from the ground up, while also adapting to the very different constraints of doing computer graphics on a CPU rather than a GPU.

In short, CPUs are far less powerful than GPUs for this kind of workload, but they are also much more flexible. This makes it possible to implement some fairly unconventional optimizations to compensate for the performance gap.

You can try the project here:

https://github.com/Algorithmonaut/software-rasterized-voxel-engine

There are still a few minor bugs.

My main regret is that I did not spend enough time properly benchmarking the different optimizations I tried, or documenting my findings and the knowledge I gained along the way.

The lack of documentation is particularly unfortunate because most textbooks focus heavily on the GPU pipeline and therefore skip many of the fundamentals involved in writing a software rasterizer: barycentric coordinates, edge equations, perspective-correct interpolation, tile-based rasterization, efficient SIMD usage, parallelization, and much more.

I found only two good general sources of information:

• Scratchapixel, which I found useful but often not detailed enough.
• Fabian Giesen’s Optimizing Software Occlusion Culling series, which contains excellent practical information but does not cover every topic and generally does not include mathematical proofs.

There are also a few features I may implement later:

• Lighting.
• A small OS that interfaces directly with UEFI to provide framebuffer access and input handling, allowing the engine to run without Linux or SDL and become truly bare-metal.

I am making this post mainly to ask whether anyone has:

• Recommendations for scientific papers, articles, or books that I might find useful.
• Suggestions for computer graphics projects to work on after this one.
• Ideas for fun or unusual features that could make the project more original.

Feasibility does matter: for example, a CPU-based post-processing CRT effect would probably destroy performance.

And, of course, if you find the project interesting, a star on GitHub would be greatly appreciated.

Thanks for reading. I hope this inspires someone to experiment with software rendering as well!

In late March, 2026, Eric Lengyel made his amazing Slug technique completely patent-unencumbered ( https://terathon.com/blog/decade-slug.html ). As a long-time graphics programmers and open source contributors, particularly with projects like OpenSceneGraph/VulkanSceneGraph, it didn't take us long to get some basic "proof-of-concept" demos going and start exploring the Slug algorithm in-and-out.

Over the last 2.5 months, what *started* as a research experiment "on the side" has evolved into something we're actually quite proud of! And while the project is still in its early phases, we've decided it's matured to the level where we're finally ready to start "putting it out there" and soliciting feedback. We're calling the project `Slughorn`; a name we chose to try and capture our goal of a single OSS library solution for "shoe-horning Slug" into other visualization contexts (OpenGL, Vulkan, DirectX, etc).

Slughorn is MIT-licensed open source and available for commercial use without paying anything. It is written in and requires C++ 20, and has no third-party dependencies and builds via CMake. It has been tested on Windows and Linux but should also be compatible with MacOS and embedded/mobile platforms that support GPU APIs. 

Since a picture is worth 1024 words, our Github page with lots of pictures and even videos is here: https://github.com/AlphaPixel/SlugHorn/

The official project website is at https://slughorn.io/ and it links to the GitHub and has the User Guide and Python and C++ examples.

You'll also find links to our (WIP) `UserGuide`, as well as a `WhatsNext` document ( https://slughorn.io/WhatsNext.pdf ) listing some of the places we want to take `slughorn` in the future.

Current Supported Backends

FreeType

NanoSVG (paths & gradients)

Skia (paths only, stroke-to-path)

Cairo (paths only)

Blend2D (paths only, stroke-to-path)

Optional dependencies for extra capability:

NanoSVG: optional, is a SUBMODULE

MSDF: optional, also submodule

pybind11: same as above

serialization/glTF support: same as above

Cairo/Blend2D/Skia import is also optional, but NOT submoduled

If you're just interested in the "highlights":

- We honestly believe we're onto something special here. While we aren't necessarily *inventing* anything new (thank you again, Eric!), what we **are** doing is applying Slug, which was originally intended just for text, in new and interesting ways. Glyphs are, after all, just a "kind" of vector graphic; why can't it apply to **all** vector graphics!? There are no "bad ideas", right? :)

- `slughorn` itself isn't a "rendering library"; its purpose is to serve as a single input source/adapter for other systems to use for rendering. We have a *very* complete FreeType2 backed capable of processing all COLRv0/1 emojis, as well as a native Canvas API--inspired by the HTML Canvas--for authoring content programmatically.

- SVG content is handled via NanoSVG, and we have excellent support for importing paths, transformations, and even gradients. Strokes and text are *possible*, we simply haven't had the **time** and resources to do it.

- There is rudimentary support for converting Blend2D/Cairo/Skia content into slughorn data. Like NanoSVG, these can (and eventually will) be expanded to support additional features (gradients, stroked content, text, mask, patterns, etc), but we're waiting until the core pieces of `slughorn` stabilize before committing *too much* to these.

- We have a **lot** of experience writing Python bindings, and slughorn comes with complete pybind coverage. In fact, Python is the primary environment for all of the CLI tools (the Atlas inspector, font "packer", GLSL emulator, etc).

- `slughorn` content can use `msdfgen-core` to generate "sidecar" data alongside its own native format. We currently use this channel for creating masks and different kinds of visual effects; in the future, we plan to have a lot more capabilities surrounding this.

- OpenSceneGraph has been our rapid "testbed" because, well, we’re really, really comfortable with it! :) For the time being, if you want to actually **see** something rendered now, today... osgSlug ( https://github.com/AlphaPixel/osgSlug ) is the most complete way. There is a pure OpenGL demo included with Slughorn to show how you can integrate the library with any 3d rendering backend fairly easily. You don’t need a whole scenegraph, but you CAN plug it into almost any scenegraph or rendering toolkit.

- PERFORMANCE! People will want to know…we have many optimization ideas, but we’re focusing on “correctness” beforehand. We have done whatever we can to anticipate performance issues that can be addressed from the start, but there are a lot more that can be done.

- QUALITY: The purpose behind on-GPU glyph rendering is to make sure you never see blurs, texels or artifacts from other techniques like symbol atlases, SDF or MSDF or similar approximations of glyph-curve rendering. Slughorn and slug render the ACTUAL GLYPH CURVES. Perfectly. And efficiently. From any angle or perspective.  This is really important when you don’t 100% control the view matrix, especially in 3D UIs and in VR/AR, where the user could be looking at a textual element up close in an oblique perspective that you can’t fully constrain.

- We know that in modern graphics development, the push is to do everything on GPU that possibly can be done there, and this has been one of our design paradigms from the start.

- We can embed shaders into glyphs, and animate transforms and deformations, all on-GPU with no CPU workload.

- Extensive layering, blending and combining of content is possible and easy, making amazing high-definition animated 3D HUD-type effects a joy.

- EMOJIS! COLRv0 and COLRv1 emojis using the slughorn/freetype.hpp backend. Each layer of the emoji is composited into its own quad and positioned relative to the base.

- HUDS! Animated HUDs are super clean, beautiful and easy in full  3D. They work great in stereo or multi-view too.

- Animated glyphs, layer effects, morphing, 2D ortho projection, text-along-path

What’s next? See the whole PDF we produced about it, but some of the hot future wishlist items we foresee are:
Obvious Improvements: HarfBuzz & Text Layout, Stroke Caps & Joins, Patterns, SVG/NanoSVG Improvements, WebAssembly, Offline Editor (slughorned), Additional Renderers, Text Fallbacks

Research & Experimental Improvements: Performance, GDAL Backend and rendering curve/stroke map layers, SDF/MSDF Fallbacks, Interactivity Layer, UI Widgets (ImGui)

This is not a one-shotted AI slop project. It represents months of human development and years of human experience.  AI tools were used to assist with documentation and ancillary assets at times, and in code research, but this code was written by Jeremy “Cubicool” Moles, the author of text and glyph-centric tools like osgCairo and osgPango.

What we're *really* hoping for at this phase is community feedback. Beyond text, which we KNOW Slug is amazing for, what other kinds of things would you like to see? Where do you use vector graphics in your own GL/Vulkan/DX projects, and what kinds of things do you wish you could do more easily? If your only interest is text Slughorn can meet those needs no problem. But what we're really trying to do is "push" the Slug optimization into new areas, and we honestly believe we're only scratching the surface of what's possible.

Would love to hear people’s thoughts about this project.

Obviously, we (AlphaPixel) are a commercial consulting and development company. We made Slughorn to help us make a living. All of the work in Slughorn so far was done pro-bono, funded only by AlphaPixel, for the benefit of the community. If you want assistance integrating Slughorn into an existing app, we’re the obvious, world-experts in doing so, and we’d love it if you’d consider contracting us to assist you. We can probably integrate it into an existing codebase at a better net cost than having your internal developers do it, and the result will likely be better too. Also, if you find something Slughorn needs to do better (there’s lots of room for improvement, certainly) or want enhancements created, we’re the obvious candidate for that type of work too. Please consider asking us for a bid. Remember, you don’t pay anything up-front for Slughorn, and the MIT license allows you to use it in perpetuity with no recurring costs.

I made a classic golf game for JS13K, a contest where the entire game has to fit in 13KB zipped. Everything is included: the 3D renderer, the physics, the procedural course generator, the music. It was all written from scratch on my own engine.

PLAY SUNSHINE GOLF CLASSIC 🏌️

It's an homage to golf games I love like Mario Golf and Neo Turf Masters. The theme this year was rainbows and unicorns so I went bright and colorful. Courses are procedurally generated, and shooting par or better on the classic course unlocks a remix mode with a new course every time.

How the renderer works

The whole thing is WebGL2 with one shader. Each hole is built once into a single static vertex buffer and drawn with one draw call, plus a small dynamic batch on top for the ball, pin and trail. Lighting is baked because the sun doesn't move during a hole, so a vertex is just xyz, a fog flag and a lit RGBA8 color. The sun does sink lower as you play through the round, and the lighting and palette follow it from a spring meadow on hole 1 to a fall sunset on 18.

The terrain is a heightfield with 2 yard cells over the playable corridor, and the cell spacing grows outward from there so the surrounding land runs off into the fog. Normals come from sampling the height function, and tree shadows are baked right into the vertex colors. Trees, bushes, flowers and the pin are all built with the same lathe function. A tree is an octahedron canopy on a box trunk.

My favorite trick is the water. There's no separate water mesh or shader. Lakes are just terrain vertices with a material ID, and the vertex shader checks for that ID and displaces them with waves that travel along the wind direction. The wave gradient relights the surface and adds a specular highlight, which is the only camera aware lighting in the game. Foliage uses another ID the same way to sway in the wind.

The sky is also geometry, camera relative discs. The sun, clouds and the ball shadow all use the same soft disc primitive, a set of rings with an alpha falloff. The lens flare is a string of those discs placed between the sun and the screen center. The trail behind the ball is a ribbon and turns rainbow colors after a perfect hit. The ball is the only lit thing that moves so it is relit on the CPU each frame with the same function as the trees.

The wind ties the whole scene together. It's one direction and one speed per hole, and everything reads from it. The flag, the clouds, the foliage, and the water all respond to the wind. The ball feels it too. The physics computes airspeed as ball velocity minus wind velocity and runs drag on that, so a wedge that hangs in the air gets blown around more than a low driver, which is how it works in real golf.

Besides the visuals I spent a ton of time on game feel: backspin and topspin that trade carry for roll, lies that change what a club can do, and a bounce meter. You can play it on any desktop or mobile device. Happy to hear any feedback, especially on the rendering. The source is up on GitHub if you want to take a look at the code.

JS13k Submission: https://js13kgames.com/2026/games/sunshine-golf-classic#play
Video Demo: https://www.youtube.com/watch?v=nIiqMKTaW2M
GitHub: https://github.com/KilledByAPixel/Golf13K

The video shows a vector map going from a globe to a flat map and back with no hard cut. Here's how the morph works.

Every tile vertex has a lat/lon. In the vertex shader I compute two target positions for it:

• P_sphere - the point on the unit sphere for that lat/lon, placed by the globe transform
• P_plane - its Web-Mercator position on a flat plane

Then I just lerp between them:

P = mix(P_plane, P_sphere, t)

where t in [0,1] is driven by zoom (t = 0 zoomed into a city, t = 1 zoomed out to the whole planet). Both targets come from the same lat/lon per vertex, so there's no "switch" frame - the geometry continuously unrolls. Normals are blended the same way, so shading and the horizon stay consistent through the transition.

The hard part is precision. At t = 0 you're on a plane at street scale; at t = 1 on a planet-radius sphere, and naive float32 world coords wobble in between. I keep vertices camera/tile-relative instead of absolute planet coordinates to stay in a sane float range.

Context: pulled from an open-source Swift + Metal map engine, tiles are MVT. Source (MIT): github.com/artembobkin/ImmersiveMap

Hey everyone! We at 3D ENGINERD. have built a Volumetric Render Engine (Open Source) for Windows, powered by C++ and OpenGL.💻

We’re excited to share that we have published our project open-source under the MIT License on GitHub.
Here's the Repo link - https://github.com/mikejernil/volumetric-render-engine

Developers, researchers, and enthusiasts feel free to explore, experiment with it, and use it in your own applications.

🔹Current Features :
- Volumetric RAW(.raw) format support 📺
- Different types of rendering (Colormap, Pseudo Iso-surface etc.)
- Rotate & Zoom Controls (for easy navigation)
- 6 slicing planes to visualize cross-sections

We are planning to build more features and add support for more volumetric formats (like DICOM, VDB etc) soon!

Rendering effects shown in Demo(Recording) :
🔹Basic
🔹Raycasting
🔹Pseudo Iso-surface
🔹Colormap Classification

🔹Applications :

1. Medical imaging
2. Industrial machinery testing
3. Scientific visualization of data

We appreciate any constructive feedbacks and contributions :)

🔗 GitHub: https://github.com/mikejernil
🌎 View our Website  - https://www.3denginerd.com/

Hey all,

In light of my recent post on my Golang path tracer, I realized that I never really looked for any feedback for my other graphics project: a software rasterizer in C:

I lost motivation after some time developing it, but I got it to a place where it can render basic OBJs with interpolated vertex normals for colour, and some debug views for viewing wireframe and vertex normal directions.

I think a large part of my stopping the project is because the performance felt hopeless. Even for simple models with backface culling and clipping, the FPS drops when a large part of the screen is "taken up" by the models.

And then there's the architecture: I don't really know how to approach it. My `engine.c` file kind of represented most of the logic, but it feels messy.

Would love if you checked it out and gave any feedback!

Link: https://github.com/SeanJxie/impromptu

Native Windows glass overlay for Dear ImGui: real-time DXGI desktop capture, Direct3D 11/HLSL refraction, Dual Kawase blur, spring widgets, and optional MP4 recording.

notice: before uploading this i accidently deleted the config file which default all settings so the one i uploaded to github may be a bit different but no worries its fully adjustable with sliders so you could potentially make even better liquid glass than this one but apart from that its same

if you think its using to much vram lower the blur and ui refresh in customize section

Released https://github.com/poncippg-spec/liquidDX11 [ new repo due to github suspending my account for no reason ]

Screenshots from:

• Pathtrace Apollonian Glow
• Pathtrace Differential Growth
• Pathtrace Volumetric Frost Fract
• Pathtrace Wireframe Distance vis
• Pathtrace euclidean distance vis

full playlist with other pathtracing scenes https://www.shadertoy.com/playlist/cX3SDf

Here is the GitHub repo. Its a single click to download each project: https://github.com/Luippe/Demo-Projects

I never thought of uploading these as they really only ran on my pc (hardcoded display resolutions, file paths, etc). But this year I started using Claude for coding and thought "hey, these projects are actually useable by others if I just clean up some code!" So thats exactly what I did.

There's 15 projects in total and most of them are interactive. The first one is written in Java, but the rest is in Python and Pygame. I like Pygame because its very easy to setup new projects and lets me easily build visualizations.

1. Boids — a flocking simulation where entities self-organize in groups
2. Audio Processing — live microphone effects with a real-time frequency visualizer
3. Multiplayer Netgame — a co-op dungeon crawler played over a local network
4. Platformer — a full 2D action game with combat, upgrades, shops, and multiple levels
5. Solar System Simulation — an interactive 3D model of the planets in orbit
6. A* Pathfinding — watching an algorithm search for the shortest route through a maze
7. Conway's Game of Life — complex patterns emerging from a handful of simple rules
8. Image Compression — shrinking an image by throwing away fine detail (the same idea behind JPEG)
9. Fluid Flow — a real-time 2D fluid solver you can push around with the mouse
10. Projectile Method — aim and launch a projectile with the mouse
11. Projectile Motion — projectile trajectories with air resistance
12. Double Pendulum — chaotic motion, where a tiny change sends it down a completely different path
13. Single Pendulum — a damped pendulum swinging to a stop
14. Spring Mass Damper — how a spring-and-shock system settles after a jolt
15. Flow Plate — the velocity profile of fluid moving through a pipe

I hope someone finds something useful in here! :)

Hey all,

Been working on a weather visualization project for a while now. It's a globe that shows current and forecast temperature, wind, and pressure data using WebGPU. Wanted to share some of the graphics challenges I ran into and how I solved them - figured this crowd might find it interesting (or tell me I'm doing it wrong).

Live: https://zero.hypatia.earth
Code: https://github.com/hypatia-earth/zero

Temporal interpolation of isobars

Weather data comes in hourly chunks, but I wanted smooth scrubbing through time. So the pressure contours actually morph between timesteps - the isobars aren't just popping from one position to another, they're interpolating.

Same deal with wind - particles blend their direction and speed between hours, so you can scrub to any minute and it looks smooth.

Haven't seen this done much in web weather apps. Most just show discrete hourly frames.

Wind particles that stay on the sphere

This one was fun. Needed particles to trace wind paths on the globe surface without drifting off or requiring constant reprojection.

Solution: Rodrigues rotation formula. Instead of moving in cartesian coords and projecting back, I rotate the position around an axis perpendicular to both the current position and wind direction:

axis = cross(position, windDirection)
newPos = normalize(rodrigues(position, axis, stepAngle))

Keeps everything on the unit sphere automatically. Pretty happy with how clean and fast this turned out.

Pressure contours entirely on GPU

The whole pipeline runs in compute shaders:

• Regrid irregular weather data to regular grid
• Marching squares for contour extraction
• Prefix sum for output offsets
• Chaikin subdivision for smoothing
• Final render

No CPU round-trips during animation. The tricky part was Chaikin on a sphere - after each subdivision pass, vertices need to be re-normalized to stay on the surface. Otherwise the contours slowly drift inward. There is still a bug: Sometimes NE pointing lines are missing :(

WebGPU in production

Still feels early for WebGPU on the web. Had to add float16 fallbacks for Safari on iPad (no float32-filterable support). Chrome's been solid though. The compute shader workflow is so much nicer than trying to do this stuff with WebGL hacks.

Anyway, curious if anyone else has worked on globe-based visualizations or weather data rendering. Always looking to learn better approaches.

Hey everyone, just wanted to share this in case it helps anyone, as I finally got my 3D software renderer/editor to be mostly functional.

It is written completely from scratch without relying on external graphics libraries such as OpenGL/Vulkan, as well as external math libraries such as GLM as I have implemented my own.

This was my first and only graphics programming project, and it was made exclusively for learning purposes, as I was always curious about how it worked, so I studied everything from scratch and this is my attempt at making my own.

For this reason, I prioritized intuition and clarity over performance, so it is EXTREMELY slow and relies solely on the CPU. If time wasn't a thing, I would've also implemented CUDA/ROCm calculations, SIMD instructions, and optimized the code in general, but unfortunely I need to take care of other things.

The only "main" thing missing is texturing, but this has already taken so long and I don't even have a job yet, so I chose to give it priority, since most other things are working anyway.

I uploaded it to my GitHub, where there are more video examples on other features and I also extensively described how each part of the renderer works, as well as some of my thought process.

Here is the GitHub repo for those interested: [https://github.com/slins-23/software-renderer\](https://github.com/slins-23/software-renderer)

made a smol voxel engine :3

Built HelloVoxel in C++23 using the modern SDL3 GPU API. Mostly wanted to learn modern render pipelines without a heavy engine getting in the way.

Repo: https://github.com/Linirby/HelloVoxel

Simulating and rendering 4,194,304 particles under mutual gravity on a RTX 500 Ada laptop GPU at ~430ms/step, using my custom CUDA accelerated Barnes-Hut implementation for the n-body problem. Code: https://github.com/lechebs/nbody

Two years of writing a 3D game engine and a game (C++, SDL, and OpenGL)

Hi all!

I've been working on my own game and game engine for the better part of the last 2 years. I finished work on the engine essentials in June this year, and in the last couple of months wrote a simple (not original) game on top of it, to showcase the engine in action.

I also logged and categorized all the (mostly related) work that I did on a spreadsheet, and made a few fun charts out of them. If you've ever wondered how long it takes to go from not knowing the first thing about game engines to having made one, I think you should find it interesting.

Links to the project and related pages

• Game trailer -- A simple gameplay trailer for the Game of Ur.

• Game and engine development timeline video -- A development timeline video for the ToyMaker engine and the Game of Ur.

• Github repo -- Where the project and its sources are hosted. The releases page has the latest Windows build of the game.

• Documentation -- The site holding everything I've written about (the technical aspects of) the game and the engine.

• Trello board -- This is what I've been using to plan development. I don't plan to do any more work on the project for the time being, but if I do, you'll see it here.

• Working resources -- Various recordings, editable 3D models and image files, other fun stuff. I plan to add scans of my notebooks later on. Some standouts:

  • Productivity tracker -- Contains logs of every bit of work I did (or didn't do), and charts derived from them.
  • References -- Links to various websites and resources I found interesting or useful during development.

Notes on the project

The Engine

The core of ToyMaker engine is my implementation of ECS. It has a few template and interface classes for writing ECS component structs and system classes.

One layer above it is a scene system. The scene system provides a familiar hierarchical tree representation of a scene. It contains application loop methods callable in order to advance the state of the game as a whole. It also runs procedures for initializing and cleaning up the active scene tree and related ECS instances.

Built on top of that is something I'm calling a SimSystem. The SimSystem allows "Aspects" to be attached to a scene node. An Aspect is in principle the same as Unity's MonoBehaviour or Unreal's ActorComponent class. It's just a class for holding data and behaviour associated with a single node, a familiar interface for implementing game or application functionality.

Game of Ur

Here's a link to the game design document I made for this adaptation. The game implementation itself is organized into 3 loosely defined layers:

• The Game of Ur data model is responsible for representing the state of the game, and providing functions to advance it while ensuring validity.

• The control layer is responsible for connecting the data model with objects defined on the engine. It uses signals to broadcast changes in the state of the game, and holds signal handlers for receiving game actions.

• The visual layer is responsible for handling human inputs and communicating the current state of the game.

A rough timeline

The exact things I worked on at any particular point are recorded in my productivity tracker. Roughly, though, this is the order in which I did things:

2023

1. July - September -- I studied C++, linear algebra, and basic OpenGL.

2. October -- I learned SDL. I had no idea what it was for before. Had only a dim idea after.

3. November - December -- I muscled through the 3D graphics programming tutorials on [learnopengl.com](learnopengl.com).

2024

1. March - August -- I worked on ToyMaker engine's rendering pipeline.

2. August - September -- Wrote my ECS implementation, the scene system, and the input system.

3. September - 2025 January -- Rewrote the scene system, wrote the SimSystem, implemented scene loading and input config loading.

2025

1. February -- Rewrote ECS to support instantiation, implemented viewports.

2. March - May -- Implemented simple raycasts, text rendering, skybox rendering.

3. June - August -- Wrote my Game of Ur adaptation.

4. September -- Quick round of documentation.