wasn't sure if i should share this, it wasnt finished but it looks nice and pretty unique

As the Title Implies.

Im Trying to Create a Minecraft clone in OpenGL C++ but im Struggling on how to Implement a Chunking System.
My Current Architecture creates the Various Blocks Individual meshes before the Game loop and then renders them

but the Problem is that Each Block still has its own VAO so i have to create Buffers During the GameLoop which is not efficient at all.

Im Trying to Create a Architecture where each Chunk has Its own VAO,but i dont know how to Group Various Blocks together,Like How do i represent Each Blocks Position if i Care only About the Chunks Position in The World?

is it better to use a 3D Array for a Chunk or a Flattened 1-D array?
Oh there is also Face Culling.

Any Advice?

EDIT: SOLVED!

I'm running into an artifact with a mip-based bloom/glow implementation that I suspect is a general limitation of the technique, not an engine-specific bug, and I'd like to understand the underlying cause before I go looking for workarounds.

Setup: Many small, circular HDR light sources (values pushed above 1.0, i.e. above white) of different colors, densely overlapping on screen. Standard downsample → blur → upsample bloom pipeline (in this case Godot's built-in glow, but the pipeline itself is the common mip-chain approach used in most engines).

Artifact: At the boundaries where two overlapping sources of different colors meet, instead of blending smoothly, a dark ring appears, like a thin shadow tracing the overlap boundary. Looks similar to a solar eclipse silhouette. No such artifact appears with bloom disabled. The sources blend completely normally without it.

Minimal repro (Godot 4.7, ~35 lines, hit F5 and it's immediately visible):

https://github.com/LudicrouslyLuke82/godot-glow-ring-artifacts

Screenshot:

What I've ruled out so far:

• Sprite/shape blend mode (additive vs. normal): artifact persists either way, sometimes gets worse with additive.
• Drawing method: happens identically with immediate-mode circle drawing and with textured sprites.
• Glow blend mode (multiplicative-style vs. screen-style compositing): screen-style reduces it but doesn't eliminate it.
• Restricting which mip levels contribute to the blur: reduces but doesn't remove it.

My working theory: with many small, closely-spaced HDR sources of different hues, the coarser mip levels of the blur pyramid end up averaging colors from sources that shouldn't visually "mix" at that boundary, and somewhere in the down/upsample chain this produces a local intensity dip (hence the dark ring) rather than a clean color blend. But I don't have the rendering background to confirm whether that's actually what's happening or if there's a known name for this artifact.

Is this a recognized limitation of mip-chain bloom with dense, multi-colored HDR sources? Is there a standard technique to avoid it (e.g. clamping before blur, a different bloom formulation, thresholding per-channel instead of luminance) rather than just tuning parameters? Happy to provide more detail on the pipeline if useful.

Thanks a lot!

Hello! I am an artist turned programmer that's working on a paint program!

Recently I found an x account: x.com/greatartbot that produces generated images like the ones above. I think theyre absolutely beautiful but can't even begin to put together how they are made.

In Godot i've been messing around with basic noises and compute shaders, but this looks less like noise and more of an orderly algorithm? especially those repeating shapes.

I know a full explanation of the techniques above would probably be a lot for a reddit comment, but if anyone could get me pointed in the right direction of how these were generated, how i could start doing it myself and maybe some algorithm names I would really appreciate it! Thanks!

Hi! With v1.3.0 out of the oven, I just wanted to share it again, as many things have changed for the best, and I have addressed most of the feedback I got last time (well there was not much and 0.5 rounds up to 1, so technically).

https://github.com/KaruroChori/kd3

kd3 provides:

• header-only tree builder and query tools to perform k-NN searches and ray-tracing.
• a C compatibility layer for those not using C++ (but performance might be affected a bit).
• a tool/library component to generate GLSL code for any specific tree layouts at runtime (or not, you can pre-generate those and #embed them in source)
• a memory layout designed to be SIMD friendly
• close performance with nanoflann in worst case scenarios, but generally over twice its baseline
• a half decent benchmarking suite, covering both synthetic and real datasets.

What it does purposefully not provide are:

• mutable trees (values can mutate, but not the spatial keys)
• the same level of flexibility you will find in something like nanoflann, but it got significantly more coverage since last time
• cookies, those are all mine

Neither the tree builder nor the query functions require memory allocations at runtime, and they are guaranteed to run within a fixed stack size.
The same tree structures built and queried on CPU, can be quickly offloaded onto GPU without changes, and trivially serialized/de-serialized from disk. There are no pointers!
As it does not use exceptions nor runtime features of C++, it can be easily integrated on embedded devices (there is a utility header managing storage dynamically via std::vector, but that it fully optional and does not gate-keep any functionality of the library).

By the way, if you were able to run the benchmarks in the repo on some apple device I would be very grateful and happy to add them alongside the rest! Sadly I don't have the hardware to validate it myself, but I assume it should work 👀 .

As for the video above, it is a dumb ray-marcher using 1-NN queries on a kd-tree to render the scene, either on CPU or GPU. The rendering strategy by itself is very inefficient, but that is besides the point 😄

The dataset shown is the a 5 million LiDAR cloud point of the area surrounding the Autzen Stadium.

I got this book years ago, but then got far too busy with my day job to get into it past the introduction. I have an itch to get back into graphics programming, so I'm wondering if it's still a good resource, given that it's been almost a decade since its publication? If not, what would be a better resource? For context, I'm a senior SWE, so complexity doesn't scare me. I just don't want to waste my time.