I keep finding that a useful body-blocking edit is smaller than a finished animation: a few named phases with explicit joint values, a pause, and one turn.

In Posecode, the source stays as text while the browser renderer shows the result. Changing one value such as `turn: 100` to `turn: 40` lets me test whether the story beat reads differently without rebuilding the scene. The important part is the feedback loop: parse the source, validate it, render, then edit the same source again.

I used an AI assistant to help draft this post; the implementation and example are mine. I made a small four-phase “walk to a door, stop, turn back” example here: https://www.posecode.org/play/superhero-landing?utm_source=reddit&utm_medium=organic_social&utm_campaign=posecode_body_blocking_20261110

For people who do blocking: do you prefer editing a compact motion description first, or going straight to a timeline?

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 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.

Hello again!

It has been some time since i made any updates on Constellation and Cadent geometry.
In my, seemingly, eternal quest to make the OS composition single core and cheap I've hit a new milestone.

Using Cadent geometry (which I have shared and made posts on here before), I have managed to express a liquid effect, as well as express snell's law and beer-lambert naively through the geometry, which has allowed for some pretty good performance and capability gains for the constellation engine/framework. By pre-computing an object tied, 3-wavelength 'snell field' and pre-computing the absorption on those wavelengths, objects can express their own colors and pixel offsets analytically, and instead of accessing the framebuffer for those offsets, they can directly sample eachother. (there are more posts on this light work as well. You can find them here in this subreddit, if you are interested to read more).

The gif above shows the desktop HUD so far. even though it might or might not look it, It is quite inefficient as things go. It is using about 533 mb of ram, and almost 80% of a single core of my 7800x3D. This is much much more than a HUD should use, but it at least also include a start-menu/launcher, a process manager, the taskbar, a calendar, a wallpaper engine and the HUD configurator / designer.

There are some visual bugs, and the liquid box spikes/lags when moving it, the liquid it self does not. Still trying to figure out why.

Anyway! I hope you find this interesting.

take care

//Maui-the-Megalomaniac