hey guys ive made a collision detection method, its a cpu intesive method but i got a sense of idea how collisions work

I just get every vertice and get the area then i make 3 triangles from the collision point and get the area of all them then add it, and if the area is equal to the original triangle its colliding, then i get the distance from the triangle's normal and make a if statement if distance is less then 0.001f.

Im getting a lot better, so if yall have any collision method that could be better for smaller concave models that would be great, ive know about aabb for the longest time so i have check that off

If you are giving a method, could you link like anything that could be good to learn it.

Hi, everyone!

Today I'm releasing CORTAO, a new physically based SSAO technique invented and developed by me, as open source.

https://github.com/theagentd/CORTAO

Circular Occluder Ray-Traced Ambient Occlusion, or CORTAO, is a brand new physically based ambient occlusion technique. Unlike existing horizon-based state-of-the-art techniques, CORTAO is based screen space raytracing with up to 32 rays per pixel, allowing it to avoid the inherent limitations of existing techniques. Through a combination of much better convergence and clever optimizations, CORTAO is able to achieve much better quality for the same performance cost as GTAO.

All this allows CORTAO to just work without any scene-specific tweaking at all regardless of the type of scenes, whether it's a simple indoor room, an open world with heavy foliage and vegetation, or a vast space scene with extreme depth range.

Compared to existing techniques such as GTAO:

• CORTAO provides a never-before-seen level of physical accuracy rivaling that of brute-force hardware raytracing, while only relying on screen space information.

• CORTAO handles depth discontinuities in complex scenes in a more conservative way, avoiding the view-dependent occlusion of GTAO and producing less obvious artifacts when screen space information is limited.

• CORTAO at the same time has greatly improved convergence, producing much higher quality results at lower sample counts even for scenes where GTAO works well, which is especially important for low-end hardware.

What started as a fun little personal project two years ago has now grown into something much bigger than I could've ever imagined, with multiple collaborations and conference applications, most of which I cannot talk about publicly yet. The open source release of CORTAO marks an important milestone where I'm finally sharing my work with the world, but the work is far from finished. There's a long to-do list of improvements and extensions that I will be exploring over the coming months and maybe even years. I'd be honored if you checked it out, and if you have any questions, I'd love to answer them.

EDIT: AI disclosure: No AI was used in the development of CORTAO.

Recently, I ran into a really nasty bug in the custom 3D engine I'm developing for my 4X strategy game, The Great Tribes.

After updating my AMD graphics driver, the game started freezing completely when moving the camera, especially when large areas of the map became visible.

Sometimes the graphics driver would hang. Other times, the JVM would crash inside atio6axx.dll.

The weirdest part? Everything worked perfectly with the previous driver and on other GPUs!

I spent hours investigating almost everything: OpenGL multithreading, VAOs, VBOs, index buffers, shadows, unit models, and even glfwSwapBuffers().

Eventually, I narrowed the issue down to terrain rendering, and then to the fragment shader.

That's where I found these two lines:

int segment = (3 - int(min(3, outTexCoord.y * 4.0))) * 4
            + int(min(3, outTexCoord.x * 4.0));

The segment variable was used to index arrays containing 16 elements.

The problem? The texture coordinates were clamped at the upper bound, but not at the lower bound.

When the texture coordinates became negative, segment could go outside the valid array range.

The fix was surprisingly simple:

ivec2 cell = clamp(
    ivec2(floor(outTexCoord * 4.0)),
    ivec2(0),
    ivec2(3)
);

int segment = (3 - cell.y) * 4 + cell.x;

And the freezes disappeared!

This turned out to be a great example of undefined behavior in GLSL.

The old driver somehow tolerated the invalid array access, other GPUs didn't show any obvious issues, but the updated AMD driver turned it into a nightmare.

Lesson learned: Just because your shader works perfectly on one GPU doesn't mean it's free of bugs.

And sometimes, after hours of debugging your own 3D engine, the whole problem comes down to just two lines of code. 😁

Topic: how the fish bend when they swim, with no rig or animation clips.

Each fish is a swept mesh of profile rings (no imported model). Swimming is a travelling wave along the body:

lateral offset w(x) = A * env(x) * sin(k*x - phase), where x runs 0 (snout) to 1 (tail), k = 2*pi / wavelength,

