Hey folks,

at the moment, I was developing a Droplet Engine, which simulates raindrops falling upon a surface (which is the monitor). It's meant to give the impression of raindrops hitting our monitor from inside.

The system simulates size and weight of the droplets and the friction of the surface. It also manages droplets which are close to each other to merge and thereby increase the size of the droplet. You know the effect.

For this system, I am working on a quadTree system which is meant to reduce the number of collision detections immensely. For those who don't know how a quadTree works like, it divides the screen in four quarters and checks if more than two objects are inside the quarter. If yes, it divides this quarter in 4 quarters again and checks again if two objects are inside each quarter... and so on. Recursively.
Afterwards, you only have to check collision for those objects which do not have their own quarters.

http://lab.polygonal.de/2007/09/09/quadtree-demonstration/

This post gives a good impression of how it's meant to work.


But I digress:
This whole collision thing got me thinking if there was not a better way of increasing the speed of collision detection.
In my eyes, the problem is, that if the render method of our engine draws a pixel on the screen, it has absolutely no idea where this pixel comes from. It only receives the color of the pixel and draws it.

Now what if every pixel had a memory. It could remember a unique ID of the graphic object that causes the pixel to change its color and maybe a collisionGroupID.

Now if a pixel is being overwritten, it compares its actual collision group to the collision group of the new pixel value. If they match, the "ObservingPixel" e.g. throws a global PerPixelCollisionEvent which includes the unique graphic object IDs of the two colliding objects.

If I'm not mistaken, that would make a super-fast, perfectly precise per-pixel-collision system that makes hundreds and thousands of Collision-checks unnecessary.


What I wanted is to discuss this idea. What do you think of it? Maybe there already is a system like this? Maybe I miss something and it's a totally stupid idea... Criticism (positive and negative) is welcome.


Cheers,
Felix

I'm just kind of curious, but if you had a system like this wouldn't it spend a lot more time rendering seeing how you would have to check for each individual pixels change of collision group as it is updated? From what I think you are saying is to make a couple more calls per pixel to check for the change of collision group. These calls I'd think would take far more time then your quadTree calls which would take far fewer calls to check for the collisions.

I'm just kind of curious, but if you had a system like this wouldn't it spend a lot more time rendering seeing how you would have to check for each individual pixels change of collision group as it is updated? From what I think you are saying is to make a couple more calls per pixel to check for the change of collision group. These calls I'd think would take far more time then your quadTree calls which would take far fewer calls to check for the collisions.

Yes, that would be exactly the question.
My thought is:
Like I see it, everytime a pixel is drawn, it is simply one if-query. "Do the collisionGroups match?"
If an object has no collision group (like the background for example or other items without collision) it won't even be checked at all..

Compared to that, drawing a quadtree each frame, especially with lots of objects which does simple collision detection as well seems much more time consuming to me...

That has been done in the past (see older OpenGL and mouse picking examples) and is super easy to implement today. However, it is not common because it requires extra memory, render, and hoisting render targets from video to CPU RAM (expensive and slow). As a general rule, it provides very little benefit or speed up over standard collision systems, while inextricably tying your collision code to your rendering code.