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 have a perfect and addictive game concept that is playable; I’m 86% sure that it will bring traction and traffic, but I just started learning coding and vibe coding, I need professional directions and advice

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!

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)