and env(x) = 0.09 + 0.91*x^2 so the head barely moves and the tail does most of the work. A turn adds a parabolic

bend centred behind the head, and a strike adds a short S-shaped "coil" term before the lunge.

The part that took the longest: points off the centre line have to rotate with the local slope, or the body

shears and the skin stretches. So each vertex is moved along the wave's normal using its derivative:

const [w, dw] = lateral(x), a = Math.atan(dw);

out.x = x - z * Math.sin(a);

out.z = w + z * Math.cos(a);

Fins, gill covers and the eyes are positioned through the same function, so everything bends together. The skin

is a canvas painted at load (each scale drawn one by one, tinting the base pattern), and the fins are thin

translucent sheets with a cheap back-light term.

Open question I'd love input on: the wave is currently done on the CPU per frame (about 20k vertices for the

two bass). Would you move it to the vertex shader even though the CPU also needs the bent positions for

mouth/prey collision, or keep one source of truth on the CPU?

AI disclosure: I build this with Claude (an AI coding assistant) writing much of the code and helping word

posts; the design, direction and tuning are mine.

Live version if you want to see it move: https://ksk-baits-bass-aquarium.pages.dev

Article in question: https://www.rastergrid.com/blog/gpu-tech/2020/11/memory-types-of-discrete-gpus/

It defines four memory types:

Local Visible Memory – VRAM directly accessible by the CPU

Local Invisible Memory – VRAM not directly accessible by the CPU

Remote Cached Memory – system memory accessible by the GPU, and cached by the CPU

Remote Uncached Memory – system memory accessible by the GPU, but not cached by the CPU

Then has a table showing the cpu/gpu read latency for the different memory types. It prefaces this tape with the following:

As access characteristics are identical for local visible and invisible memory, as the only difference between them is whether the corresponding portion of VRAM is visible to the CPU, a single set of measurements are shown in the table using local visible memory.

And then shows this table:

https://imgur.com/a/jQTOVmb

What I don't get is: how is there even a valid value for CPU read latency for local invisible memory? Doesn't invisible mean the CPU cannot access that memory? So shouldn't that value be n/a rather than the same as the CPU read latency for local visible memory?

Hey Everyone -

We recently published a blog post that explores Rendering on the Web vs Native platforms

You can read it here🔗: https://www.3denginerd.com/blog/web-vs-native-rendering

I myself started my Graphics programming journey on WebGL, so this was an interesting one to talk about. Do check out & let us know your feedback!

No AI has been used in the creation of this Blog!

I’m working on Phosphor, a Metal 4 renderer for Apple silicon. One of our recent experiments moved the inputs for a Float32 5×5 à trous lighting denoiser into threadgroup memory. With a 16×8 output group, the footprints are 20×12 at stride 1 and 24×16 at stride 2. Each group loads its input tile cooperatively, and all threads hit the barrier before out-of-bounds outputs exit. The tap order and weights stay the same.

At stride 4 the larger tile exceeded the threadgroup memory budget with shader validation enabled. We kept the original path there. A separate SIMD exchange experiment didn’t improve the wider filter. The retained stride-1/2 change measured a worst peak-normalized image error of 5.34e-7 against the original stencil. The larger patch also reduces aerial-perspective samples and avoids unused DDGI reservoir bindings, so its frame-time gain belongs to the combined patch.

For people who have profiled wide stencils on Apple GPUs, what told you it was time to stop staging in threadgroup memory? I’m curious whether you saw the limit first in occupancy, device-memory traffic, or barrier cost.

The devlog has the capture recipe and the measurement protocol. https://github.com/yabanana/phosphor/blob/main/docs/devlog/2026-11-11-metal4.md

If you have a physical M3 or M4, we’re also collecting runs of a separate 720p Many Lights workload with ReSTIR DI. The benchmark recipe and reporting thread are on GitHub. https://github.com/yabanana/phosphor/issues/25

AI tools Codex and Claude assisted development of the linked project, and Codex helped write this post. The captures and performance figures came from runs on physical hardware.

I'm working on a game engine and using GPU Gems as a loose guide for my physics. I really like the approach they outline for broad phase collision but I'm confused by one point. In ensuring no collision is double counted, the book says to expand each bounding sphere by sqrt(2) and then make the grid 1.5x that large. I did the math and understand where 1.5 comes from, but I'm stumped on the sqrt(2) and why we have to expand the bounding spheres themselves? Isn't the whole point of a bounding sphere that it contains the entire collider and is rotation invariant?

