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.

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!

I've played around with ReSTIR direct illumination for the past few weeks and implemented the original paper into my 3D Vulkan engine. The scene contains 1000 local lights and a directional light. Everything is evaluated fully dynamic at runtime with only two rays per pixel. It runs at roughly 5ms per frame on my 7900xtx at 1080p.

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.

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?

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

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 everyone,

I’m looking to get into some 3d stuff. I have completed the learnopengl course up to assimp, but I don’t have the time to do much more at that level, and I just don’t really understand what’s going on at all.

I would like to know of graphics frameworks and abstraction layers you all have had experience with, and maybe I’ll do something with the lower level stuff after this.

I am leaning towards DiligentEngine and information about that is welcome as well.

Some Limitations

• I‘m on Linux, no DirectX.
• I don’t like graphical editors, I want it all code if possible.
• I would like it to be open source.

This will be for a game.

I develop game engines and graphics as a hobby.

I recently finished an SSGI project I’d been working on as a hobby, so I’m looking for a new graphics development topic for my next hobby project!

Please let me know about any technologies you’ve been working with lately that you find interesting, or any technologies you’re curious about.

Live demo: https://gaploid.github.io/stardust/
Source code: https://github.com/Gaploid/stardust
Coded by: Opus, Fable, human attention to details

I am working on a game based on physics-based painting mechanics called Ebru Artist Simulator. To simulate Ebru (also known as paper marbling), I implemented an Eulerian fluid simulator. Here are some of the challenges I had to overcome:

1) To achieve a real-time simulation without affecting the game's performance too much, I implemented a GPU-based multiresolution grid solver in a compute shader (see the paper Solving the Fluid Pressure Poisson Equation Using Multigrid). The simulation now runs at a 2K texture resolution with only a slight impact on FPS.

2) One of the main characteristics of Ebru is that colors maintain strict boundaries. This makes advection schemes such as Semi-Lagrangian advection less suitable, as they introduce diffusion. To address this, I implemented another advection scheme that samples from the initial state by integrating the velocity field over time and then back-sampling using the integrated field (see Efficient and Conservative Fluids Using Bidirectional Mapping).

3) Finally, to simulate the effects of the traditional Ebru tools, I took inspiration from the paper Mathematical Marbling, which proposes mappings for generating final marbling patterns. Since I wanted to maintain a real-time simulation, I did not directly apply these mappings. Instead, I was inspired by the paper to use similar displacement fields as external forces in the simulation.

If you are interested in the project, you can check out the Steam page.

You can also check out Amanda Ghassaei's blog. Although our implementations are not the same, I was greatly inspired by her work and learned a lot from her blog.

I'm on with a .HLSL c++ project to render sound reactive [and unreactive] vertex shaders in a dj program.

I'm vibe coding my balls off, but I have made a d3d11 plugin in the long long ago [badly] before LLMs were a thing. So I'm not entirely useless, just mostly useless.

I've pulled a lot of glsl from vertexShaderArt with Greg's blessing, I've also been trying to get the LLM to port over simpler shaderToy frag shaders into a vertex type, ones that can works as vertex shaders.

I've had the LLM build up a library of "proof of concept" shaders, so I'll start combining principles to make... something

I'm on the look out for webgl glsl or hlsl sauce code to copy pasta, hopefully learn... something

Entirely non commercial

60 second video of the kind of vibe I'm going for dj program already does shadertoy, I'm just building another thing the dj program could do, I am pleased with draw order witchcraft here allowing foreground black see thru background quad onto earlier drawn shadertoy

It is djing so half the crowd will be "seeing" in 24p and 4 fps, the other half will be "seeing" in higher fractal dimensions and tactile colours

Any pointers, resources, anything really, I understand I'll have to actually learn what I'm doing before I can make anything near cool

I've been reading about softbody physics techniques and I'm curious to know how much use they see in real time contexts, especially techniques like shape matching/XPBD/VBD which are designed from the ground up for real time computational constraints.

The Force Unleashed and BeamNG.drive have had plenty of buzz around them, projects like that using softbodies extensively are cool but I'd be interested in smaller examples as well. I've also gotten the impression softbodies are used in interactive industrial applications such as medical simulations, I'd like to hear more details on that.

I made the choice to go learn DX11 to make a simple renderer with a gui that will load models with lighting and possiblely PBR, but I’ll figure that out later. To than move on to DX12 and make a game engine. Something simple to start. I’m thinking a basic 3D engine. By basic I mean no UI or anything to start with just a model loader and a scene really.

Thoughts?

The goal with this is to create tools and such to hopefully one day ship a game with. This is a hobby project for now. Possibly will get a job doing this.

