blender/source/gameengine/Ketsji/KX_TouchEventManager.cpp

222 lines
6.9 KiB
C++
Raw Normal View History

/*
* ***** BEGIN GPL LICENSE BLOCK *****
2002-10-12 11:37:38 +00:00
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
2002-10-12 11:37:38 +00:00
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software Foundation,
2010-02-12 13:34:04 +00:00
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
2002-10-12 11:37:38 +00:00
*
* The Original Code is Copyright (C) 2001-2002 by NaN Holding BV.
* All rights reserved.
*
* The Original Code is: all of this file.
*
* Contributor(s): none yet.
*
* ***** END GPL LICENSE BLOCK *****
2002-10-12 11:37:38 +00:00
*/
2011-02-25 13:35:59 +00:00
/** \file gameengine/Ketsji/KX_TouchEventManager.cpp
* \ingroup ketsji
*/
2002-10-12 11:37:38 +00:00
#include "KX_TouchEventManager.h"
#include "SCA_ISensor.h"
#include "KX_TouchSensor.h"
#include "KX_GameObject.h"
#include "PHY_IPhysicsEnvironment.h"
#include "PHY_IPhysicsController.h"
2002-10-12 11:37:38 +00:00
KX_TouchEventManager::KX_TouchEventManager(class SCA_LogicManager* logicmgr,
PHY_IPhysicsEnvironment* physEnv)
: SCA_EventManager(logicmgr, TOUCH_EVENTMGR),
m_physEnv(physEnv)
{
//notm_scene->addTouchCallback(STATIC_RESPONSE, KX_TouchEventManager::collisionResponse, this);
//m_scene->addTouchCallback(OBJECT_RESPONSE, KX_TouchEventManager::collisionResponse, this);
//m_scene->addTouchCallback(SENSOR_RESPONSE, KX_TouchEventManager::collisionResponse, this);
BGE: Cleaning up the BGE's physics code and removing KX_IPhysicsController and KX_BulletPhysicsController. Instead, we just use PHY_IPhysicsController, which removes a lot of duplicate code. This is a squashed commit of the following: BGE Physics Cleanup: Fix crashes with LibLoading and replication. Also fixing some memory leaks. BGE Physics Cleanup: Removing KX_IPhysicsController and KX_BulletPhysicsController. BGE Physics Cleanup: Moving the replication code outside of KX_BlenderBulletController and switching KX_ConvertPhysicsObjects to create a CcdPhysicsController instead of a KX_BlenderBulletController. BGE Physics Cleanup: Getting rid of an unsued KX_BulletPhysicsController.h include in KX_Scene.cpp. BGE Physics Cleanup: Removing unused KX_IPhysicsController and KX_BulletPhysicsController includes. BGE Physics Cleanup: Removing m_pPhysicsController1 and GetPhysicsController1() from KX_GameObject. BGE Physics Cleanup: Remove SetRigidBody() from KX_IPhysicsController and remove GetName() from CcdPhysicsController. BGE Physics Cleanup: Moving Add/RemoveCompoundChild() from KX_IPhysicsController to PHY_IPhysicsController. BGE Physics Cleanup: Removing GetLocalInertia() from KX_IPhysicsController. BGE Physics Cleanup: Making BlenderBulletCharacterController derive from PHY_ICharacter and removing CharacterWrapper from CcdPhysicsEnvironment.cpp. Also removing the character functions from KX_IPhysicsController. BGE Physics Cleanup: Removing GetOrientation(), SetOrientation(), SetPosition(), SetScaling(), and GetRadius() from KX_IPhysicsController. BGE Physics Cleanup: Removing GetReactionForce() since all implementations returned (0, 0, 0). The Python interface for KX_GameObject still has reaction force code, but it still also returns (0, 0, 0). This can probably be removed as well, but removing it can break scripts, so I'll leave it for now. BGE Physics Cleanup: Removing Get/SetLinVelocityMin() and Get/SetLinVelocityMax() from KX_IPhysicsController. BGE Physics Cleanup: Removing SetMargin(), RelativeTranslate(), and RelativeRotate() from KX_IPhysicsController. BGE Physics Cleanup: Using constant references for function arguments in PHY_IPhysicsController where appropriate. BGE Physics Cleanup: Removing ApplyImpulse() from KX_IPhysicsController. BGE Physics Cleanup: Removing ResolveCombinedVelocities() from KX_IPhysicsController. BGE Physics Cleanup: Accidently removed a return when cleaning up KX_GameObject::PyGetVelocity(). BGE Physics Cleanup: Remove GetLinearVelocity(), GetAngularVelocity() and GetVelocity() from KX_IPhysicsController. The corresponding PHY_IPhysicsController functions now also take Moto types instead of scalars to match the KX_IPhysicsController interface. BGE Physics Cleanup: Moving SuspendDynamics, RestoreDynamics, SetMass, GetMass, and SetTransform from KX_IPhysicsController to PHY_IPhysicsController. BGE Physics Cleanup: PHY_IPhysicsEnvironment and derived classes now use the same naming scheme as PHY_IController. BGE Physics Cleanup: PHY_IMotionState and derived classes now use the same naming convention as PHY_IController. BGE Phsyics Cleanup: Making PHY_IController and its derived classes follow a consistent naming scheme for member functions. They now all start with capital letters (e.g., setWorldOrientation becomes SetWorldOrientation). BGE Physics Cleanup: Getting rid of KX_GameObject::SuspendDynamics() and KX_GameObject::RestoreDynamics(). Instead, use the functions from the physics controller. BGE: Some first steps in trying to cleanup the KX_IPhysicsController mess. KX_GameObject now has a GetPhysicsController() and a GetPhysicsController1(). The former returns a PHY_IPhysicsController* while the latter returns a KX_IPhysicsController. The goal is to get everything using GetPhysicsController() instead of GetPhysicsController1().
2013-11-04 19:22:47 +00:00
m_physEnv->AddTouchCallback(PHY_OBJECT_RESPONSE, KX_TouchEventManager::newCollisionResponse, this);
m_physEnv->AddTouchCallback(PHY_SENSOR_RESPONSE, KX_TouchEventManager::newCollisionResponse, this);
m_physEnv->AddTouchCallback(PHY_BROADPH_RESPONSE, KX_TouchEventManager::newBroadphaseResponse, this);
2002-10-12 11:37:38 +00:00
}
bool KX_TouchEventManager::NewHandleCollision(void* object1, void* object2, const PHY_CollData *coll_data)
2002-10-12 11:37:38 +00:00
{
PHY_IPhysicsController* obj1 = static_cast<PHY_IPhysicsController*>(object1);
PHY_IPhysicsController* obj2 = static_cast<PHY_IPhysicsController*>(object2);
m_newCollisions.insert(std::pair<PHY_IPhysicsController*, PHY_IPhysicsController*>(obj1, obj2));
return false;
}
2002-10-12 11:37:38 +00:00
bool KX_TouchEventManager::newCollisionResponse(void *client_data,
void *object1,
void *object2,
const PHY_CollData *coll_data)
{
KX_TouchEventManager *touchmgr = (KX_TouchEventManager *) client_data;
touchmgr->NewHandleCollision(object1, object2, coll_data);
return false;
}
bool KX_TouchEventManager::newBroadphaseResponse(void *client_data,
void *object1,
void *object2,
const PHY_CollData *coll_data)
{
PHY_IPhysicsController* ctrl1 = static_cast<PHY_IPhysicsController*>(object1);
PHY_IPhysicsController* ctrl2 = static_cast<PHY_IPhysicsController*>(object2);
BGE: Cleaning up the BGE's physics code and removing KX_IPhysicsController and KX_BulletPhysicsController. Instead, we just use PHY_IPhysicsController, which removes a lot of duplicate code. This is a squashed commit of the following: BGE Physics Cleanup: Fix crashes with LibLoading and replication. Also fixing some memory leaks. BGE Physics Cleanup: Removing KX_IPhysicsController and KX_BulletPhysicsController. BGE Physics Cleanup: Moving the replication code outside of KX_BlenderBulletController and switching KX_ConvertPhysicsObjects to create a CcdPhysicsController instead of a KX_BlenderBulletController. BGE Physics Cleanup: Getting rid of an unsued KX_BulletPhysicsController.h include in KX_Scene.cpp. BGE Physics Cleanup: Removing unused KX_IPhysicsController and KX_BulletPhysicsController includes. BGE Physics Cleanup: Removing m_pPhysicsController1 and GetPhysicsController1() from KX_GameObject. BGE Physics Cleanup: Remove SetRigidBody() from KX_IPhysicsController and remove GetName() from CcdPhysicsController. BGE Physics Cleanup: Moving Add/RemoveCompoundChild() from KX_IPhysicsController to PHY_IPhysicsController. BGE Physics Cleanup: Removing GetLocalInertia() from KX_IPhysicsController. BGE Physics Cleanup: Making BlenderBulletCharacterController derive from PHY_ICharacter and removing CharacterWrapper from CcdPhysicsEnvironment.cpp. Also removing the character functions from KX_IPhysicsController. BGE Physics Cleanup: Removing GetOrientation(), SetOrientation(), SetPosition(), SetScaling(), and GetRadius() from KX_IPhysicsController. BGE Physics Cleanup: Removing GetReactionForce() since all implementations returned (0, 0, 0). The Python interface for KX_GameObject still has reaction force code, but it still also returns (0, 0, 0). This can probably be removed as well, but removing it can break scripts, so I'll leave it for now. BGE Physics Cleanup: Removing Get/SetLinVelocityMin() and Get/SetLinVelocityMax() from KX_IPhysicsController. BGE Physics Cleanup: Removing SetMargin(), RelativeTranslate(), and RelativeRotate() from KX_IPhysicsController. BGE Physics Cleanup: Using constant references for function arguments in PHY_IPhysicsController where appropriate. BGE Physics Cleanup: Removing ApplyImpulse() from KX_IPhysicsController. BGE Physics Cleanup: Removing ResolveCombinedVelocities() from KX_IPhysicsController. BGE Physics Cleanup: Accidently removed a return when cleaning up KX_GameObject::PyGetVelocity(). BGE Physics Cleanup: Remove GetLinearVelocity(), GetAngularVelocity() and GetVelocity() from KX_IPhysicsController. The corresponding PHY_IPhysicsController functions now also take Moto types instead of scalars to match the KX_IPhysicsController interface. BGE Physics Cleanup: Moving SuspendDynamics, RestoreDynamics, SetMass, GetMass, and SetTransform from KX_IPhysicsController to PHY_IPhysicsController. BGE Physics Cleanup: PHY_IPhysicsEnvironment and derived classes now use the same naming scheme as PHY_IController. BGE Physics Cleanup: PHY_IMotionState and derived classes now use the same naming convention as PHY_IController. BGE Phsyics Cleanup: Making PHY_IController and its derived classes follow a consistent naming scheme for member functions. They now all start with capital letters (e.g., setWorldOrientation becomes SetWorldOrientation). BGE Physics Cleanup: Getting rid of KX_GameObject::SuspendDynamics() and KX_GameObject::RestoreDynamics(). Instead, use the functions from the physics controller. BGE: Some first steps in trying to cleanup the KX_IPhysicsController mess. KX_GameObject now has a GetPhysicsController() and a GetPhysicsController1(). The former returns a PHY_IPhysicsController* while the latter returns a KX_IPhysicsController. The goal is to get everything using GetPhysicsController() instead of GetPhysicsController1().
2013-11-04 19:22:47 +00:00
KX_ClientObjectInfo *info1 = (ctrl1) ? static_cast<KX_ClientObjectInfo*>(ctrl1->GetNewClientInfo()) : NULL;
2014-06-17 12:04:20 +00:00
KX_ClientObjectInfo *info2 = (ctrl2) ? static_cast<KX_ClientObjectInfo*>(ctrl2->GetNewClientInfo()) : NULL;
// This call back should only be called for controllers of Near and Radar sensor
if (!info1)
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
2009-05-17 12:51:51 +00:00
return true;
// Get KX_GameObjects for callbacks
KX_GameObject* gobj1 = info1->m_gameobject;
KX_GameObject* gobj2 = (info2) ? info2->m_gameobject : NULL;
bool has_py_callbacks = false;
2014-06-17 11:52:04 +00:00
#ifdef WITH_PYTHON
// Consider callbacks for broadphase inclusion if it's a sensor object type
if (gobj1 && gobj2)
has_py_callbacks = gobj1->m_collisionCallbacks || gobj2->m_collisionCallbacks;
2014-06-17 11:52:04 +00:00
#else
(void)gobj1;
(void)gobj2;
#endif
switch (info1->m_type)
{
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
2009-05-17 12:51:51 +00:00
case KX_ClientObjectInfo::SENSOR:
if (info1->m_sensors.size() == 1)
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
2009-05-17 12:51:51 +00:00
{
// only one sensor for this type of object
KX_TouchSensor* touchsensor = static_cast<KX_TouchSensor*>(*info1->m_sensors.begin());
return touchsensor->BroadPhaseFilterCollision(object1, object2);
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
2009-05-17 12:51:51 +00:00
}
break;
case KX_ClientObjectInfo::OBSENSOR:
case KX_ClientObjectInfo::OBACTORSENSOR:
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
2009-05-17 12:51:51 +00:00
// this object may have multiple collision sensors,
// check is any of them is interested in this object
for (std::list<SCA_ISensor*>::iterator it = info1->m_sensors.begin();
it != info1->m_sensors.end();
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
2009-05-17 12:51:51 +00:00
++it)
{
if ((*it)->GetSensorType() == SCA_ISensor::ST_TOUCH)
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
2009-05-17 12:51:51 +00:00
{
KX_TouchSensor* touchsensor = static_cast<KX_TouchSensor*>(*it);
if (touchsensor->BroadPhaseSensorFilterCollision(object1, object2))
return true;
}
}
return has_py_callbacks;
2010-10-20 12:33:00 +00:00
// quiet the compiler
case KX_ClientObjectInfo::STATIC:
case KX_ClientObjectInfo::ACTOR:
case KX_ClientObjectInfo::RESERVED1:
/* do nothing*/
break;
}
return true;
}
void KX_TouchEventManager::RegisterSensor(SCA_ISensor* sensor)
{
2002-10-12 11:37:38 +00:00
KX_TouchSensor* touchsensor = static_cast<KX_TouchSensor*>(sensor);
BGE performance, 4th round: logic This commit extends the technique of dynamic linked list to the logic system to eliminate as much as possible temporaries, map lookup or full scan. The logic engine is now free of memory allocation, which is an important stability factor. The overhead of the logic system is reduced by a factor between 3 and 6 depending on the logic setup. This is the speed-up you can expect on a logic setup using simple bricks. Heavy bricks like python controllers and ray sensors will still take about the same time to execute so the speed up will be less important. The core of the logic engine has been much reworked but the functionality is still the same except for one thing: the priority system on the execution of controllers. The exact same remark applies to actuators but I'll explain for controllers only: Previously, it was possible, with the "executePriority" attribute to set a controller to run before any other controllers in the game. Other than that, the sequential execution of controllers, as defined in Blender was guaranteed by default. With the new system, the sequential execution of controllers is still guaranteed but only within the controllers of one object. the user can no longer set a controller to run before any other controllers in the game. The "executePriority" attribute controls the execution of controllers within one object. The priority is a small number starting from 0 for the first controller and incrementing for each controller. If this missing feature is a must, a special method can be implemented to set a controller to run before all other controllers. Other improvements: - Systematic use of reference in parameter passing to avoid unnecessary data copy - Use pre increment in iterator instead of post increment to avoid temporary allocation - Use const char* instead of STR_String whenever possible to avoid temporary allocation - Fix reference counting bugs (memory leak) - Fix a crash in certain cases of state switching and object deletion - Minor speed up in property sensor - Removal of objects during the game is a lot faster
2009-05-10 20:53:58 +00:00
if (m_sensors.AddBack(touchsensor))
// the sensor was effectively inserted, register it
touchsensor->RegisterSumo(this);
2002-10-12 11:37:38 +00:00
}
void KX_TouchEventManager::RemoveSensor(SCA_ISensor* sensor)
{
KX_TouchSensor* touchsensor = static_cast<KX_TouchSensor*>(sensor);
BGE performance, 4th round: logic This commit extends the technique of dynamic linked list to the logic system to eliminate as much as possible temporaries, map lookup or full scan. The logic engine is now free of memory allocation, which is an important stability factor. The overhead of the logic system is reduced by a factor between 3 and 6 depending on the logic setup. This is the speed-up you can expect on a logic setup using simple bricks. Heavy bricks like python controllers and ray sensors will still take about the same time to execute so the speed up will be less important. The core of the logic engine has been much reworked but the functionality is still the same except for one thing: the priority system on the execution of controllers. The exact same remark applies to actuators but I'll explain for controllers only: Previously, it was possible, with the "executePriority" attribute to set a controller to run before any other controllers in the game. Other than that, the sequential execution of controllers, as defined in Blender was guaranteed by default. With the new system, the sequential execution of controllers is still guaranteed but only within the controllers of one object. the user can no longer set a controller to run before any other controllers in the game. The "executePriority" attribute controls the execution of controllers within one object. The priority is a small number starting from 0 for the first controller and incrementing for each controller. If this missing feature is a must, a special method can be implemented to set a controller to run before all other controllers. Other improvements: - Systematic use of reference in parameter passing to avoid unnecessary data copy - Use pre increment in iterator instead of post increment to avoid temporary allocation - Use const char* instead of STR_String whenever possible to avoid temporary allocation - Fix reference counting bugs (memory leak) - Fix a crash in certain cases of state switching and object deletion - Minor speed up in property sensor - Removal of objects during the game is a lot faster
2009-05-10 20:53:58 +00:00
if (touchsensor->Delink())
// the sensor was effectively removed, unregister it
touchsensor->UnregisterSumo(this);
}
2002-10-12 11:37:38 +00:00
void KX_TouchEventManager::EndFrame()
{
BGE performance, 4th round: logic This commit extends the technique of dynamic linked list to the logic system to eliminate as much as possible temporaries, map lookup or full scan. The logic engine is now free of memory allocation, which is an important stability factor. The overhead of the logic system is reduced by a factor between 3 and 6 depending on the logic setup. This is the speed-up you can expect on a logic setup using simple bricks. Heavy bricks like python controllers and ray sensors will still take about the same time to execute so the speed up will be less important. The core of the logic engine has been much reworked but the functionality is still the same except for one thing: the priority system on the execution of controllers. The exact same remark applies to actuators but I'll explain for controllers only: Previously, it was possible, with the "executePriority" attribute to set a controller to run before any other controllers in the game. Other than that, the sequential execution of controllers, as defined in Blender was guaranteed by default. With the new system, the sequential execution of controllers is still guaranteed but only within the controllers of one object. the user can no longer set a controller to run before any other controllers in the game. The "executePriority" attribute controls the execution of controllers within one object. The priority is a small number starting from 0 for the first controller and incrementing for each controller. If this missing feature is a must, a special method can be implemented to set a controller to run before all other controllers. Other improvements: - Systematic use of reference in parameter passing to avoid unnecessary data copy - Use pre increment in iterator instead of post increment to avoid temporary allocation - Use const char* instead of STR_String whenever possible to avoid temporary allocation - Fix reference counting bugs (memory leak) - Fix a crash in certain cases of state switching and object deletion - Minor speed up in property sensor - Removal of objects during the game is a lot faster
2009-05-10 20:53:58 +00:00
SG_DList::iterator<KX_TouchSensor> it(m_sensors);
for (it.begin();!it.end();++it)
2002-10-12 11:37:38 +00:00
{
BGE performance, 4th round: logic This commit extends the technique of dynamic linked list to the logic system to eliminate as much as possible temporaries, map lookup or full scan. The logic engine is now free of memory allocation, which is an important stability factor. The overhead of the logic system is reduced by a factor between 3 and 6 depending on the logic setup. This is the speed-up you can expect on a logic setup using simple bricks. Heavy bricks like python controllers and ray sensors will still take about the same time to execute so the speed up will be less important. The core of the logic engine has been much reworked but the functionality is still the same except for one thing: the priority system on the execution of controllers. The exact same remark applies to actuators but I'll explain for controllers only: Previously, it was possible, with the "executePriority" attribute to set a controller to run before any other controllers in the game. Other than that, the sequential execution of controllers, as defined in Blender was guaranteed by default. With the new system, the sequential execution of controllers is still guaranteed but only within the controllers of one object. the user can no longer set a controller to run before any other controllers in the game. The "executePriority" attribute controls the execution of controllers within one object. The priority is a small number starting from 0 for the first controller and incrementing for each controller. If this missing feature is a must, a special method can be implemented to set a controller to run before all other controllers. Other improvements: - Systematic use of reference in parameter passing to avoid unnecessary data copy - Use pre increment in iterator instead of post increment to avoid temporary allocation - Use const char* instead of STR_String whenever possible to avoid temporary allocation - Fix reference counting bugs (memory leak) - Fix a crash in certain cases of state switching and object deletion - Minor speed up in property sensor - Removal of objects during the game is a lot faster
2009-05-10 20:53:58 +00:00
(*it)->EndFrame();
2002-10-12 11:37:38 +00:00
}
}
void KX_TouchEventManager::NextFrame()
2002-10-12 11:37:38 +00:00
{
BGE performance, 4th round: logic This commit extends the technique of dynamic linked list to the logic system to eliminate as much as possible temporaries, map lookup or full scan. The logic engine is now free of memory allocation, which is an important stability factor. The overhead of the logic system is reduced by a factor between 3 and 6 depending on the logic setup. This is the speed-up you can expect on a logic setup using simple bricks. Heavy bricks like python controllers and ray sensors will still take about the same time to execute so the speed up will be less important. The core of the logic engine has been much reworked but the functionality is still the same except for one thing: the priority system on the execution of controllers. The exact same remark applies to actuators but I'll explain for controllers only: Previously, it was possible, with the "executePriority" attribute to set a controller to run before any other controllers in the game. Other than that, the sequential execution of controllers, as defined in Blender was guaranteed by default. With the new system, the sequential execution of controllers is still guaranteed but only within the controllers of one object. the user can no longer set a controller to run before any other controllers in the game. The "executePriority" attribute controls the execution of controllers within one object. The priority is a small number starting from 0 for the first controller and incrementing for each controller. If this missing feature is a must, a special method can be implemented to set a controller to run before all other controllers. Other improvements: - Systematic use of reference in parameter passing to avoid unnecessary data copy - Use pre increment in iterator instead of post increment to avoid temporary allocation - Use const char* instead of STR_String whenever possible to avoid temporary allocation - Fix reference counting bugs (memory leak) - Fix a crash in certain cases of state switching and object deletion - Minor speed up in property sensor - Removal of objects during the game is a lot faster
2009-05-10 20:53:58 +00:00
SG_DList::iterator<KX_TouchSensor> it(m_sensors);
for (it.begin();!it.end();++it)
(*it)->SynchronizeTransform();
2002-10-12 11:37:38 +00:00
for (std::set<NewCollision>::iterator cit = m_newCollisions.begin(); cit != m_newCollisions.end(); ++cit)
{
// Controllers
PHY_IPhysicsController* ctrl1 = (*cit).first;
PHY_IPhysicsController* ctrl2 = (*cit).second;
// Sensor iterator
list<SCA_ISensor*>::iterator sit;
// First client info
BGE: Cleaning up the BGE's physics code and removing KX_IPhysicsController and KX_BulletPhysicsController. Instead, we just use PHY_IPhysicsController, which removes a lot of duplicate code. This is a squashed commit of the following: BGE Physics Cleanup: Fix crashes with LibLoading and replication. Also fixing some memory leaks. BGE Physics Cleanup: Removing KX_IPhysicsController and KX_BulletPhysicsController. BGE Physics Cleanup: Moving the replication code outside of KX_BlenderBulletController and switching KX_ConvertPhysicsObjects to create a CcdPhysicsController instead of a KX_BlenderBulletController. BGE Physics Cleanup: Getting rid of an unsued KX_BulletPhysicsController.h include in KX_Scene.cpp. BGE Physics Cleanup: Removing unused KX_IPhysicsController and KX_BulletPhysicsController includes. BGE Physics Cleanup: Removing m_pPhysicsController1 and GetPhysicsController1() from KX_GameObject. BGE Physics Cleanup: Remove SetRigidBody() from KX_IPhysicsController and remove GetName() from CcdPhysicsController. BGE Physics Cleanup: Moving Add/RemoveCompoundChild() from KX_IPhysicsController to PHY_IPhysicsController. BGE Physics Cleanup: Removing GetLocalInertia() from KX_IPhysicsController. BGE Physics Cleanup: Making BlenderBulletCharacterController derive from PHY_ICharacter and removing CharacterWrapper from CcdPhysicsEnvironment.cpp. Also removing the character functions from KX_IPhysicsController. BGE Physics Cleanup: Removing GetOrientation(), SetOrientation(), SetPosition(), SetScaling(), and GetRadius() from KX_IPhysicsController. BGE Physics Cleanup: Removing GetReactionForce() since all implementations returned (0, 0, 0). The Python interface for KX_GameObject still has reaction force code, but it still also returns (0, 0, 0). This can probably be removed as well, but removing it can break scripts, so I'll leave it for now. BGE Physics Cleanup: Removing Get/SetLinVelocityMin() and Get/SetLinVelocityMax() from KX_IPhysicsController. BGE Physics Cleanup: Removing SetMargin(), RelativeTranslate(), and RelativeRotate() from KX_IPhysicsController. BGE Physics Cleanup: Using constant references for function arguments in PHY_IPhysicsController where appropriate. BGE Physics Cleanup: Removing ApplyImpulse() from KX_IPhysicsController. BGE Physics Cleanup: Removing ResolveCombinedVelocities() from KX_IPhysicsController. BGE Physics Cleanup: Accidently removed a return when cleaning up KX_GameObject::PyGetVelocity(). BGE Physics Cleanup: Remove GetLinearVelocity(), GetAngularVelocity() and GetVelocity() from KX_IPhysicsController. The corresponding PHY_IPhysicsController functions now also take Moto types instead of scalars to match the KX_IPhysicsController interface. BGE Physics Cleanup: Moving SuspendDynamics, RestoreDynamics, SetMass, GetMass, and SetTransform from KX_IPhysicsController to PHY_IPhysicsController. BGE Physics Cleanup: PHY_IPhysicsEnvironment and derived classes now use the same naming scheme as PHY_IController. BGE Physics Cleanup: PHY_IMotionState and derived classes now use the same naming convention as PHY_IController. BGE Phsyics Cleanup: Making PHY_IController and its derived classes follow a consistent naming scheme for member functions. They now all start with capital letters (e.g., setWorldOrientation becomes SetWorldOrientation). BGE Physics Cleanup: Getting rid of KX_GameObject::SuspendDynamics() and KX_GameObject::RestoreDynamics(). Instead, use the functions from the physics controller. BGE: Some first steps in trying to cleanup the KX_IPhysicsController mess. KX_GameObject now has a GetPhysicsController() and a GetPhysicsController1(). The former returns a PHY_IPhysicsController* while the latter returns a KX_IPhysicsController. The goal is to get everything using GetPhysicsController() instead of GetPhysicsController1().
2013-11-04 19:22:47 +00:00
KX_ClientObjectInfo *client_info = static_cast<KX_ClientObjectInfo*>(ctrl1->GetNewClientInfo());
// First gameobject
KX_GameObject *kxObj1 = KX_GameObject::GetClientObject(client_info);
// Invoke sensor response for each object
if (client_info) {
for ( sit = client_info->m_sensors.begin(); sit != client_info->m_sensors.end(); ++sit) {
static_cast<KX_TouchSensor*>(*sit)->NewHandleCollision(ctrl1, ctrl2, NULL);
}
}
// Second client info
BGE: Cleaning up the BGE's physics code and removing KX_IPhysicsController and KX_BulletPhysicsController. Instead, we just use PHY_IPhysicsController, which removes a lot of duplicate code. This is a squashed commit of the following: BGE Physics Cleanup: Fix crashes with LibLoading and replication. Also fixing some memory leaks. BGE Physics Cleanup: Removing KX_IPhysicsController and KX_BulletPhysicsController. BGE Physics Cleanup: Moving the replication code outside of KX_BlenderBulletController and switching KX_ConvertPhysicsObjects to create a CcdPhysicsController instead of a KX_BlenderBulletController. BGE Physics Cleanup: Getting rid of an unsued KX_BulletPhysicsController.h include in KX_Scene.cpp. BGE Physics Cleanup: Removing unused KX_IPhysicsController and KX_BulletPhysicsController includes. BGE Physics Cleanup: Removing m_pPhysicsController1 and GetPhysicsController1() from KX_GameObject. BGE Physics Cleanup: Remove SetRigidBody() from KX_IPhysicsController and remove GetName() from CcdPhysicsController. BGE Physics Cleanup: Moving Add/RemoveCompoundChild() from KX_IPhysicsController to PHY_IPhysicsController. BGE Physics Cleanup: Removing GetLocalInertia() from KX_IPhysicsController. BGE Physics Cleanup: Making BlenderBulletCharacterController derive from PHY_ICharacter and removing CharacterWrapper from CcdPhysicsEnvironment.cpp. Also removing the character functions from KX_IPhysicsController. BGE Physics Cleanup: Removing GetOrientation(), SetOrientation(), SetPosition(), SetScaling(), and GetRadius() from KX_IPhysicsController. BGE Physics Cleanup: Removing GetReactionForce() since all implementations returned (0, 0, 0). The Python interface for KX_GameObject still has reaction force code, but it still also returns (0, 0, 0). This can probably be removed as well, but removing it can break scripts, so I'll leave it for now. BGE Physics Cleanup: Removing Get/SetLinVelocityMin() and Get/SetLinVelocityMax() from KX_IPhysicsController. BGE Physics Cleanup: Removing SetMargin(), RelativeTranslate(), and RelativeRotate() from KX_IPhysicsController. BGE Physics Cleanup: Using constant references for function arguments in PHY_IPhysicsController where appropriate. BGE Physics Cleanup: Removing ApplyImpulse() from KX_IPhysicsController. BGE Physics Cleanup: Removing ResolveCombinedVelocities() from KX_IPhysicsController. BGE Physics Cleanup: Accidently removed a return when cleaning up KX_GameObject::PyGetVelocity(). BGE Physics Cleanup: Remove GetLinearVelocity(), GetAngularVelocity() and GetVelocity() from KX_IPhysicsController. The corresponding PHY_IPhysicsController functions now also take Moto types instead of scalars to match the KX_IPhysicsController interface. BGE Physics Cleanup: Moving SuspendDynamics, RestoreDynamics, SetMass, GetMass, and SetTransform from KX_IPhysicsController to PHY_IPhysicsController. BGE Physics Cleanup: PHY_IPhysicsEnvironment and derived classes now use the same naming scheme as PHY_IController. BGE Physics Cleanup: PHY_IMotionState and derived classes now use the same naming convention as PHY_IController. BGE Phsyics Cleanup: Making PHY_IController and its derived classes follow a consistent naming scheme for member functions. They now all start with capital letters (e.g., setWorldOrientation becomes SetWorldOrientation). BGE Physics Cleanup: Getting rid of KX_GameObject::SuspendDynamics() and KX_GameObject::RestoreDynamics(). Instead, use the functions from the physics controller. BGE: Some first steps in trying to cleanup the KX_IPhysicsController mess. KX_GameObject now has a GetPhysicsController() and a GetPhysicsController1(). The former returns a PHY_IPhysicsController* while the latter returns a KX_IPhysicsController. The goal is to get everything using GetPhysicsController() instead of GetPhysicsController1().
2013-11-04 19:22:47 +00:00
client_info = static_cast<KX_ClientObjectInfo *>(ctrl2->GetNewClientInfo());
// Second gameobject
KX_GameObject *kxObj2 = KX_GameObject::GetClientObject(client_info);
if (client_info) {
for ( sit = client_info->m_sensors.begin(); sit != client_info->m_sensors.end(); ++sit) {
static_cast<KX_TouchSensor*>(*sit)->NewHandleCollision(ctrl2, ctrl1, NULL);
}
}
// Run python callbacks
kxObj1->RunCollisionCallbacks(kxObj2);
kxObj2->RunCollisionCallbacks(kxObj1);
}
m_newCollisions.clear();
BGE performance, 4th round: logic This commit extends the technique of dynamic linked list to the logic system to eliminate as much as possible temporaries, map lookup or full scan. The logic engine is now free of memory allocation, which is an important stability factor. The overhead of the logic system is reduced by a factor between 3 and 6 depending on the logic setup. This is the speed-up you can expect on a logic setup using simple bricks. Heavy bricks like python controllers and ray sensors will still take about the same time to execute so the speed up will be less important. The core of the logic engine has been much reworked but the functionality is still the same except for one thing: the priority system on the execution of controllers. The exact same remark applies to actuators but I'll explain for controllers only: Previously, it was possible, with the "executePriority" attribute to set a controller to run before any other controllers in the game. Other than that, the sequential execution of controllers, as defined in Blender was guaranteed by default. With the new system, the sequential execution of controllers is still guaranteed but only within the controllers of one object. the user can no longer set a controller to run before any other controllers in the game. The "executePriority" attribute controls the execution of controllers within one object. The priority is a small number starting from 0 for the first controller and incrementing for each controller. If this missing feature is a must, a special method can be implemented to set a controller to run before all other controllers. Other improvements: - Systematic use of reference in parameter passing to avoid unnecessary data copy - Use pre increment in iterator instead of post increment to avoid temporary allocation - Use const char* instead of STR_String whenever possible to avoid temporary allocation - Fix reference counting bugs (memory leak) - Fix a crash in certain cases of state switching and object deletion - Minor speed up in property sensor - Removal of objects during the game is a lot faster
2009-05-10 20:53:58 +00:00
for (it.begin();!it.end();++it)
(*it)->Activate(m_logicmgr);
2002-10-12 11:37:38 +00:00
}