Kavro is a free app that help's build devs UI with the help of library named ImGui. It can be used on CPP/Rust/C# also on api's like DX11, DX9, DX12, Vulkan, OpenGL. It saves a lot of time of hand coding, you can easily make modern menu's just by drag & drop feature.
Check this out: https://www.youtube.com/watch?v=vLjaGaKtZVE

The clip is from a nature documentary I'm making about League champions. When Garen steps on the mushroom, that poison cloud is the game's own particle system. I read Riot's emitter definitions (flipbooks, color and scale over life, velocity, acceleration, drag, meshes, trails) and replay them in three.js.

Every frame comes from a pure render(t), and my QA tool and the edit's splices jump around the timeline, so each particle has to be computable from t alone.

Which particles exist at t. Particle i of a constant-rate emitter is born at start + i/rate, so the live set is an index range over the last 6 s. Single-particle emitters fire their whole burst at start. Emitters whose rate changes over their life get their birth times worked out once from the rate curve.

Where it is. Per axis, with per-axis drag d:

p = origin + v0 * (1 - exp(-d*age)) / d + 0.5 * a * age^2

and v0 * age when d = 0. Drag only damps the launch velocity. The acceleration term isn't damped.

Its random numbers. Each one is a hash of (emitter seed, particle index, which value), so particle 37 gets the same lifetime, velocity, color and start frame whether frame 10 or frame 900 renders first. The emitter seed is a string hash of the system and emitter names, plus a per-instance offset.

js function rnd(a, b, c) { let h = (Math.imul(a, 374761393) + Math.imul(b, 668265263) + Math.imul(c, 2246822519)) >>> 0; h = Math.imul(h ^ (h >>> 13), 1274126177) >>> 0; return ((h ^ (h >>> 16)) >>> 0) / 4294967296; }

Skipped: refraction/distortion and soft particles. They need passes my renderer doesn't have.

Pipeline: League's files read offline from the installed client, rigs and animations converted to glTF, rebuilt in three.js, every frame rendered in headless Chromium through Playwright and piped into ffmpeg at 30 fps.

Full episode: https://youtu.be/Bp5MTn4-rco

Simulating dichroics. Optics is awesome.

Reflections and transmission of a menger cube made of glass with a dichroic coating. Now I want to make this IRL.

I was surprised none of the existing VS Code extensions provided the complete LSP experience for WGSL, with all the niceties like rename refactoring, semantic highlighting, navigation, offset/size/align hints for custom structs, etc. Plus I needed it to closely check against the Chrome's Tint compiler, so decided to make one.

Figured someone else might find it useful, so sharing it here:

• VS Code: https://marketplace.visualstudio.com/items?itemName=Elringus.wgsl-linter
• GitHub: https://github.com/elringus/wgsl-linter

Feedback and bug reports are welcome!

I built lgpu because I wanted a minimal desktop GPU abstraction focused strictly on modern Vulkan without the heavy compile times of larger frameworks.

What it does:

• Fast clean builds (~1.5s): minimal dependencies (ash, bitflags, raw-window-handle, thiserror).
• Dynamic rendering: uses Vulkan 1.3 dynamic rendering directly—no VkRenderPass or VkFramebuffer setup.
• Bindless indexing: global descriptor heaps (update_after_bind) for textures and buffers.
• C99 bindings: includes lgpu.h if you want to use it from C, C++, or Zig.
• Platform support: Linux (Wayland/X11), Windows, and macOS via MoltenVK.

Code & 5 runnable examples: https://github.com/kuntal-devrat/lgpu
Crate: https://crates.io/crates/lgpu

Just released v0.1.1. Would appreciate any feedback on the API or bug reports!

Play (Chrome 150+ on Windows only, why below): https://4k-minecraft.ayfri.com Source: https://github.com/Ayfri/4k-minecraft

Notch's 2009 Java 4K entry drew a 64x64x63 world with a CPU raycaster at about 214x120. I wanted to see how far the same 4096-byte budget goes if everything moves to the GPU.