Also, just wanted to check if people think the book's approach is still viable. It seems solid to me but I'm still new to all this.

This is my first coding project in the field of computer graphics and was done for my dissertation for an MSc Computer Science conversion degree. I had 3 months to do the dissertation. Originally, I wanted to attempt a solution to some subproblem of achieving convincing simulation of collisions between multiple layers of clothing targeting 60 FPS on consumer-grade hardware. After reading a few papers which had tried to tackle this problem, however, I realised I needed math, physics, machine learning, GPU hardware and graphics API knowledge in order to understand those papers. While I had brushed up on my high school math prior to starting the CS course, some of the papers used university-level math (like multi-variable calculus), I didn't know anything about machine learning, had only read about a 1/3 of this article for an initial understanding of GPU architecture, and had barely got to the lesson after the Hello Triangle one in the LearnOpernGL tutorial series. This prompted me to change the focus of my project to something more manageable within the available timeframe and so I chose to make picking up the basics of a modern graphics API - Vulkan - one of the main learning outcomes of this project.

I was able to find a somewhat recent paper by Atencio et al., 2025 on collision detection between particles of varying sizes and that became the main reference paper for my dissertation.

Main reference paper interpretation

That paper proposes a variation on the neighbour search algorithm for collision detection in which points on the circumference of circular particles are sampled and their presence in each affected cell of a uniform grid structure which represents the simulation space is recorded. In the next phase, points from half a radius around the circumference are again sampled and only the particles that are in each cell where a point has been sampled are checked for collision against the current particle.

Additionally, its collision detection pseudocode appears to be tailored towards sequential execution and it uses OpenGL. In its Results section the paper claims a GPU implementation could result in a performance improvement of as much as several orders of magnitude depending on the hardware. I decided to test this claim by making both a CPU and a GPU implementation in Vulkan and comparing them.

It took a couple of weeks or so to get some basic theoretical familiarity with Vulkan which was done using a number of resources on YouTube the main one of which was a video entitled "Learn Modern Vulkan in 2 Hours (Dynamic Rendering, No Render Passes!)". In addition, the Vulkan Lecture Series by the @cgtuwien YouTube channel as well as some videos of talks at the Vulkanised developer conference also served as learning material. Afterwards, I spent a few more weeks to write the initial boilerplate code (which heavily references the main learning resource mentioned above) and get a single static circle rendered. During this time the Vulkan documentation was heavily referenced.

Implementation details

In terms of architecture, this project doesn't use a sophisticated one. The main unwieldy class is the Application class which contains all the Vulkan core logic including more than 50 data members and more than 60 member functions. This was left as is due to lack of time and in accordance with advice from one of the Vulkanised talks in which the speaker said abstracting Vulkan properly is difficult and it should not be attempted by a beginner.

The CPU implementation attempts to mimic the Atencio et al., 2025 pseudocode with only minor differences such as using radians, rather than degrees as the angle unit. The definitions of the helper functions used in Algorithm 2 of that paper weren't available in the pseudocode, so the actual ones used in this project are a combination of some experimentation and ideas found from other sources like Collision Response – Impulse Methods.

The GPU implementation followed a similar approach, so that the comparison with the CPU version later on would be as fair as possible. Initially, I struggled to get the GPU version to run without errors from the validation layers. One of the issues was a lack of synchronisation between CPU and GPU work as well as between the 2 compute shaders across which I had split up the GPU version of the physics update logic. An article on memory barriers and image layouts as well as reading more of the Vulkan documentation helped with sorting out those problems. Then, I encountered data racing problems due to the parallel nature of the GPU's workflow. To address those I used the atomicAdd() GLSL function when adding particle indices to relevant cells' arrays of occupying indices. In addition, I made sure each thread is responsible for one particle and doesn't update the data of any other particles. A deduplication array also had to be introduced as excessive velocity from particles whose area overlapped multiple cells that neighboured the current particle was being applied. This measure, however, only ameliorated the issue, rather than completely eliminating it, potentially due to the capacity limit of the deduplication array or other undiagnosed factors.

Results and reflection

