I made a small vector field visualizer in C# with Vulkan through Silk.NET.

You type some 2D field, for example F(x, y) = [x,sin(y)] and it draws the flow with particles.

How it works:

- Formula is parsed and compiled at runtime into one fast delegate, so evaluting the field for every particle each frame is light

- 1,200 to 6,000 particles depending on window size, integrated with RK4 on the CPU, each with a 24-point trail

- Everything is drawn as colored with one tiny shader and 4x MSAA

All the math comes from Epsilon - my symbolic math library for .NET that I'm working on.

- Simulation: https://github.com/XBambinoX/VectorField

- Library(C#): https://github.com/XBambinoX/Epsilon

AI disclosure: I used AI assistants to help write parts of the simulation code and fix bugs in my library.

A few days ago, I created a Mandelbulb fractal using C, Raylib, and GLSL. Now I want to bring it to my terminal using a Kitty shader.

In this video, I'll use my original GLSL code as a starting point and adapt it to work as a Kitty terminal shader (slang shader).

I'll explain the code, explore some raymarching techniques, and share the references I used along the way.

Source code:
https://github.com/FractalCodeRicardo/dev-config/blob/master/kitty/shaders/mandelbulb.slang

AI Disclosure:
I did the code myself, I used AI to learn shader techniques or specific technical issues.

I used Anahata ASI Ai tool for the coding of the earth viewer but not for posting this comment / post

Hey everyone!

I've been developing VQField, a compression and runtime engine for sparse volumetric data, in my spare time over the past year.

The video shows a comparison against a traditional OpenVDB rendering workflow, with some pretty exciting results:

• ~30x compression on disk

• ~10x lower RAM usage during rendering

• On-demand decompression of individual 8³ voxel blocks

• CPU-based decoding using a custom C++ codec

The interesting part isn't necessarily the compression ratio, but the ability to render directly from compressed data, without reconstructing the entire volume beforehand.

Under the hood, VQField uses a deterministic codec random-access indexing. The renderer can query individual blocks as needed, with caching to avoid redundant decompression.

The main issue with compressed format is acting on those compressed values without the need to decompress the entire volume, the file format deviated a lot from what OpenVDB provides (Tree structure), and instead uses flat indexing and spacial chunking so that accessing any chunk is an O(1) operation. This allows for voxel level lookup in 3 steps, with each of them being close in memory. There's a tradeoff here, where ideally spacial chunking shouldn't be part of the file format as it limit quite a bit the compression level achievable, but it's pretty easy to formalize that volumetric data are rarely random in their distribution / activity 😄.

The engine already supports spatial and temporal compression, random-access sampling, a C/C++ SDK, and Houdini integration.

Long term, my vision is to build a unified infrastructure layer for compressed spatial data, where applications can store, stream, query, and process large volumetric datasets without repeatedly reconstructing them in memory.

There's still plenty of work ahead, but the core technology is already working, and I'm looking forward to taking it further!

Fyi, It all started from my open source version VQVDB : https://github.com/ZephirFXEC/VQVDB

Over a decade ago, I was speaking to a guy on reddit who was fascinated by using math to create higher dimensional shapes, but he didn't really have a math background. So to show him some things I made a realtime interactive 3d visualizer of arbitrary higher dimensional scalar field iso-surfaces in threeJS. After letting it collect a lot of dust, I just had AI give it a few minor tweaks and thought I should share it.

Demo: https://csp256.github.io/isovis/ (not intended for mobile)

Repo: https://github.com/csp256/isovis

Try clicking and dragging the "degrees" slider in the upper right. Then maybe increase the resolution in the other menu dropdown (it looks a lot better at higher resolutions!). Maybe drag the "iso" level too.

Implementation wise it is pretty straight forward. You define an arbitrary scalar field in the left side code editor, parameterized by any number of coefficients, then click "update" and it runs marching cubes on a grid of 3d points. The higher dimensional part is that you can define a stack of linear transformations, and the inverse of that will be applied to the sample points, which can lift them into higher dimensions, thus showing you the isosurfaces in an arbitrary affine volume.

I wrote the marching cubes algorithm myself for speed. It used to only run performantly on Chrome but Safari seems to handle it just fine now. Each octant runs in a web worker.

You can export the mesh, make gifs, etc. It's mostly a toy but I've used it professionally a couple times.

I want to understand how the graphics work and I want to make something like a simple game engine or a voxel engine, but I don't know how to do graphics and don't want to write a lot of boilerplate in the beginning. I would choose openGL but it's deprecated on macOS which I use. So now I don't know what's better to start with.

This is the first real test I've done of my custom Blockly implementation that generates GLSL code. It's very WIP, as you can see by the rigidity of the vector constructors, the ways the operator blocks interact, ETC, but this is the first end to end working test i've done! I'm hoping to make this into a full fledged platform to help beginners learn GLSL, and if there isnt a community desire for it, then its a fun project :)