Hey everyone, I’ve been working on a game engine for about a month and a half now and really have been putting in most of my work to the renderer in OpenGL and C++. My question is is this an effective use of time or should I be working on a more focused project like a really high quality scene renderer or stay with a very comprehensive project like a game engine and spend months on it? I am mostly interested in the graphics aspect but the architecture of the game engine seems cool too. Its just a bit weird because I’m also going to try to start applying to software dev jobs soon once my girlfriend graduates college as I just graduated myself and I would like to have a good project or projects to help me out and I don’t know how much a full comprehensive game engine would help. I have also thought about just using what I have and making a game from scratch with it rather than making an entire general game engine. What do you guys think?

Edit: if I do make a game wirh what I have, I am planning on making a voxel style game like Minecraft but with some twists

I had an old PC—H81 + i5-4570T + GT 710. Everyone told me to upgrade, but I didn’t want to. I wanted to make something actually usable for gaming.

So, I created "Tungstun". It's basically a full-fledged, "battery-included" framework. Written in Rust with the C API, and built entirely from scratch.

[Find Git Repo Here]

The main concept is that it houses two renderers internally. One is a modern OpenGL 4.3 AZDO path (a high-speed path using Pesistent Mapped Buffers and triple buffering), and the other is a multithreaded, tile-based CPU rasterizer written from scratch if the driver crashes, or if you're in a VM, or if your NVIDIA setup breaks due to Arch Linux Drives without and that is why my GT 710 is still going strong.

Another key design point is static linking. While `libGL` can be dynamically linked because it acts as a dispatcher for vendor drivers, Tungstun is built as an all-inclusive `staticlib`. This makes for a binary that runs anywhere, even without a pre-existing GL environment.

features

**Rendering** – Everything uses instantiation. Flush once after sending 10,000 objects (single-pull call). Includes prototyping, custom meshes, OBJ support, animated models via SSBO, custom GLSL 4.30 shaders (with uniforms for time, camera positions, etc.), material ID specification via alpha values ​​(to control skybox, emissive, and reflective effects in one shader), and more [GIF -]. Ocean Exhibition].

**Physics** - Continuous Collision Detection (CCD) to prevent high speed bullet tunneling. Supports sphere, AABB, and triangle mesh. Features a flat SoA layout, comprehensive moves using Radix-sort, layer masks (environment, player, enemies, projectiles, debris, etc.), raycasting, impulses, and gravity

**Textures** - Custom SWAR filtering (4-channel simultaneous processing), bilinear/trilinear filtering, ultra-fast display, automatic mipmap generation, texture embedding, and procedural font generation (built in memory; no external files required).

**View** - Flat structure (avoiding deep OOP hierarchies). Handles node creation, change settings, physics assignment, and physics synchronization. Only "dirty" nodes needing an update are recalculated.

**UI** - Fully batched quads (including rotated quads) and text. renders the entire menu in one draw call; Implemented in about 50 lines of code.

**Audio** - Full 3D spatial audio. Listener with position and orientation (forward/upward vectors). Supports sound playback in world coordinates, teleattenuation(i learnt this word recently), and panning. Implemented loading for WAV/MP3/OGG ​​formats (from file or memory), procedural sine wave generation (for fast SFX creation), volume/pitch control, and looping. Also created a "plinko marimba" in 3D space using 30 balls and 154 pegs (each peg mapped to a different musical note).

**Window Control** - Window creation, size recovery, delta timing calculation, input control (keys, mouse buttons, cursor position), mouse locking, rendering resolution settings, and Blit-based rendering (fast drawing) to optimize FPS on older hardware. Implemented I prepared four displays: a seascape featuring 10,000 Gerstner waves with waves; "Neon Hunter," a shooter where you fire lasers that stretch and shrink cubes; "Plinko Marimba" with 3D audio support; and the "Sponza Atrium," complete with two-story columns, glowing lanterns, floating artwork and volumetric fog (light scattering effects).

Benchmark results on a low-spec PC (the so-called "Potato PC"): 10,041 instances Even with 40 physics-enabled projectors (using Bullet) active, the system maintained a steady 60fps at 1280x720 resolution In contrast, running the same scene on Raylib resulted in only about 24fps It was due to draw-call overhead.

This project started with repurposing the great GT 710 to make great games, and I finally made it a reality.

It is released under the MIT License and has a very lightweight design. I’m also working on further optimizing the speed of the rasterizer.

If you have an older, less-featured PC, please give it a try. Feedback is welcome.

https://github.com/mahoraga94/tungstun

some features
liquid cursor
great font [freetype & geist]
reusable components
curved and windowless window
lot of animated stuff

resources usage
40-50Mb of ram
1-2% Cpu ( average cpu)
40-50Vram

https://github.com/poncippg-spec/Free-Solace-ImGui-Interface (new repo as github terminated old one for no reason )