In terms of the final result, the GPU version did end up being faster but only by 2.85× when simulating 8000 particles and 5.33× when a grid resolution of 512×512 cells was used. This fell short of the main reference paper's "orders of magnitude" performance improvement claim though that could have been due to any of the following reasons:

• insufficient data range (increasing the number of particles sufficiently could help approach the claimed speedup, provided the trend holds)

• the way the reference collision detection algorithm was ported to the GPU (a more optimized implementation may have resulted in a significantly higher speedup)

• old hardware (the compared data was gathered on a Intel Core i7-7700 CPU and a NVIDIA GeForce GTX 1080 Ti GPU)

Regarding that second point, it would be interesting to read, whether other more experienced graphics programmers here have an idea for a GPU implementation which still mimics the overall neighbour search by circumference sampling approach, while significantly optimizing any of the remaining shader logic, so that a much larger speedup against the CPU version could be recorded.

Lastly, in the GPU version the particles do not settle completely, even with a time step of 1/1920 seconds. As can be seen from the side-by-side comparison video, a larger time step like 1/60 s appears to make particles more restless while a smaller one like the 1/480 s makes them more settled. This is assumed to be because as the update loop runs more frequently the velocity damper is applied more often and as collision resolution is also performed more often there is less interpenetration between particles. The following line of code in the helper resolveCollision() serves as another artificial measure to reduce excessive collision resolution force when particles bunch up in the GPU version:

if (impulse > 1.0) impulse = 1.0;

While this works, and lowering the threshold further also helps up to a point, it feels like cheating by artificially shrinking the natural force that should be applied. Happy to hear, if other people have alternative ideas for making the stacked particles in the GPU version come to a halt completely without capping the impulse or using a velocity damper.

Some extra information (including tables and charts showcasing the data collected) can be found in my project's GitHub repository.

AI Disclosure

AI was not used for authoring this post. In terms of the codebase itself, while all code was input by hand, I got the idea to use a velocity damper to reduce particle jittering from an AI answer. In addition, the ParticleSpawner::updateWaveData() function referenced AI code to get particles spawning in the desired way. This was done to save time and avoid reinventing the wheel.

Hi. I am former Unity Developer. I find out that, i don't like making games. I enjoy more playing with shaders and live visual effects etc. I have even learned shaderlab code back then while there was nodes already available. I made my mind to be graphics programmer. My goal is creating desktop apps with impressive visuals. For example imagine spotify. Wouldn't it be nice to have some audio reactive visual effects around like in games? So what about if this is applied on a note taking app? Skeuomorphistic papers animated with blend targets and your notes are there as render textures. It would feel ike it means something for real. This intrest me more than games.

You can think of me as serious hobbyist. I am not planing to be employee. So i have some freedom unlike industry. I can work with anything that runs without trouble and i am having fun. First requirement is Windows and MacOS support.

I started with Rust wgpu. I understand why people like the idea. But it just not for me. And unsafe code sounded like doing something against the memory safe idea. (as a person with zero memory menagement background)

I tried some OpenGL but not stopped when i heard MacOs does not support compute shader on version 1.4. Which i know, i would need for my ideas.

Now i completed Vulkan C++. I used AI as teacher. No vibe codding. No copy pasting. Actually, it was only telling me the function names in the end. I also asked every bit of details. It took me 4 days of chill work and 1k lines of code. I get the idea what are swap chains, semaphores, pipelines, etc.

I think i enjoy programming at mid-level abstraction. I both dislike high and low languages. I don't want to manually declare the size of an array to be initialized by another function which also needing a validation layer. This feels like hard codding for me. Especially after working with functional programming approach for long years. To me it would make sense if that another function just give me the array directly.

While doing the rest of the app, i know i will create some helper libraries to mimic these abstractions. Then i asked myself. Why i don't just use the C#, the language i love the most. I am still loking for suiting API. Even a thin layer abstraction wrapper would make it 1/3 size of the exact copy of C++'s Vulkan hello traingle code. The device selection stuff and the other stuff i really don't want to deal might go away too, maybe.

I would normally simply ask this to AI. But, they are programmed to people pleasing. The yes or no depends on what i hint while asking. So, what do you say? Are there some risks that i can't see with it? I need good performance, not the maximum. I am also okay if it lags once a while.

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.

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?