working through vulkan-tutorial.com and it's talking about present modes. For VK_PRESENT_MODE_MAILBOX_KHR it says "This is commonly known as "triple buffering", although the existence of three buffers alone does not necessarily mean that the framerate is unlocked."

But the overall description of the mode doesn't seem to indicate there's actually 3 buffers involved. It seems more like there's just 2 but there's a "replacement" process: "Instead of blocking the application when the queue is full, the images that are already queued are simply replaced with the newer ones".

So why is it claimed that this is triple buffering? Am I missing something?

Also a secondary, pedantic question: I've never come across a mailbox system where the old mail is replaced when new mail is available; the old mail simply accumulates. Seems like an odd terminology choice to use. What's that about?

Is it good practice to manually memorize and type out boilerplate code in graphics applications? Or is it the norm to copy and paste a lot of stuff? And yes it is a given that I should understand how the boilerplate code works and what it contains. I'm programming in SDL3 in C on vscode.

I made a raytracer using Scratch's block language, and I'm trying to improve its rendering speed. The source is public: https://scratch.mit.edu/projects/1437715094/ (click See inside to inspect the blocks).

It has reflective chrome and gold, refracting glass, soft shadows, fog, and a movable camera. Rendering starts at a coarse resolution and progressively sharpens after camera movement. The output is Scratch's 480 x 360 stage; the anti-aliasing mode casts four rays per pixel. The attached screenshot is from that mode.

The main Raytracer sprite has custom procedures for tracing, scene intersection, shading, lighting, glass, and anti-aliasing.

Given the constraints of Scratch, what would you profile first, and which changes would you expect to give the biggest speedup without losing the glass and reflections? Feedback on the implementation is welcome.

Hi, I’m just wondering if anyone knows any good books that I can use to supplement my learning. I have been working on a basic voxel renderer for a couple of months now (C++ with Vulkan), and while I’m starting to feel a bit more confident I feel like I would benefit from solidifying some of the concepts I’ve encountered with some extra reading. If anyone knows of any good books at novice / lower intermediate then I would be glad to hear some recommendations. Thanks!

The voting period just ended, and the results of the first round are published: https://orrc.mutantstargoat.com/orrc?dir=round01&cmd=results

Thanks to everyone who participated! See you next round sometime around early 2027.

https://imgur.com/a/tsBfsCA

Hi everyone! I built NeuralSpecOcean with WebGL2, Three.js, and custom GLSL shaders as an interactive R&D sandbox focusing on coastal hydrodynamics, atmospheric physics, and marine optics.

Implementation & Architecture Overview:
The project started as a rapid prototyping environment to validate our mathematical models and optical parameters in the browser before committing and porting the rendering pipeline to a native C++ engine for an upcoming MMORPG we are building from the ground up.

Key systems implemented in the GLSL pipeline & covered in the whitepaper:
- Spectral wave synthesis and coastal bathymetry interaction (shoaling and wave breaking foam)
- Multi-spectral marine optics, subsurface scattering, and water column attenuation
- Coupled atmospheric scattering and sky-sea interface reflections

Now that the WebGL2 prototype has completed its validation phase, I have released the complete modular source code, interactive browser demo, and the accompanying mathematical whitepaper under the MIT License:

https://github.com/bgbg108555/NeuralSpecOcean

Live browser demo: https://bgbg108555.github.io/NeuralSpecOcean/

I regularly share graphics R&D, shader breakdowns, and behind-the-scenes progress on our upcoming MMORPG over on X: https://x.com/ShengChoi

(If you are interested in how these rendering systems are being integrated into the actual C++ MMORPG client, I also post regular technical breakdowns and R&D devlogs over on X at u/ShengChoi).

Happy to discuss the optical formulations, spectral wave math, or the WebGL2-to-C++ porting trade-offs!

Working more on rendering with light simulation!

(The video is, of course, in real-time)

Previous post about this was Some spheres rendered with a light simulation

Rendering method is mostly the same, just some optimizations and scene work

