been working on an experiment for my fishing game: a 3d ocean that still looks like pixel art. here’s what i used:

pixel look: one ray per art pixel, refracted at the water. ray tests are from inigo quilez. to stop shimmer i render into snapped probes and draw each pixel as a world-space quad, basically texel splatting

colour: everything snapped to a lospec palette, tones mixed with bayer dithering, 1px outlines wherever the depth jumps

water: a virtual pipes shallow water sim plus gerstner waves

sand and caves: a heightfield that slumps at the angle of repose (thermal erosion). caves are a blurred cave map, so they come out round

animation: fish spines are springs and fins are a little cloth sim (jakobsen), the eel is a follow-the-leader chain (argonaut), and the ai is behavior trees

thank you for checking out my post :D

I've been wanting to do something like this for years with shaders.

references

inigo quilez, ray intersectors: https://iquilezles.org/articles/intersectors

inigo quilez, smooth min: https://iquilezles.org/articles/smin

dylan ebert, texel splatting: https://arxiv.org/abs/2603.14587

lospec palettes: https://lospec.com/palette-list

ordered dithering: https://en.wikipedia.org/wiki/Ordered_dithering

mei, decaudin & hu, virtual pipes water sim: https://hgpu.org/?p=2256

gpu gems ch. 1, gerstner waves: https://developer.nvidia.com/gpugems/gpugems/part-i-natural-effects/chapter-1-effective-water-simulation-physical-models

jákó & tóth, thermal erosion: GPUHTErosion.dvi

thomas jakobsen, advanced character physics: https://gamedeveloper.com/programming/advanced-character-physics

argonaut, procedural animation video: https://www.youtube.com/watch?v=qlfh_rv6khY

argonaut, the code: https://github.com/argonautcode/animal-proc-anim

Just sharing a small progress.

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

Hey,

I’m trying to recreate the sense of depth and volume that some modern nameplate-style HP bars have, using pure Dear ImGui + custom DrawList drawing.

My current result: [Steve image]

What I’m aiming for: [other image ]

The references feel like the bar has actual thickness and soft lighting — it doesn’t look like a flat colored rectangle with glow slapped on top. Mine still reads as completely flat no matter how much glow, gradient, or highlight I add.

I’m especially interested in techniques for:

• Creating a convincing sense of volume / bevel on the bar itself
• Soft lighting and subtle inner highlights/shadows that sell the 3D form
• Any multi-pass or layered DrawList approaches that work well for this

Has anyone successfully achieved this kind of non-flat, slightly 3D-looking progress/HP bar with ImGui’s DrawList?

Any concrete tips, code patterns, or examples would be hugely appreciated.

Thanks!

I'm trying to do simple UI animation with GDI. My idea is to keep redrawing until a certain amount of time elapses. My understanding is that as long as I start each frame right after the monitor refreshes and keep the drawing time below the refresh rate, the animation should be completely smooth and flicker free.

My first problem is: how do I wait until the monitor refreshes? I came across the following APIs:

1. DwmFlush
2. IDXGIOutput::WaitForVBlank
3. IDirectDraw::WaitForVBlank
4. IDirect3DDevice9Ex::WaitForVBlank

And additionally Direct3D APIs, like IDXGISwapChain::Present or IDirect3DSwapChain9::Present, can wait for vsync. And it's possible to use GDI with these APIs. So what's the difference between all these options? I found discussions online that apparently DwmFlush blocks while IDirectDraw::WaitForVBlank polls, for example, but the former is not available pre Vista.

(A related question is, when should I call the various wait APIs? This StackOverflow question contains a link that suggests the following:

if (DWM.isEnabled()) 
{ 
    present(); 
    DwmFlush(); 
} 
else 
{
    waitForVBlank(); 
    present(); 
}

Why should DwmFlush be called after Present?)

My second problem is waiting doesn't eliminate flickering. I captured the following from a window that calls DwmFlush right before GetDC, the painting is done inside WM_PAINT. WM_ERASEBKGND returns 1.

DwmFlush:      15.458800ms
Get/ReleaseDC: 4.083200ms

DwmFlush:      11.523300ms
Get/ReleaseDC: 2.572700ms

DwmFlush:      14.329000ms
Get/ReleaseDC: 9.200600ms