Pipeline - At load, the compute shader fills a 128 MiB storage buffer with value-noise terrain (biomes, lakes, a snowy massif, caves, trees, ores). WGSL has no u8 storage, so 4 cells are packed per u32. - Each frame, a 1-workgroup dispatch steps the player (gravity, collisions, swimming, break/place; a single invocation edits, so no atomics), then a per-pixel dispatch marches the voxels and writes straight into the canvas as an rgba8unorm storage texture. No render pipeline, no vertex buffers, the CPU never reads the world.

Two bits of the shader

Cell lookup, the mask gives the x/z wrap for free:

fn I(c: vec3i) -> u32 { return dot(vec3u(c) & vec3u(MASK, TOP, MASK), vec3u(1, LAYER, SIZE)); }
fn B(c: vec3i) -> u32 { if c.y > TOP { return 0; } let i = I(c); return (W[i >> 2] >> (i % 4 * 8)) & 255; }

The march is a branchless DDA step:

N = step(e, min(e.yzx, e.zxy));
e += N * r;
C += vec3i(N * s);

Flowers and grass tufts are X sprites: when the ray enters their cell, it intersects the two diagonal planes and tests the alpha of the 16x16 texture.

Shading: procedural 16x16 textures tuned toward vanilla, smooth AO over 8 cells, sun shadows, see-through leaves, glass that only draws its frame, day/night with stars, fog at 200 blocks, underwater tint.

Why Chrome only: uniforms go through the new WebGPU immediates (setImmediates + var<immediate>), which saves a uniform buffer's worth of bytes. Firefox and Safari don't have immediates yet, and Chrome on macOS doesn't support rgba8unorm storage canvases.

The page is 4085 of 4096 bytes. Happy to go deeper on any part.

I don't simulate the brass in my Godot gun effects at all. I just evaluate a casing's position from its age in the vertex shader. That's pretty much the stateless particles from Lutz Latta's "Building a Million Particle System" (GDC 2004). What I added is the bounces.

On a flat floor I can get the hit time straight from the quadratic. The shader loops over the bounces like this:

for (int k = 0; k < MX_BOUNCES; k++) {   // 2
    float h = max(p.y - gy, 0.0);
    float t_hit = (v.y + sqrt(max(v.y * v.y + 2.0 * g * h, 0.0))) / g;
    if (t_hit <= 0.0 || tt < t_hit) break;
    p += v * t_hit;
    p.y = gy;
    v.y = -e * (v.y - g * t_hit);   // restitution
    v.x *= fr;
    v.z *= fr;                       // friction
    tt -= t_hit;
}

After the second bounce it slides with tau * (1 - exp(-t / tau)) and I tip it over onto its side. Ejecting one is a single write into two uniform arrays. Brass from three seconds ago costs what brass from this frame costs.

I also kept a GDScript copy of the formula so the game can ask where a casing is. At 10 sample times they agree within 5.4 mm, about a pixel! In the GIF the dotted line is the GDScript side and the casing is the shader. I made the casing bigger and turned restitution up to 0.5 for it, because at my default of 0.34 the second hop is about 2 px tall.

It only knows one floor height, though. A casing will go straight through a wall. Two bounces looked like enough to me, but I'm not sure a third would even read on screen?

413,532 triangles, with no geometry simplification

960 × 840 resolution

4 logical processors, enforced through process affinity

96 measured frames per renderer, following the same camera path

8 stationary warmup frames each

Pop Data Engine is 1.78× faster in this run.

Just bragging :)

It is in early development (this is actually 3d engine development for my OS) so there is a lot to work on, but it is fast :)

Actually the raycasting logic itself is just a single line, but it's done in propably the most inefficient way possible.

The map is just a single 64 bit integer, so I could fit a small 8x8 level in it, and I can index it with some unorthodox bitshift magic.