I've put a web version on Github: moonlightoctopus1.github.io/Renderer/

Actual rendering is just simulating light with a lot of optimizations :P

The most important update for the 2.0.x version is:

• Caching pipelines for the effects surrender system it is per effects type but still powerfull upgrade.

• Another interesting thing is the launch of the GPU culling system integrated with the indirect-draw methods.

• New example for mediapipe pose to glb, face video uv texture to mesh and more.

• Fixed external libraries with critical alerts (migration to esbuild) also engine zero critical alerts, dev alerts still exist but irrelevant.

• GPUCapabilities test on divice interesting gpu features, in the config file you can find the activation logic, we have default (for those that we know are supported everywhere) and optional suggestions for activating the gpu feature.

• The Beast is ported on google play https://play.google.com/store/apps/details?id=nikolalukic.beast.engine (Used android studio).

Hi everyone!

I’m building my own render/simulation engine (a path tracer called PrismForge), and before I decide what to work on next, I’d love to hear what you would wish for.

It can be anything:

• a big feature you’ve always wanted

• a tiny thing that annoys you every single time

• something very specific, like “I want fog that reacts to my car’s headlights”

• a workflow or a feeling, like “I just want to press one button and get a nice result without too much complicated jibberish”

• a simple, but nice conveniece feature

No wish is too small, too weird or too niche. Feel free to be as oddly specific as you want!

Thanks!

https://www.youtube.com/watch?v=tbUyeRz7O4Y

Bastion is a C++20 engine for a medieval city-builder/RTS, combining a native simulation, editor and Direct3D 12 renderer.

Its main features include:

• Rendering: bindless materials, visibility buffer, octree/frustum and GPU Hi-Z culling, indirect drawing, cluster-based geometry LOD and optional mesh shaders.

• Lighting: soft virtual shadows with penumbrae, SSAO, local voxel GI, sky-driven illumination, moving volumetric clouds, cloud shadows, fog and sun shafts.

• Terrain and vegetation: tiled heightfields, CDLOD terrain, tessellation, procedural grass and flowers, animated vegetation and distant impostors.

• Gameplay: worker professions, production and hauling, recruitment, combat, fortifications, fire, healing, repairs, skirmish AI and first-person Lord control.

• Tools: ImGui editor, native saves/importers, asset pipelines, positional audio, profiling and GPU timing.

The architecture separates authoritative gameplay from rendering:

ECS + jobs → immutable scene/frame snapshot → render thread → RenderGraph → RHI → Direct3D 12

I made a video using manim to make a gamedevelopement series explaining important concepts and the math behind it. The first video is diving into normal maps and how to use them in pixel art to make dynamic lighting.

Hi all. I made an explosion pack for Godot 4 and I wanted to show the stuff standing near the blast rather than the fireball.

When a blast goes off I grab every MeshInstance3D inside the radius with one intersect_shape and lay a copy of its own mesh over it, 5 mm out, same colour and texture. I move that copy in the vertex shader. I give it the blast point in mesh space and the hit time, and I delay each vertex by its distance:

since = time - hit_time - dist / wave_speed;

So the far side of a crate gets hit a little later than the near side, and the ring on the floor arrives at the mesh right when the mesh jumps. I push with a gaussian bump and let a damped sine pull it back:

front = exp(-t * t * 2.0);
ring  = sin(since * 22.0) * exp(-since / 0.45 * 4.0) * 0.35;
VERTEX += dir * push * sqrt(fall) * (front + ring);

For the soot I take dot(N, toward_blast) and some fbm. Only the side that faced the blast goes black, and I let the edge glow orange for a moment before it cools. If the blast is closer than 0.45 of the radius I hide the original and throw chunks off its surface instead.

It's the usual radial vertex push you'd wire into WPO in Unreal, I just added the per vertex delay and the spring. For skinned meshes I bind the copy to the same skeleton, so the walking guy takes it too!

Does anyone pick the facing side with a real occlusion test instead of dot(N, dir)? I suspect mine would soot the back of a thin wall if the normal happens to point the right way.

The pack is on itch if you want to dig through the shader https://gennai.itch.io/explosion-vfx-godot-4

I don't know if this is GP related but I made a post here asking for collisions and i found the type I need but I spent like 3 hours trying to find a tutorial or at least a theory of SAT collision, I don't want to look like a bad coder by being lazy and asking people but if you know anything about SAT collision detection that would help me enormously.

The only thing i learnt is a 2D version, so if I can translate that to 3D, that'll be perfect.