| 10-10-2007, 01:35 PM | #1 |
Anyone got ideas of doing effective optimized collision detection? just spam ideas here please. I'm asking for algoritm |
| 10-10-2007, 02:28 PM | #2 |
What is the complexity of your current detection algorithm? O(n^2) ? |
| 10-10-2007, 02:32 PM | #3 |
O_O wow very clever xD. the only one who REALY knows it it's grim001 =) i havent spend much time on collisions. well use code inside GroupEnumUnits... use globlas for transfare. don't intialize to much local vars in filter func. optimize the calculations (avoid some "fancy" stuff) |
| 10-10-2007, 02:34 PM | #4 | |
Quote:
LoL that algorithm can be found in any half-good book on algorithms (for example the one I am looking at right now) So the only question here is: "how much money do you have MaD[Lion]?" EDIT: One important question, do all units on the map have same collision radius? EDIT2: @Toadcop As far as I know grim's old physics engine is not using the most optimized algorithm. It is based on representing units as spheres and that requires the use of sqrt function. The fastest methods are based on representing units as boxes (or set of boxes) For example in CS you have a box for torzo, head, leg and arm parts. Of course in wc3 using one box per unit is quite enough. Boxes have that advantage that you can check collision coordinate per coordinate. So if units don't collide by X you can avoid calculating collision by Y and Z This is funny: Results 1 - 10 of about 1,770,000 for collision detection algorithm. (0.28 seconds) |
| 10-10-2007, 04:26 PM | #5 |
lol cohadar. once again talking about a subject you know nothing about. anyway I spent months developing my collision detection/resolution, somehow it feels wrong to hand over the code just because someone asked for it... although it will eventually be released anyway... This site uses a method similar to mine: http://www.gamedev.net/reference/pro...here/page2.asp Of course you have to prune the number of checks, that should be done using GroupEnum. |
| 10-10-2007, 06:39 PM | #6 |
I still think that box algorithm would be faster. It could be even be built directly into periodic movement loop by using center of mass of all objects that are currently moving. I do like talking about subjects I know little about, but don't forget I get to know them really fast. Anyways we are all waiting for that engine grim (no pun intended), I just hope it is not a monolythical monster like MaD[Lion]s' |
| 10-10-2007, 09:23 PM | #7 | |
Quote:
btw cilinders in war3 are the best solution as for me. |
| 10-10-2007, 10:49 PM | #8 |
I am going to put a lot of effort into modularizing it but only to the extent that I can do so without sacrificing a noticeable amount of performance. Either way the user end is a thing of beauty, no one needs to look inside the black box. |
| 10-11-2007, 05:16 AM | #9 | |
Deleted useless posts. Quote:
|
| 10-15-2007, 11:43 AM | #10 | |
Quote:
I haven't been here for a while so I am answering a bit late here. Just wanted to say that purpouse of modularization is to make code easier to debug/maintain, not to make it look "pretty". So by modularizing code you are actually helping yourself, performance should not be a victim of that process, on the contrary modularizing often results in increased performance because you see bottlenecks more clearly. |
| 10-16-2007, 02:59 AM | #11 |
in wc3, when u modarize, it is impossible to avoid calling some functions (for connection between modules). And these calls of functions, are wat i dont want. Therefore i did not modarize my system. Function calls cost just too much performance, cant afford that |
