The current implementation of the collision reaction is not yet complete. On one hand there is a bug hiding, that prevents some collisions from being registered and on the other hand the design is not symmetric. There are also some performance issues that could be handled, like: collision objects that are not registered for any collision at all do not need to be checked.
I'll keep you informed.
[Closed] Collision Reaction Redesign
Moderator: PPS-Leaders
[Closed] Collision Reaction Redesign
Last edited by patrick on Sat Dec 16, 2006 3:55 pm, edited 1 time in total.
Just finished the new collision reaction module.
- * fixed a bug that prevented every second entity from registering collisions
* greatly enhanced the collision detection/reaction speed
* lowered used memory (slightly)
* nicer framework
I'm not quite happy with the new collision :/
I made a testmap yesterday to check the limits of orxonox (~3500 cubes in one room).
Yesterday, with the old collision I had:
- around 20 fps (guessed) - that's ok for 3500 cubes
- the player didn't collide correctly with the 3500 little brushes, but there was some sort of collision (it wasn't correct, but I could see the good will
)
- the view vibrated as soon as I moved the mouse (running straight forward was no problem) - as in your jail-map
today, with the new collision I had:
- around 10 fps (guessed again)
- absolutely no collision with the small brushes
- the same vibrations as before (seems to be in relation with the amount of collision checks - I had no problems on a smaller map)
There is only one improvement: With the 3500 cubes behind me, the performance was much better than before (and no vibrations - cool!), but there is also a VERY strange bug:
My player seems to increase his jumping height with every collision check.
In fact, I was able to jump up to the ceiling in the high-poly room.
But as the collision works fine with "normal" brushes, I won't really build 3500 cubes in the space station
I made a testmap yesterday to check the limits of orxonox (~3500 cubes in one room).
Yesterday, with the old collision I had:
- around 20 fps (guessed) - that's ok for 3500 cubes
- the player didn't collide correctly with the 3500 little brushes, but there was some sort of collision (it wasn't correct, but I could see the good will
)- the view vibrated as soon as I moved the mouse (running straight forward was no problem) - as in your jail-map
today, with the new collision I had:
- around 10 fps (guessed again)
- absolutely no collision with the small brushes
- the same vibrations as before (seems to be in relation with the amount of collision checks - I had no problems on a smaller map)
There is only one improvement: With the 3500 cubes behind me, the performance was much better than before (and no vibrations - cool!), but there is also a VERY strange bug:
My player seems to increase his jumping height with every collision check.
In fact, I was able to jump up to the ceiling in the high-poly room.
But as the collision works fine with "normal" brushes, I won't really build 3500 cubes in the space station
Thx for the fast feedback. Perhaps you can show me this test next Wednesday in the PPS.
Actually the collision detection with the bsp map has not changed. I think that the difference of 10fps causes the collision precision to drop
no correct collision reactions.
But I don't know why the framerate dropped so much! I will perhaps have to do some rethinking.
If we are lucky, Claudio will reimplement the collision detection with ode. This would solve all performance issues!
Actually the collision detection with the bsp map has not changed. I think that the difference of 10fps causes the collision precision to drop
no correct collision reactions.But I don't know why the framerate dropped so much! I will perhaps have to do some rethinking.
If we are lucky, Claudio will reimplement the collision detection with ode. This would solve all performance issues!
For sure. Oh, and there's another bug, but I can't explain it yet. I'll show it to you Wednesday, but I'm not sure if it will appear on Linux systems as well. Stay tuned, more work to comepatrick wrote:Thx for the fast feedback. Perhaps you can show me this test next Wednesday in the PPS.
As the fps were guessed, I'm not that confident with them. I'll recheck on Wednesday, before and after the svn update.But I don't know why the framerate dropped so much! I will perhaps have to do some rethinking.
That would be greatIf we are lucky, Claudio will reimplement the collision detection with ode. This would solve all performance issues!
Hi
Since I won't attend a 'Fachpraktikum' next Wendesday I could pass by at the PPS, if that was OK. So you could tell me how/where I best integrate ODE's collision detection.
On the other hand I like the thought of having our own collision detection..
I hope I'll do so. As I got the collision detection with ODE basically working, I think this will be not such a big deal. It'll all be about integrateing ODE's collision detection into the new collision framework.If we are lucky, Claudio will reimplement the collision detection with ode. This would solve all performance issues!
Since I won't attend a 'Fachpraktikum' next Wendesday I could pass by at the PPS, if that was OK. So you could tell me how/where I best integrate ODE's collision detection.
On the other hand I like the thought of having our own collision detection.
.hi claudo!
long time no see! (sorry for that crapy english, but it's just this classical expression)
Its probably better if we will merge the trunk back to your branche so you will be able to work on the newest state. We could do this also on wednesday.
looking forward!
long time no see! (sorry for that crapy english, but it's just this classical expression)
This would definitely be very cool! I will take myself enough time to speak through whatever you wanna know. I'm realy looking forward to this!claudio wrote: Since I won't attend a 'Fachpraktikum' next Wendesday I could pass by at the PPS, if that was OK. So you could tell me how/where I best integrate ODE's collision detection.
Ja, it was an adventure to implement it and not easy at all. But now, that it works, I'm eager to see how the pros are solving this problem.claudio wrote: On the other hand I like the thought of having our own collision detection
Its probably better if we will merge the trunk back to your branche so you will be able to work on the newest state. We could do this also on wednesday.
looking forward!
Who is online
Users browsing this forum: No registered users and 15 guests