BEPUphysics

Hi,

I'm currently working on a default implementation of BEPUPhysics in my framework (IGF for SunBurn http://igf.codeplex.com)

Question I: Sender & Other identification
As part of it, I'm hooking the Entity.CollisionInformation.Events.InitialCollisionDetected event and I'm wondering in the handler how I can identify which of the "sender" and "other" Collidable instance passed to the delegate signature is the one I'm currently in.

Say, I have a CollisionEntity class that wraps an Entity instance and I hook the above event in the CollisionEntity constructor to a OnEntityInitialCollisionDetected(EntityCollidable sender, Collidable other, CollidablePairHandler pair) method.

Should I always test in this method:
if(sender == this)

To know which of the sender or other is the currently wrapped entity instance.
Or is there any rule that ensures that the sender is always the Entity that is attached to the hooked event?

Question II: Modifying CollisionRules once InitialCollisionDetected
Moreover, let's say I don't want to apply the Collision effects else "trigger" an event (useful for bullet collisions for instance). Would it make sense to apply a CollisionRules.NoSolver to the Entity.CollisionRules inside the InitialCollisionDetected event?
I know that I can set this before but that would save me an extra call in my API.

Thanks

Or is there any rule that ensures that the sender is always the Entity that is attached to the hooked event?

The "sender" in all events is indeed the collidable which had the event hooked. That is, if you hook an event handler to Collidable A, and then Collidable A hits Collidable B, the event handler will have Collidable A in the 'sender' parameter and Collidable B in the 'other' parameter.

To extend the example, if you also put an event handler on Collidable B, then two handlers will run and the second handler will have Collidable B as the sender and Collidable A as the other.

Question II: Modifying CollisionRules once InitialCollisionDetected
Moreover, let's say I don't want to apply the Collision effects else "trigger" an event (useful for bullet collisions for instance). Would it make sense to apply a CollisionRules.NoSolver to the Entity.CollisionRules inside the InitialCollisionDetected event?
I know that I can set this before but that would save me an extra call in my API.

InitialCollisionDetected is a deferred event which means it's actually being called from a safe sequential context at the end of a space update. Changing the collision rules there would not stop one frame's worth of collision solving from taking place.

The present-tense version (as detailed in the events documentation: http://bepuphysics.codeplex.com/wikipag ... umentation) is called from the in-line, possibly asynchronous, context. These "immediate" event handlers require greater care due to their ability to corrupt shared state.

So you can indeed use the immediate DetectingInitialCollision to change collision rules to stop solving since a pair's CollisionRule isn't shared state. However, in some cases it could be simpler to just give the projectile a personal collision rule of NoSolver if you never want it to have collision response with anything, or use collision groups and other collision rule features to specify more precise behaviors.

I'm currently working on a default implementation of BEPUPhysics in my framework (IGF for SunBurn http://igf.codeplex.com)

Great job on IGF by the way

Thanks for the kind words on IGF. You did a tremendous job with BEPUPhysics too

I have now a better understanding on the event handling stuff. I also looked at the lib internal behavior and I believe I got it how it works.
You probably right, it is safer to modify the state outside of the Space.Update() call and let the developer do as he really expects it to work. Sometimes, I tend to automate too much things

I'll keep you posted how I move on with my integration. So far, I manage to get the movements and collisions working even with my Steering Behaviors and AI implementation without changing a line on them (it uses a set of interfaces to communicate with abstracted features )