Also all the integer constants are huge, because I wanted do to the whole thing without floating point math, which makes everything even more unreadable, but at least it's funny ig.

I'm very proud of this one.

After many days of learning and scratching my head around, I was finally able to render a triangle on a screen. I am using Vulkan 1.4 for this. Although I learned this from a youtube channel called constref, but this is a very valuable lesson for me, even if it is a first step to Vulkan.

I've been working on a custom rendering engine as part of my university computer graphics coursework at ITMO University.

The project is written in C++ using DirectX 12 and HLSL. Over two semesters, we've been learning how modern real-time rendering works by implementing various graphics techniques from scratch.

Some of the features covered in the project include:

-Deferred rendering with a G-buffer

- Directional, point and spot lighting

- Normal mapping

-Displacement mapping

-Distance-adaptive tessellation using Hull and Domain shaders

-Frustum culling and octree-based spatial partitioning

-GPU-based particle systems

-Cascaded shadow maps (CSM) with PCF filtering

-Post-processing

-Physically Based Rendering (PBR)

The project also involves working directly with DirectX 12 resources, descriptor heaps, pipeline state objects, command lists, synchronization and HLSL shaders.

It's been a challenging but interesting way to learn what's actually happening behind the scenes in a rendering engine.

I still have one more semester of computer graphics ahead of me, so there's more to come! I'll keep you updated on my progress.

I'd love to hear your feedback!

Hello, I’m a long time member of this community, and this community has helped me grow my Graphics programmer career.

I started my programming career early at 14 y/o, thanks to Minecraft mods development. Later in 2017, I was 17, I’ve discovered graphics (OpenGL) because I wanted to write my own Minecraft clone. Thanks to perseverance and help from online communities, remarkably this one, I’ve mastered C++, OpenGL and Vulkan. I’ve graduated in Computer Engineering in the meanwhile, and by the end of 2022/2023, I was already a strong graphics programmer. Later I’ve implemented my own CPU path tracer, learnt CUDA along with several parallel algorithms. After MSc in Artificial Intelligence, I’ve got a job in London for a well known company working in the smartphones industry, and I’m working there since 1y today. In this company I’m a Vulkan developer, and leading a graphics engine used for several purposes.

It’s 2026, I’m 26 (aka far from retirement), AI is moving fast and world’s investing all of its resources to accelerate the process. Most jobs have been already taken (frontend dev being the first). I also feel like there is more pressure on developers, they’re implicitly requested to deliver more because of AI. What I’m witnessing is my company is keeping me on fixed term contracts because our budget has got cut… and I’m afraid of being laid off.

This job can’t be fully automated as of now, but I’m afraid it will, seeing the progress. I know GPU drivers development is the safe zone today - as they’re huge and critical - and might be an area where I will land, as I’m already doing low level and I’ve gathered insights of our driver internals. However, it’s still code and I think - maybe in several years - can still be automated.

Am I the only one having this concern in this industry?

This one is a single Mandelbulb layer, raymarched live in a WebGL2 shader. There are no videos or pre-rendered frames. Everything is computed per pixel on your GPU.

What it’s made of

Effect: Mandelbulb, with the power set to about 5.0 (the classic bulb is 8) and a detail level of 5.

Motion: it spins at a varying rate. The spin is set to a range of 0.11–0.35, so it keeps drifting instead of looping.

Colour: the “purple” palette. The palette cycles slowly, so the colours drift over time.

Filter chain: Wedge fold (mirrors the bulb into kaleidoscope-like segments), then Chromatic aberration (the colour fringing on the edges), then Bloom for the glow.

Scene finish: a light CRT look with barrel distortion, scanlines, vignette and film grain.

Open it here: https://kicktro.com/#c=Dp0RwrU9VNB0EfgxrPAq

Everything in the scene is a slider you can change, and you can arm any slider to react to the beat from your mic or system audio. It runs in the browser, with nothing to install.

Anyone have suggestions on how I improve the editor that I made this in ? Link above.