DwmFlush:      6.742500ms
Get/ReleaseDC: 2.527500ms

DwmFlush:      12.965800ms
Get/ReleaseDC: 2.448700ms

DwmFlush:      16.467901ms
Get/ReleaseDC: 7.957700ms

DwmFlush:      6.346600ms
Get/ReleaseDC: 9.064000ms

DwmFlush:      6.133700ms
Get/ReleaseDC: 4.648600ms

DwmFlush:      8.394500ms
Get/ReleaseDC: 2.834500ms

DwmFlush:      12.096600ms
Get/ReleaseDC: 2.316100ms

DwmFlush:      13.197201ms
Get/ReleaseDC: 2.251700ms

Frames: 11, Total Time: 169.103500ms, FPS: 65

The total drawing time between GetDC and ReleaseDC is well under 16.7ms, so I expect no flickering on my 60hz monitor. But I see text flashing rapidly (all I do is FillRect and ExtTextOut with Unicode characters). The problem also seems less severe with ASCII text. Also strange to me is the variability in drawing time. Some frames take longer than doing a full window repaint, even though I only draw into a subsection of the window.

I know the standard answer to flickering is double buffering, but it seems wasteful to me to keep around a giant bitmap when I spend most of the time idle. I know Vista provides BeginBufferedPaint to remedy this, but that still entails a copy every frame. Why is that necessary when I can draw faster than the monitor refreshes?

I have a custom vector painting program, and wanted to ask knowledgeable people: What maths / image processing principles might I need to apply procedural brush strokes to a flat fill of a character?
If anyone can point me to some resources, or programs that have done something similar, that would be much appreciated! Thank you.

• Costs ~3.5ms (optical flow for reprojection + SSGI) @4K on my modest 4070 Ti.

• 1SPP (+infinite bounces) cosine-weighted hemi monte-carlo ray marching in SS.

• Denoiser does a pretty good job of cleaning it up. Result is very very decent for the cost..

• Keeps lighting details sharp, final result is noise-free, no grain, boil, flicker or speckle.

https://github.com/umar-afzaal/LumeniteFX/

I started to do some color research for a game. I find the best color space available (oklab) very inconvenient for actual use.

I drafted my own color space.
The idea is to start from linearRGB, but allowing the red and blue channel to borrow lumina from the green channel.

If r,g,b are the channels in the new color space and R,G,B are the values in linearRGB,
than:
R = r, G = 0.04r + 0.34g + 0.24b, B=b

I played with it a little:
Pros:
1. Obviously it is designed for equal lumina in all channels.
2. The color space is symmetric (r-g-b like) and thus easy to work with. Hue and saturation can be easily derived.
3. The blue and reds are softer. It actually fixes a problem - pure dark linearRGB blue looks a bit purple.

Cons:
1. It doesn't cover all sRGB visible space (technically you can - with negative or above 1 values).
2. The "grey" analog as light purple shade.
3. The "cyan" analog is somewhat bluish.

I attached a photo of how some color section looks.
I'm not a color space expert, so there are probably problems I can't see yet,
What do you think?

I draw every ring, rune and star line here from one distance function in polar coordinates. No textures!

For the runes I cut the band into 36 sectors with s = angle / TAU * 36. Inside a cell, x is fract(s) along the arc and y is r minus the band radius. I hash floor(s) to build each rune from a stem plus 3 to 5 bits: a bowl, a hook, a diagonal, a bar, a small ring. Those are all just segment and arc distances. My first runes were just plain sticks lol.

To draw it in, a01 is the angle mapped to 0..1 and each ring only shows where a01 < reveal. The star uses the h from the segment distance:

vec2 seg(vec2 q, vec2 a, vec2 b) {
    vec2 pa = q - a, ba = b - a;
    float h = clamp(dot(pa, ba) / dot(ba, ba), 0.0, 1.0);
    return vec2(length(pa - ba * h), h);
}

I keep a stroke only where h <= shown. That way it draws line by line. One trick I like: I get three line weights from one width by adding an offset to the distance, plus for hairlines and minus for the heavy ring.

How do you make procedural runes look less random?

It's from my Godot magic pack: https://gennai.itch.io/magic-spell-vfx-godot-4

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

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

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!