Feature request: Improving a little the collision response..

Discuss about anything related to the Irrlicht Engine, or read announcements about any significant features or usage changes.
Post Reply
christianclavet
Posts: 1638
Joined: Mon Apr 30, 2007 3:24 am
Location: Montreal, CANADA
Contact:

Feature request: Improving a little the collision response..

Post by christianclavet »

Hi.

I used the collision response and the meta selector for all my small projects and experiments, but lately, I had a little problem with it.

It's working but It's really slow to update geometry for the "world" for the collisions...

I'm not asking this now, since you guys have a hell of things to do and it's not getting anything to do with the rendering. It's just that theses little changes (I think there should not too much thing to change) might help a lot to improve performance when dealing with elements that changes in a collision world.

My first problem. (example)
I have 60 nodes and the player and want them to have each a collision responses animator, that use the "world" for the collsion.

If I use the "world" (meta selector), it contain the triangles used in the node that collision response animator. This will make the node collision with itself and get stuck.

A nice thing that would resolve this, would be that the collision response animator don't use the triangles of the node its' assigned on.

A quick solution was to remove the triangles of the node from the meta selector (method exist and work), but since the meta selector is shared among all the collision response animator assigned to all the nodes I can't reuse it for the other collision animators. So for one collision response animator in my scene, no problem. The problem occur if you want to have multiple collision response animators in the scene.

The current solution, that I'm using is to re-create a meta selector each time I'm assigning it to a collision response animator. So for the 60 nodes I have to create a meta selector (getting the triangles selectors for all the node except the one it's assigned so 59 nodes). It's working but its not really efficient. Removing a node from the "world" mean, rebuilding all this so it's not just done at startup but need to be done at runtime too, each time the "world" change.

I asked the forum if there would be a way to copy the object of the meta selector, so I could keep the "full world" in memory and only give reference to the collision response animation to a version without the triangles of the current node. Unfortunately, It's cannot be cloned without modifying the source code.

today I checked the source code, and I saw this in

Code: Select all

core::array<ITriangleSelector*> TriangleSelectors;
If we could have a method that you get access to this and the associated scene node would allow us to copy the array to another object, use the meta selector with the full scene, and remove the triangles of node the collision response animator will be applied on. If we could duplicate the meta selector, we could remove ourself the triangle of the node the collision response animator is applied.

Still the easiest way for the user is that the CollisionResponseAnimator would not use the collision triangles of the node its applied on.
CuteAlien
Admin
Posts: 9734
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany
Contact:

Post by CuteAlien »

First - usually you don't use real triangles for collision of dynamic objects. Instead typically invisible collision objects are used. But I think the main problem here is that our collision animator isn't really about dynamic collisions. Adding & removing selectors of dynamic objects to it is rather a workaround. The best solution would be to use your own collision animator instead. I'm not sure right now how stable the current one is if it is mixed with custom movement of the objects which it controls (probably not too good). As the best solution would be to use it only for the static geometry (the world). And do the object-object collisions additionally yourself (you only have to check if 2 objects are closer together than their combined radii - then you already have a simple dynamic collision detection. Reacting is more complicated... but pushing them in the opposite direction away from the center of the other object will basically work).
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Mel
Competition winner
Posts: 2292
Joined: Wed May 07, 2008 11:40 am
Location: Granada, Spain

Post by Mel »

I think it is much better to try a physics engine and leave only the graphics to irrlicht. Physics engines are meant to colide thousands of things in an optimized way. It is a bit of overhead for the program to bear perhaps with double the meshes, but in the long run, i think it is much worthy than using Irrlicht's collision system. If you aren't simulating neither clothes nor soft bodies, Newton is pretty much your choice here. Seems easy to use, and it is fairly easy to set it up.
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
christianclavet
Posts: 1638
Joined: Mon Apr 30, 2007 3:24 am
Location: Montreal, CANADA
Contact:

Post by christianclavet »

Hi! Thanks for answering so quickly!

First, I'm using the bouding box of the object not their real triangles. So it is not a problem. The current method I use work rather well is your not deciding to remove triangle from the world.

I think I could modify the IRRlicht source and do it myself now. But my code won't be IRRlicht type, so will be 99.9% refused. I'll see about this in a few day, If I take the time to do it, as since the beginning I only wanted to use an official IRRlicht distribution so it would be quick and easy to migrate to the next IRRlicht version.

I like your idea of checking around the radius of the objects (perhaps a bounding box test) to see if an object is about to collide. I could investigate if this need more work to do...

For more performance, I could only test only the moving objects with their surrounding. Since only the "moving" objects will be removed from the world, it could work. The test would be to test the moving object will all the other (capable of) moving object. Thanks for the idea, I really could use that since I want to focus more on the combat aspect itself than the collision. (As I said previously, it's really simple)

As for putting in place a physic engine, I don't have the time, nor the will to implement this, the need to be really simple and I would like to have a project that have as less dependancy as possible.

I learned a lot with my last experiences (Project First King, that will restart someday when I get enough programming experience to get the thing started and working, by myself).

A guy wanted to help me in that project and put lot of dependencies that were all patched (Linux), I was never able to port it to windows at the time and review what he had implemented. It was bad for everbody and I don't blame him. Don't want this to happen again. Right now the collisions performance on my current project (it's working 100%, but could get slow on crowded scenes when the world change) is just a nice option, and a physic engine is just overkill.
Post Reply