BGE DEV: New "Sensor" physics object for advanced collision management

[Ace Dragon]

http://lists.blender.org/pipermail/b...ay/019429.html

BGE: new sensor object to generalize Near and Radar sensor, static-static collision capbility. A new type of "Sensor" physics object is available in the GE for advanced collision management. It's called Sensor for its similarities with the physics objects that underlie the Near and Radar sensors. Like the Near and Radar object it is: - static and ghost - invisible by default - always active to ensure correct collision detection - capable of detecting both static and dynamic objects - ignoring collision with their parent - capable of broadphase filtering based on: * Actor option: the collisioning object must have the Actor flag set to be detected * property/material: as specified in the collision sensors attached to it Broadphase filtering is important for performance reason: the collision points will be computed only for the objects that pass the broahphase filter. - automatically removed from the simulation when no collision sensor is active on it Unlike the Near and Radar object it can: - take any shape, including triangle mesh - be made visible for debugging (just use the Visible actuator) - have multiple collision sensors using it Other than that, the sensor objects are ordinary objects. You can move them freely or parent them. When parented to a dynamic object, they can provide advanced collision control to this object. The type of collision capability depends on the shape: - box, sphere, cylinder, cone, convex hull provide volume detection. - triangle mesh provides surface detection but you can give some volume to the suface by increasing the margin in the Advanced Settings panel. The margin applies on both sides of the surface. Performance tip: - Sensor objects perform better than Near and Radar: they do less synchronizations because of the Scenegraph optimizations and they can have multiple collision sensors on them (with different property filtering for example). - Always prefer simple shape (box, sphere) to complex shape whenever possible. - Always use broadphase filtering (avoid collision sensor with empty propery/material) - Use collision sensor only when you need them. When no collision sensor is active on the sensor object, it is removed from the simulation and consume no CPU. Known limitations: - When running Blender in debug mode, you will see one warning line of the console: "warning btCollisionDispatcher::needsCollision: static-static collision!" In release mode this message is not printed. - Collision margin has no effect on sphere, cone and cylinder shape. Other performance improvements: - Remove unnecessary interpolation for Near and Radar objects and by extension sensor objects. - Use direct matrix copy instead of quaternion to synchronize orientation. Other bug fix: - Fix Near/Radar position error on newly activated objects. This was causing several detection problems in YoFrankie - Fix margin not passed correctly to gImpact shape. - Disable force/velocity actions on static objects

This system will allow for advanced collision management and allows things like static-static collision, also, this will likely be the last big commit in the BGE for 2.49 as said below

**** 2.49 - Some complaints went on that too many new (although good!) GE stuff went in svn last weeks, postponing release. Benoit promised it's done for now though.

[SamCameron]

That is one of those things that Blender should must have, so finally is done, STATIC COLLISIONS !! that sounds great , what a shame there will be no soft shadows in 2.49 .

[J09]

Some complaints went on that too many new (although good!) GE stuff went in svn last weeks, postponing release.

Hm... you won't hear me complaining. Good work devs!!!

[Blendiac]

Some complaints went on that too many new (although good!) GE stuff went in svn last weeks

Damn straight. All this new feature stuff just makes it that new users think being an artist is easy! *hrumph!* I say no new features for Blender - ever! In fact, let's strip out the ones we don't need currently, like modelling, lighting, texturing and animation. We'll all finish up much faster without any of that stuff.

[kay_Eva]

I hope this get built on graphicall soon trigger volumes make everything awesome

[kirado]

- Some complaints went on that too many new (although good!) GE stuff went in svn last weeks,

.. er.. who was complaining and why (curious)? Yeah I hate it when stuff improves and gets better.. it's sooo terrible lol.

I think the other Blender users are just jealous that now that the GE has a larger group of motivated devs than ever before, that it just appears, to impatient users, that there have been faster improvements than the 2.5 update ;-) Well that's my make believe theory, heh heh. Probably just some commit convention thing..but it has been like this before.

[Moguri]

The complaints have been coming from the fact that 2.49 has been in a release candidate stage for a while now, which is supposed to be bug fixes only at that point.

[kirado]

Yah, I figured it was probably something like that. Thanks for clearing it up.

[jessegp]

so sweet baby Jebus i've been wanting this for soooooooooooo long.

[Blendiac]

Has anyone managed to find where this is in the UI? I looked in the dynamic type dropdown / bounds / sensor / actuator... still no joy. I'm wondering if my graphicall build was from pre-this commit though...

[ben2610]

@Blendiac: this is a new physics type. It's between "no collision" and "static" in the physics type menu.
You will need revision 20239 or later to get it.

[moerdn]

Could someone give a short idea, how to use this feature? Is it useful to check whether the player is inside this volume or not and how do I combine it with a logic brick?

greetings, moerdn

[Littlebob]

What specifically does this mean?

Originally Posted by Benoit - Use collision sensor only when you need them. When no collision sensor is active on the sensor object, it is removed from the simulation and consume no CPU.

Is it possible to deactivate a collision sensor or does this just mean if you don't have a collision sensor on the object? It would be very nice if I could temporarily disable a collision sensor.

[Blendiac]

Originally Posted by moerdn Could someone give a short idea, how to use this feature? Is it useful to check whether the player is inside this volume or not and how do I combine it with a logic brick? greetings, moerdn

I'm using it to detect whether my character is touching the ground. Previously I used a ray, but the problem there was that if only the edge of the character was touching the ground, then the ray (in the middle of the character) missed it. Using a collision actuator on my character would also trigger if the side or top of my character was touching something. With this, I have a simple shape, that approximates the underside of my characters shape, parented just beneath them. If the sensor object is colliding with the ground, they're touching. Simple, flexible and effective.

Feel free to checkout my demo file here. (note: it requires a build more recent than RC3, such as the autobuild from graphicall.org)

[ben2610]

@Littlebob: yes you can deactivate a collision sensor: simply put the main object in a state where no controllers is connected to the sensor; it will be automatically removed from the physics simulation and the logic system and will consume no CPU. Changing back to a state where the sensor is connected will automatically bring it back in the simulation.

@Blendiac: if you use a sensor object with a triangle shape, don't forget to give it a width with the collision margin in the Advanced panel or your sensor object will easily miss the ground. Ideally the sensor object shape should touch the feet of your character so that the contact with the ground is never missed. Unfortunately, the margin is not visible in the 3D view but you can get a feel of the size of the shape in the game if you enable physics visualization.

[Littlebob]

Originally Posted by ben2610 @Littlebob: yes you can deactivate a collision sensor: simply put the main object in a state where no controllers is connected to the sensor; it will be automatically removed from the physics simulation and the logic system and will consume no CPU. Changing back to a state where the sensor is connected will automatically bring it back in the simulation.

Thank you.

I knew I should have been getting used to states much earlier. I have a feeling that it might be better and more efficient than how I have been doing it with allot of things.

[dabeanyo]

This is a very helpful addition to the game engine. Has anyone found errors with these new sensor objects, or are they good to go?
@Blendiac: Thanks for posting the demo file, it works well to show some of the new capabilities.