In my last post I mentioned that using brute-force approach for collision detection I can handle 200 objects on my machine with 60 fps. My next step was to add some spatial structure for fast collisions.
For that I choosed uniform grid - it's easy to manage and simple to implement. For debugging purposes I created grid mesh. But it was hard to see anything in this mess of cubes:
So my next (and current) approach is just to show a cell that is occupied by an object. Like this:
In the end you can see how simulation explodes. And the bad thing that fps dramatically drops. I'll try to explain why.
When I'm finding that object collides I separate it from another. Now, with a new position I make a new test with another object and if there's colision again I separate them again. Probably again to the old position. And so on. When my main ship stands still all other cubes move to it. Actually they all move to one point - center of my ship. There's a big competition for the place. Because of that object can jitter a lot. And when it change it's position, it's matrix should be recalculated. Moreover, in one single time in one cell can bee too many objects.
For grid implementation I choosed a vector for storing objects in one cell, i.e. when a ship goes to new cell it should be removed from the old one and added in the new. Since I'm using a vector the only way I know for object to be removed is splice() method. And this method causes a memory leak and performance issues (because of rest parameter). Again, when an object jitters it changes cells very often causing splice() to be called more intensivelly. Of course I'll change it to something different, linked list probably.
My next step will be not to set new position every time object collides (and recalculate a matrix), but to use some sort of accumulation buffer. For every collision I'll add offset to it and apply translation only once - after all calculations are done. This is of course not accurate, but I think it worth to try to see how it'll behave.
Another optimisation I'll try is a final matrix calculation. Currently object's transform consists of three matrices - scale, rotation, translation. In my current game I don't use scale at all. For some objects rotation or translation not needed. So why to use them, that's a lot of calculations. I'll introduce maybe a flag which will tell should I use some matrix or not.
That's it, stay tuned.
For that I choosed uniform grid - it's easy to manage and simple to implement. For debugging purposes I created grid mesh. But it was hard to see anything in this mess of cubes:
So my next (and current) approach is just to show a cell that is occupied by an object. Like this:
The color of cell depends on the number of objects inside it.
Using this grid I can now have 500 colliding objects with 60 fps.
In the end you can see how simulation explodes. And the bad thing that fps dramatically drops. I'll try to explain why.
When I'm finding that object collides I separate it from another. Now, with a new position I make a new test with another object and if there's colision again I separate them again. Probably again to the old position. And so on. When my main ship stands still all other cubes move to it. Actually they all move to one point - center of my ship. There's a big competition for the place. Because of that object can jitter a lot. And when it change it's position, it's matrix should be recalculated. Moreover, in one single time in one cell can bee too many objects.
For grid implementation I choosed a vector for storing objects in one cell, i.e. when a ship goes to new cell it should be removed from the old one and added in the new. Since I'm using a vector the only way I know for object to be removed is splice() method. And this method causes a memory leak and performance issues (because of rest parameter). Again, when an object jitters it changes cells very often causing splice() to be called more intensivelly. Of course I'll change it to something different, linked list probably.
My next step will be not to set new position every time object collides (and recalculate a matrix), but to use some sort of accumulation buffer. For every collision I'll add offset to it and apply translation only once - after all calculations are done. This is of course not accurate, but I think it worth to try to see how it'll behave.
Another optimisation I'll try is a final matrix calculation. Currently object's transform consists of three matrices - scale, rotation, translation. In my current game I don't use scale at all. For some objects rotation or translation not needed. So why to use them, that's a lot of calculations. I'll introduce maybe a flag which will tell should I use some matrix or not.
That's it, stay tuned.
Комментариев нет:
Отправить комментарий