ICollisionCallback added to collision response animator

rogerborg · Post by **rogerborg** » Tue Jan 20, 2009 11:08 pm

Thanks to garrittg for this patch. SVN 2111 on the trunk adds an optional ICollisionCallback to the ISceneNodeAnimatorCollisionResponse animator. ISceneNodeAnimatorCollisionResponse also stores and exposes the last collision point and the triangle that was hit.

So when a collision occurs, the user application gets called back and passed the animator. It can then extract the node that the animator is acting on, the collision point, and the hit triangle, and can either allow or stop the collision being applied to the node.

There's no usage of it in the example apps (yet), but tests/collisionResponseAnimator.cpp exercises the functionality.

Comments, suggestions and fixes are welcome.

Mel · Post by **Mel** » Wed Jan 21, 2009 11:18 am

Does it mean it can perhaps trigger when a any scenenode colide with another? so that perhaps, it could be like an "onCollision" method that returned the colider object, and the exact point, and such?

rogerborg · Post by **rogerborg** » Wed Jan 21, 2009 11:57 am

No. If you have a request for a new type of collision, then I'd love to see your detailed requirements.

Mel · Post by **Mel** » Wed Jan 21, 2009 12:01 pm

For a request. That any ISceneNode had an onCollision method, just like the onEvent, so, if any ISceneNode colided with another, the collision was reported, in a rough draft. I thought it was something like that. But even though, i think it can be done in some way with that extension. Good.

Sylence · Post by **Sylence** » Wed Jan 21, 2009 1:11 pm

You should remember that Irrlicht is not a game engine. Imho the collision stuff that Irrlicht already has is already too much. If you need physics you should use a physics engine.

JP · Post by JP » Wed Jan 21, 2009 1:13 pm

Yeah i think that's a good point... improving the collision stuff in this way would make it more usable, whilst still being a bit too limited for anything more than a tech demo so people would be tempted to stick with it over a physics engine when they shouldn't really...

Mel · Post by **Mel** » Thu Jan 22, 2009 4:06 pm

I haven't spoken of Physics at all. I mean, I think that using a physics engine for collision detection is way too limited, for a physics engine, if you have a physics engine, do physics simulations with it.

Given it has already collision methods for coliding with large amounts of triangles, why not giving also a way to detect automatically when 2 scene nodes have colided and that it gives a response to act accordingly? I don't think that is a game feature only, and could improve the engine. Besides, what i like of Irrlicht is its extraordinary flexibility, and while you still could make use of Physics engine for the purpouses you want, if you simply need to know when 2 objects are too close, but you don't know which, when, or where is it going to happen, and you can automate the process of resolving that collision with a feedback that can trigger at any time, and any place, better.

rogerborg · Post by **rogerborg** » Thu Jan 22, 2009 4:23 pm

I think we'd need more detailed requirements.

What sort of collisions?
Box-box, or something more complex?

Which nodes should be tested, and against what?
Every node against every other node?
Individual nodes against every node?
Individual nodes against a subset of the scene graph?
Individual nodes against other individual nodes?
Against specific types of nodes, or not?
Using a bitmask, or not?
Against invisible nodes, or not?

When to do collision?
On demand from the user app?
During the regular processing of each testing node?

I ask because collision detection is an N^2 problem, so we'd want to design optimisations in.

christianclavet · Post by **christianclavet** » Thu Jan 22, 2009 4:37 pm

I'd really love to see a demo on how it's working! Great Rogerborg, this will be really useful. I have a question on the collision subject, is there a way to have an invisible collision mesh working with the irrlicht collision system?

I could do a very simplified version of the map where the player will walk, so the collision system could use that instead of the mesh. I would convert that simplified mesh to an occtree, can we have invisible occtree working with the collision response animator? (Not rendered)

Mel · Post by **Mel** » Thu Jan 22, 2009 5:22 pm

I think we'd need more detailed requirements.

What sort of collisions?
Box-box, or something more complex?

Which nodes should be tested, and against what?
Every node against every other node?
Individual nodes against every node?
Individual nodes against a subset of the scene graph?
Individual nodes against other individual nodes?
Against specific types of nodes, or not?
Using a bitmask, or not?
Against invisible nodes, or not?

When to do collision?
On demand from the user app?
During the regular processing of each testing node?

I ask because collision detection is an N^2 problem, so we'd want to design optimisations in.

I know it is a complex problem. I'm speaking just of bounding box collisions.

From what i imagined, what we could be speaking of is scene nodes which wanted to receive collision events, just in their bounding box, that only could receive collision events from another scene nodes which are registered to receive collision events.

It would be an "every node against every node" approach, That is as a general way of working, of course this is open to optimizations. Then if perhaps, a node is a parent of a group of nodes, given the parent had a bounding box that enclosed all of its children, doing collision test with the parent first could save processing time if the test failed, giving the posibility to process less nodes.There could be optimizations, such as testing against marked nodes, if you want to colide to a type of nodes, but you don't want, or care about others, that could be a posibility too, this could use bitmasking.

Invisible nodes are ambiguous. you can't see them, but they must mean something if you want to test a collision with them, so if you want to test an invisible node, you should register it for events.

When to do collision tests?. the ideal thing would be that it was an event that happens to the scene node, so, as an event, it should be triggered at any time. Then, the event itself could be processed by the node if it had an onCollision() event implemented. More or less, that would be what i've thought of.

This is much more an approach from the external point of view of the problem, where the things work just fine, and no one cares about how. But that was my idea. Don't take it as a formal request, but as a sort of challenge, if it works, i think it could improve the engine, if not, is okay.

rogerborg · Post by **rogerborg** » Thu Jan 22, 2009 6:00 pm

I do love collision detection, but I honestly think that this is something that's more in the application domain. Irrlicht provides aabbox methods already; what we could do is to add non-aabbox checks as well (callable by the user app). I'll put that on the mental ToDo.

Dark_Kilauea · Post by **Dark_Kilauea** » Thu Jan 22, 2009 8:10 pm

Perhaps what someone should do is create a collision library for basic collision detection and handling (not an actual physics simulation) for game which don't require and would actually be hindered by a more advanced simulation.

Or at the very least, provide utility functions and classes to help the user with creating their own implementation.

I'd volunteer to do something like this if I honestly had the time to do so. :/

Mel · Post by **Mel** » Fri Jan 23, 2009 4:28 pm

I see, the good thing is that Irrlicht still has any tool to provide a similar functionality, though in a more active way. What i talked about was a pasive system too, so it was faster to react when 2 iscenenodes had colided. Is okay.