blender/source/gameengine/Ketsji/KX_Scene.cpp

1847 lines
50 KiB
C++
Raw Normal View History

2002-10-12 11:37:38 +00:00
/*
* $Id$
*
* ***** 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,
* Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*
* 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
* Ketsji scene. Holds references to all scene data.
*/
#ifdef WIN32
#pragma warning (disable : 4786)
#endif //WIN32
#include "KX_Scene.h"
2005-01-23 01:36:29 +00:00
#include "MT_assert.h"
#include "SND_Scene.h"
2002-10-12 11:37:38 +00:00
#include "KX_KetsjiEngine.h"
#include "KX_BlenderMaterial.h"
2002-10-12 11:37:38 +00:00
#include "RAS_IPolygonMaterial.h"
#include "ListValue.h"
#include "SCA_LogicManager.h"
#include "SCA_TimeEventManager.h"
#include "SCA_AlwaysEventManager.h"
#include "SCA_RandomEventManager.h"
#include "KX_RayEventManager.h"
#include "KX_TouchEventManager.h"
#include "SCA_KeyboardManager.h"
#include "SCA_MouseManager.h"
#include "SCA_PropertyEventManager.h"
BGE logic update: new servo control motion actuator, new distance constraint actuator, new orientation constraint actuator, new actuator sensor. General ======= - Removal of Damp option in motion actuator (replaced by Servo control motion). - No PyDoc at present, will be added soon. Generalization of the Lvl option ================================ A sensor with the Lvl option selected will always produce an event at the start of the game or when entering a state or at object creation. The event will be positive or negative depending of the sensor condition. A negative pulse makes sense when used with a NAND controller: it will be converted into an actuator activation. Servo control motion ==================== A new variant of the motion actuator allows to control speed with force. The control if of type "PID" (Propotional, Integral, Derivate): the force is automatically adapted to achieve the target speed. All the parameters of the servo controller are configurable. The result is a great variety of motion style: anysotropic friction, flying, sliding, pseudo Dloc... This actuator should be used in preference to Dloc and LinV as it produces more fluid movements and avoids the collision problem with Dloc. LinV : target speed as (X,Y,Z) vector in local or world coordinates (mostly useful in local coordinates). Limit: the force can be limited along each axis (in the same coordinates of LinV). No limitation means that the force will grow as large as necessary to achieve the target speed along that axis. Set a max value to limit the accelaration along an axis (slow start) and set a min value (negative) to limit the brake force. P: Proportional coefficient of servo controller, don't set directly unless you know what you're doing. I: Integral coefficient of servo controller. Use low value (<0.1) for slow reaction (sliding), high values (>0.5) for hard control. The P coefficient will be automatically set to 60 times the I coefficient (a reasonable value). D: Derivate coefficient. Leave to 0 unless you know what you're doing. High values create instability. Notes: - This actuator works perfectly in zero friction environment: the PID controller will simulate friction by applying force as needed. - This actuator is compatible with simple Drot motion actuator but not with LinV and Dloc motion. - (0,0,0) is a valid target speed. - All parameters are accessible through Python. Distance constraint actuator ============================ A new variant of the constraint actuator allows to set the distance and orientation relative to a surface. The controller uses a ray to detect the surface (or any object) and adapt the distance and orientation parallel to the surface. Damp: Time constant (in nb of frames) of distance and orientation control. Dist: Select to enable distance control and set target distance. The object will be position at the given distance of surface along the ray direction. Direction: chose a local axis as the ray direction. Range: length of ray. Objecgt within this distance will be detected. N : Select to enable orientation control. The actuator will change the orientation and the location of the object so that it is parallel to the surface at the vertical of the point of contact of the ray. M/P : Select to enable material detection. Default is property detection. Property/Material: name of property/material that the target of ray must have to be detected. If not set, property/ material filter is disabled and any collisioning object within range will be detected. PER : Select to enable persistent operation. Normally the actuator disables itself automatically if the ray does not reach a valid target. time : Maximum activation time of actuator. 0 : unlimited. >0: number of frames before automatic deactivation. rotDamp: Time constant (in nb of frame) of orientation control. 0 : use Damp parameter. >0: use a different time constant for orientation. Notes: - If neither N nor Dist options are set, the actuator does not change the position and orientation of the object; it works as a ray sensor. - The ray has no "X-ray" capability: if the first object hit does not have the required property/material, it returns no hit and the actuator disables itself unless PER option is enabled. - This actuator changes the position and orientation but not the speed of the object. This has an important implication in a gravity environment: the gravity will cause the speed to increase although the object seems to stay still (it is repositioned at each frame). The gravity must be compensated in one way or another. the new servo control motion actuator is the simplest way: set the target speed along the ray axis to 0 and the servo control will automatically compensate the gravity. - This actuator changes the orientation of the object and will conflict with Drot motion unless it is placed BEFORE the Drot motion actuator (the order of actuator is important) - All parameters are accessible through Python. Orientation constraint ====================== A new variant of the constraint actuator allows to align an object axis along a global direction. Damp : Time constant (in nb of frames) of orientation control. X,Y,Z: Global coordinates of reference direction. time : Maximum activation time of actuator. 0 : unlimited. >0: number of frames before automatic deactivation. Notes: - (X,Y,Z) = (0,0,0) is not a valid direction - This actuator changes the orientation of the object and will conflict with Drot motion unless it is placed BEFORE the Drot motion actuator (the order of actuator is important). - This actuator doesn't change the location and speed. It is compatible with gravity. - All parameters are accessible through Python. Actuator sensor =============== This sensor detects the activation and deactivation of actuators of the same object. The sensor generates a positive pulse when the corresponding sensor is activated and a negative pulse when it is deactivated (the contrary if the Inv option is selected). This is mostly useful to chain actions and to detect the loss of contact of the distance motion actuator. Notes: - Actuators are disabled at the start of the game; if you want to detect the On-Off transition of an actuator after it has been activated at least once, unselect the Lvl and Inv options and use a NAND controller. - Some actuators deactivates themselves immediately after being activated. The sensor detects this situation as an On-Off transition. - The actuator name can be set through Python.
2008-07-04 08:14:50 +00:00
#include "SCA_ActuatorEventManager.h"
2002-10-12 11:37:38 +00:00
#include "KX_Camera.h"
2005-01-23 01:36:29 +00:00
#include "SCA_JoystickManager.h"
2002-10-12 11:37:38 +00:00
#include "RAS_MeshObject.h"
#include "BL_SkinMeshObject.h"
2002-10-12 11:37:38 +00:00
#include "RAS_IRasterizer.h"
#include "RAS_BucketManager.h"
#include "FloatValue.h"
#include "SCA_IController.h"
#include "SCA_IActuator.h"
#include "SG_Node.h"
#include "SYS_System.h"
#include "SG_Controller.h"
#include "SG_IObject.h"
#include "SG_Tree.h"
BGE patch: DUPLIGROUP option supported in BGE. Blender duplicates groups in the 3D view at the location of objects having the DUPLIGROUP option set. This feature is now supported in the BGE: the groups will be instantiated as in the 3D view when the scene is converted. This is useful to populate a scene with multiple enemies without having to actually duplicate the objects in the blend file. Notes: * The BGE applies the same criteria to instantiate the group as Blender to display them: if you see the group in the 3D view, it will be instantiated in the BGE. * Groups are instantiated as if the object having the DUPLIGROUP option (usually an empty) executed an AddObject actuator on the top objects of the group (objects without parent). * As a result, only intra-group parent relationship is supported: the BGE will not instantiate objects that have parents outside the group. * Intra-group logic bricks connections are preserved between the duplicated objects, even between the top objects of the group. * For best result, the state engine of the objects in the group should be self-contained: logic bricks should only have intra-group connections. Use messages to communicate with state engines outside the group. * Nested groups are supported: if one or more objects in the group have the DUPLIGROUP option set, the corresponding groups will be instantiated at the corresponding position and orientation. * Nested groups are instantiated as separate groups, not as one big group. * Linked groups are supported as well as groups containing objects from the active layers. * There is a difference in the way Blender displays the groups in the 3D view and how BGE instantiates them: Blender does not take into account the parent relationship in the group and displays the objects as if they were all children of the object having the DUPLIGROUP option. That's correct for the top objects of the group but not for the children. Hence the orientation of the children objects may be different in the BGE. * An AddGroup actuator will be added in a future release.
2008-07-15 20:05:23 +00:00
#include "DNA_group_types.h"
#include "DNA_scene_types.h"
BGE patch: DUPLIGROUP option supported in BGE. Blender duplicates groups in the 3D view at the location of objects having the DUPLIGROUP option set. This feature is now supported in the BGE: the groups will be instantiated as in the 3D view when the scene is converted. This is useful to populate a scene with multiple enemies without having to actually duplicate the objects in the blend file. Notes: * The BGE applies the same criteria to instantiate the group as Blender to display them: if you see the group in the 3D view, it will be instantiated in the BGE. * Groups are instantiated as if the object having the DUPLIGROUP option (usually an empty) executed an AddObject actuator on the top objects of the group (objects without parent). * As a result, only intra-group parent relationship is supported: the BGE will not instantiate objects that have parents outside the group. * Intra-group logic bricks connections are preserved between the duplicated objects, even between the top objects of the group. * For best result, the state engine of the objects in the group should be self-contained: logic bricks should only have intra-group connections. Use messages to communicate with state engines outside the group. * Nested groups are supported: if one or more objects in the group have the DUPLIGROUP option set, the corresponding groups will be instantiated at the corresponding position and orientation. * Nested groups are instantiated as separate groups, not as one big group. * Linked groups are supported as well as groups containing objects from the active layers. * There is a difference in the way Blender displays the groups in the 3D view and how BGE instantiates them: Blender does not take into account the parent relationship in the group and displays the objects as if they were all children of the object having the DUPLIGROUP option. That's correct for the top objects of the group but not for the children. Hence the orientation of the children objects may be different in the BGE. * An AddGroup actuator will be added in a future release.
2008-07-15 20:05:23 +00:00
#include "BKE_anim.h"
2002-10-12 11:37:38 +00:00
#include "KX_SG_NodeRelationships.h"
#include "KX_NetworkEventManager.h"
#include "NG_NetworkScene.h"
#include "PHY_IPhysicsEnvironment.h"
#include "KX_IPhysicsController.h"
#include "PHY_IGraphicController.h"
#include "KX_BlenderSceneConverter.h"
#include "KX_MotionState.h"
2002-10-12 11:37:38 +00:00
BGE: Support mesh modifiers in the game engine. Realtime modifiers applied on mesh objects will be supported in the game engine with the following limitations: - Only real time modifiers are supported (basically all of them!) - Virtual modifiers resulting from parenting are not supported: armature, curve, lattice. You can still use these modifiers (armature is really not recommended) but in non parent mode. The BGE has it's own parenting capability for armature. - Modifiers are computed on the host (using blender modifier stack). - Modifiers are statically evaluated: any possible time dependency in the modifiers is not supported (don't know enough about modifiers to be more specific). - Modifiers are reevaluated if the underlying mesh is deformed due to shape action or armature action. Beware that this is very CPU intensive; modifiers should really be used for static objects only. - Physics is still based on the original mesh: if you have a mirror modifier, the physic shape will be limited to one half of the resulting object. Therefore, the modifiers should preferably be used on graphic objects. - Scripts have no access to the modified mesh. - Modifiers that are based on objects interaction (boolean,..) will not be dependent on the objects position in the GE. What you see in the 3D view is what you get in the GE regardless on the object position, velocity, etc. Besides that, the feature is compatible with all the BGE features that affect meshes: armature action, shape action, relace mesh, VideoTexture, add object, dupligroup. Known problems: - This feature is a bit hacky: the BGE uses the derived mesh draw functions to display the object. This drawing method is a bit slow and is not 100% compatible with the BGE. There may be some problems in multi-texture mode: the multi-texture coordinates are not sent to the GPU. Texface and GLSL on the other hand should be fully supported. - Culling is still based on the extend of the original mesh. If you have a modifer that extends the size of the mesh, the object may disappear while still in the view frustrum. - Derived mesh is not shared between replicas. The derived mesh is allocated and computed for each object with modifiers, regardless if they are static replicas. - Display list are not created on objects with modifiers. I should be able to fix the above problems before release. However, the feature is already useful for game development. Once you are ready to release the game, you can apply the modifiers to get back display list support and mesh sharing capability. MSVC, scons, Cmake, makefile updated. Enjoy /benoit
2009-04-21 11:01:09 +00:00
#include "BL_ModifierDeformer.h"
#include "BL_ShapeDeformer.h"
Patch: [ #2439 ] Makes objects react properly to deformations after a mesh replacement call. from brian hayward (bthayward) Detailed description: Currently, when an armature deformed object's mesh is replaced by the ReplaceMesh actuator, the new mesh fails to deform to the armature's movement. My patch fixes this by properly replacing the deform controller along with the mesh (when appropriete). For instance, if one had an animated character using any of the standard deformation techniques (armature, ipo, RVK, or AVK), that character's mesh would currently be prevented from changing mid-game. It could be replaced, but the new mesh would lack the controller which tells it how to deform. If one wanted to dynamiclly add a hat on top of the character's head, it would require storing a secondary prebuilt character (mesh, armature, logic, ect...) on another layer FOR EACH HAT the character could possibly wear, then swapping out the whole character when the hat change was desired. So if you had 4 possible hat/character combos, you would have 4 character meshes, 4 armatures, 4 sets of logic, and so on. I find this lack of flexibility to be unresonable. With my patch, one could accomplish the same thing mearly by making one version of the character in the main layer, and adding an invisible object atop the character's head (which is parented to the head bone). Then whenever it becomes desirable, one can replace the invisible object's mesh with the desirable hat's mesh, then make it visible. With my patch, the hat object would then continue to deform to the character's head regardless of which hat was currently being worn. *note 1* for armature/mesh deformations, the new mesh must have properly assigned vertex groups which match one or more of the bones of the target armature before the replaceMesh call is made. Otherwise the vertices won't react to the armature because they won't know how. (not sure if vertices can be scripted to change groups after the game has started) *note 2* The added processing time involved with replacing the object's deform controller is negligible.
2005-04-18 11:44:21 +00:00
#include "BL_DeformableGameObject.h"
// to get USE_BULLET!
#include "KX_ConvertPhysicsObject.h"
#ifdef USE_BULLET
#include "CcdPhysicsEnvironment.h"
#include "CcdPhysicsController.h"
#endif
2002-10-12 11:37:38 +00:00
#include "KX_Light.h"
2002-10-12 11:37:38 +00:00
void* KX_SceneReplicationFunc(SG_IObject* node,void* gameobj,void* scene)
{
KX_GameObject* replica = ((KX_Scene*)scene)->AddNodeReplicaObject(node,(KX_GameObject*)gameobj);
if(replica)
replica->Release();
2002-10-12 11:37:38 +00:00
return (void*)replica;
}
void* KX_SceneDestructionFunc(SG_IObject* node,void* gameobj,void* scene)
{
((KX_Scene*)scene)->RemoveNodeDestructObject(node,(KX_GameObject*)gameobj);
return NULL;
};
bool KX_Scene::KX_ScenegraphUpdateFunc(SG_IObject* node,void* gameobj,void* scene)
{
return ((SG_Node*)node)->Schedule(((KX_Scene*)scene)->m_sghead);
}
bool KX_Scene::KX_ScenegraphRescheduleFunc(SG_IObject* node,void* gameobj,void* scene)
{
return ((SG_Node*)node)->Reschedule(((KX_Scene*)scene)->m_sghead);
}
SG_Callbacks KX_Scene::m_callbacks = SG_Callbacks(
KX_SceneReplicationFunc,
KX_SceneDestructionFunc,
KX_GameObject::UpdateTransformFunc,
KX_Scene::KX_ScenegraphUpdateFunc,
KX_Scene::KX_ScenegraphRescheduleFunc);
2002-10-12 11:37:38 +00:00
// temporarily var until there is a button in the userinterface
// (defined in KX_PythonInit.cpp)
extern bool gUseVisibilityTemp;
KX_Scene::KX_Scene(class SCA_IInputDevice* keyboarddevice,
class SCA_IInputDevice* mousedevice,
class NG_NetworkDeviceInterface *ndi,
class SND_IAudioDevice* adi,
const STR_String& sceneName,
Scene *scene):
2004-06-07 11:03:12 +00:00
PyObjectPlus(&KX_Scene::Type),
2002-10-12 11:37:38 +00:00
m_keyboardmgr(NULL),
m_mousemgr(NULL),
m_sceneConverter(NULL),
m_physicsEnvironment(0),
2002-10-12 11:37:38 +00:00
m_sceneName(sceneName),
m_adi(adi),
2002-10-12 11:37:38 +00:00
m_networkDeviceInterface(ndi),
m_active_camera(NULL),
m_ueberExecutionPriority(0),
m_blenderScene(scene)
2002-10-12 11:37:38 +00:00
{
m_suspendedtime = 0.0;
m_suspendeddelta = 0.0;
2002-10-12 11:37:38 +00:00
m_dbvt_culling = false;
m_dbvt_occlusion_res = 0;
2002-10-12 11:37:38 +00:00
m_activity_culling = false;
m_suspend = false;
m_isclearingZbuffer = true;
m_tempObjectList = new CListValue();
m_objectlist = new CListValue();
m_parentlist = new CListValue();
m_lightlist= new CListValue();
m_inactivelist = new CListValue();
2002-10-12 11:37:38 +00:00
m_euthanasyobjects = new CListValue();
m_logicmgr = new SCA_LogicManager();
m_timemgr = new SCA_TimeEventManager(m_logicmgr);
m_keyboardmgr = new SCA_KeyboardManager(m_logicmgr,keyboarddevice);
m_mousemgr = new SCA_MouseManager(m_logicmgr,mousedevice);
SCA_AlwaysEventManager* alwaysmgr = new SCA_AlwaysEventManager(m_logicmgr);
SCA_PropertyEventManager* propmgr = new SCA_PropertyEventManager(m_logicmgr);
BGE logic update: new servo control motion actuator, new distance constraint actuator, new orientation constraint actuator, new actuator sensor. General ======= - Removal of Damp option in motion actuator (replaced by Servo control motion). - No PyDoc at present, will be added soon. Generalization of the Lvl option ================================ A sensor with the Lvl option selected will always produce an event at the start of the game or when entering a state or at object creation. The event will be positive or negative depending of the sensor condition. A negative pulse makes sense when used with a NAND controller: it will be converted into an actuator activation. Servo control motion ==================== A new variant of the motion actuator allows to control speed with force. The control if of type "PID" (Propotional, Integral, Derivate): the force is automatically adapted to achieve the target speed. All the parameters of the servo controller are configurable. The result is a great variety of motion style: anysotropic friction, flying, sliding, pseudo Dloc... This actuator should be used in preference to Dloc and LinV as it produces more fluid movements and avoids the collision problem with Dloc. LinV : target speed as (X,Y,Z) vector in local or world coordinates (mostly useful in local coordinates). Limit: the force can be limited along each axis (in the same coordinates of LinV). No limitation means that the force will grow as large as necessary to achieve the target speed along that axis. Set a max value to limit the accelaration along an axis (slow start) and set a min value (negative) to limit the brake force. P: Proportional coefficient of servo controller, don't set directly unless you know what you're doing. I: Integral coefficient of servo controller. Use low value (<0.1) for slow reaction (sliding), high values (>0.5) for hard control. The P coefficient will be automatically set to 60 times the I coefficient (a reasonable value). D: Derivate coefficient. Leave to 0 unless you know what you're doing. High values create instability. Notes: - This actuator works perfectly in zero friction environment: the PID controller will simulate friction by applying force as needed. - This actuator is compatible with simple Drot motion actuator but not with LinV and Dloc motion. - (0,0,0) is a valid target speed. - All parameters are accessible through Python. Distance constraint actuator ============================ A new variant of the constraint actuator allows to set the distance and orientation relative to a surface. The controller uses a ray to detect the surface (or any object) and adapt the distance and orientation parallel to the surface. Damp: Time constant (in nb of frames) of distance and orientation control. Dist: Select to enable distance control and set target distance. The object will be position at the given distance of surface along the ray direction. Direction: chose a local axis as the ray direction. Range: length of ray. Objecgt within this distance will be detected. N : Select to enable orientation control. The actuator will change the orientation and the location of the object so that it is parallel to the surface at the vertical of the point of contact of the ray. M/P : Select to enable material detection. Default is property detection. Property/Material: name of property/material that the target of ray must have to be detected. If not set, property/ material filter is disabled and any collisioning object within range will be detected. PER : Select to enable persistent operation. Normally the actuator disables itself automatically if the ray does not reach a valid target. time : Maximum activation time of actuator. 0 : unlimited. >0: number of frames before automatic deactivation. rotDamp: Time constant (in nb of frame) of orientation control. 0 : use Damp parameter. >0: use a different time constant for orientation. Notes: - If neither N nor Dist options are set, the actuator does not change the position and orientation of the object; it works as a ray sensor. - The ray has no "X-ray" capability: if the first object hit does not have the required property/material, it returns no hit and the actuator disables itself unless PER option is enabled. - This actuator changes the position and orientation but not the speed of the object. This has an important implication in a gravity environment: the gravity will cause the speed to increase although the object seems to stay still (it is repositioned at each frame). The gravity must be compensated in one way or another. the new servo control motion actuator is the simplest way: set the target speed along the ray axis to 0 and the servo control will automatically compensate the gravity. - This actuator changes the orientation of the object and will conflict with Drot motion unless it is placed BEFORE the Drot motion actuator (the order of actuator is important) - All parameters are accessible through Python. Orientation constraint ====================== A new variant of the constraint actuator allows to align an object axis along a global direction. Damp : Time constant (in nb of frames) of orientation control. X,Y,Z: Global coordinates of reference direction. time : Maximum activation time of actuator. 0 : unlimited. >0: number of frames before automatic deactivation. Notes: - (X,Y,Z) = (0,0,0) is not a valid direction - This actuator changes the orientation of the object and will conflict with Drot motion unless it is placed BEFORE the Drot motion actuator (the order of actuator is important). - This actuator doesn't change the location and speed. It is compatible with gravity. - All parameters are accessible through Python. Actuator sensor =============== This sensor detects the activation and deactivation of actuators of the same object. The sensor generates a positive pulse when the corresponding sensor is activated and a negative pulse when it is deactivated (the contrary if the Inv option is selected). This is mostly useful to chain actions and to detect the loss of contact of the distance motion actuator. Notes: - Actuators are disabled at the start of the game; if you want to detect the On-Off transition of an actuator after it has been activated at least once, unselect the Lvl and Inv options and use a NAND controller. - Some actuators deactivates themselves immediately after being activated. The sensor detects this situation as an On-Off transition. - The actuator name can be set through Python.
2008-07-04 08:14:50 +00:00
SCA_ActuatorEventManager* actmgr = new SCA_ActuatorEventManager(m_logicmgr);
2002-10-12 11:37:38 +00:00
SCA_RandomEventManager* rndmgr = new SCA_RandomEventManager(m_logicmgr);
KX_RayEventManager* raymgr = new KX_RayEventManager(m_logicmgr);
KX_NetworkEventManager* netmgr = new KX_NetworkEventManager(m_logicmgr, ndi);
2005-01-23 01:36:29 +00:00
2002-10-12 11:37:38 +00:00
m_logicmgr->RegisterEventManager(alwaysmgr);
m_logicmgr->RegisterEventManager(propmgr);
BGE logic update: new servo control motion actuator, new distance constraint actuator, new orientation constraint actuator, new actuator sensor. General ======= - Removal of Damp option in motion actuator (replaced by Servo control motion). - No PyDoc at present, will be added soon. Generalization of the Lvl option ================================ A sensor with the Lvl option selected will always produce an event at the start of the game or when entering a state or at object creation. The event will be positive or negative depending of the sensor condition. A negative pulse makes sense when used with a NAND controller: it will be converted into an actuator activation. Servo control motion ==================== A new variant of the motion actuator allows to control speed with force. The control if of type "PID" (Propotional, Integral, Derivate): the force is automatically adapted to achieve the target speed. All the parameters of the servo controller are configurable. The result is a great variety of motion style: anysotropic friction, flying, sliding, pseudo Dloc... This actuator should be used in preference to Dloc and LinV as it produces more fluid movements and avoids the collision problem with Dloc. LinV : target speed as (X,Y,Z) vector in local or world coordinates (mostly useful in local coordinates). Limit: the force can be limited along each axis (in the same coordinates of LinV). No limitation means that the force will grow as large as necessary to achieve the target speed along that axis. Set a max value to limit the accelaration along an axis (slow start) and set a min value (negative) to limit the brake force. P: Proportional coefficient of servo controller, don't set directly unless you know what you're doing. I: Integral coefficient of servo controller. Use low value (<0.1) for slow reaction (sliding), high values (>0.5) for hard control. The P coefficient will be automatically set to 60 times the I coefficient (a reasonable value). D: Derivate coefficient. Leave to 0 unless you know what you're doing. High values create instability. Notes: - This actuator works perfectly in zero friction environment: the PID controller will simulate friction by applying force as needed. - This actuator is compatible with simple Drot motion actuator but not with LinV and Dloc motion. - (0,0,0) is a valid target speed. - All parameters are accessible through Python. Distance constraint actuator ============================ A new variant of the constraint actuator allows to set the distance and orientation relative to a surface. The controller uses a ray to detect the surface (or any object) and adapt the distance and orientation parallel to the surface. Damp: Time constant (in nb of frames) of distance and orientation control. Dist: Select to enable distance control and set target distance. The object will be position at the given distance of surface along the ray direction. Direction: chose a local axis as the ray direction. Range: length of ray. Objecgt within this distance will be detected. N : Select to enable orientation control. The actuator will change the orientation and the location of the object so that it is parallel to the surface at the vertical of the point of contact of the ray. M/P : Select to enable material detection. Default is property detection. Property/Material: name of property/material that the target of ray must have to be detected. If not set, property/ material filter is disabled and any collisioning object within range will be detected. PER : Select to enable persistent operation. Normally the actuator disables itself automatically if the ray does not reach a valid target. time : Maximum activation time of actuator. 0 : unlimited. >0: number of frames before automatic deactivation. rotDamp: Time constant (in nb of frame) of orientation control. 0 : use Damp parameter. >0: use a different time constant for orientation. Notes: - If neither N nor Dist options are set, the actuator does not change the position and orientation of the object; it works as a ray sensor. - The ray has no "X-ray" capability: if the first object hit does not have the required property/material, it returns no hit and the actuator disables itself unless PER option is enabled. - This actuator changes the position and orientation but not the speed of the object. This has an important implication in a gravity environment: the gravity will cause the speed to increase although the object seems to stay still (it is repositioned at each frame). The gravity must be compensated in one way or another. the new servo control motion actuator is the simplest way: set the target speed along the ray axis to 0 and the servo control will automatically compensate the gravity. - This actuator changes the orientation of the object and will conflict with Drot motion unless it is placed BEFORE the Drot motion actuator (the order of actuator is important) - All parameters are accessible through Python. Orientation constraint ====================== A new variant of the constraint actuator allows to align an object axis along a global direction. Damp : Time constant (in nb of frames) of orientation control. X,Y,Z: Global coordinates of reference direction. time : Maximum activation time of actuator. 0 : unlimited. >0: number of frames before automatic deactivation. Notes: - (X,Y,Z) = (0,0,0) is not a valid direction - This actuator changes the orientation of the object and will conflict with Drot motion unless it is placed BEFORE the Drot motion actuator (the order of actuator is important). - This actuator doesn't change the location and speed. It is compatible with gravity. - All parameters are accessible through Python. Actuator sensor =============== This sensor detects the activation and deactivation of actuators of the same object. The sensor generates a positive pulse when the corresponding sensor is activated and a negative pulse when it is deactivated (the contrary if the Inv option is selected). This is mostly useful to chain actions and to detect the loss of contact of the distance motion actuator. Notes: - Actuators are disabled at the start of the game; if you want to detect the On-Off transition of an actuator after it has been activated at least once, unselect the Lvl and Inv options and use a NAND controller. - Some actuators deactivates themselves immediately after being activated. The sensor detects this situation as an On-Off transition. - The actuator name can be set through Python.
2008-07-04 08:14:50 +00:00
m_logicmgr->RegisterEventManager(actmgr);
2002-10-12 11:37:38 +00:00
m_logicmgr->RegisterEventManager(m_keyboardmgr);
m_logicmgr->RegisterEventManager(m_mousemgr);
m_logicmgr->RegisterEventManager(m_timemgr);
m_logicmgr->RegisterEventManager(rndmgr);
m_logicmgr->RegisterEventManager(raymgr);
m_logicmgr->RegisterEventManager(netmgr);
SYS_SystemHandle hSystem = SYS_GetSystem();
bool nojoystick= SYS_GetCommandLineInt(hSystem,"nojoystick",0);
if (!nojoystick)
{
SCA_JoystickManager *joymgr = new SCA_JoystickManager(m_logicmgr);
m_logicmgr->RegisterEventManager(joymgr);
}
2002-10-12 11:37:38 +00:00
m_soundScene = new SND_Scene(adi);
2005-01-23 01:36:29 +00:00
MT_assert (m_networkDeviceInterface != NULL);
2002-10-12 11:37:38 +00:00
m_networkScene = new NG_NetworkScene(m_networkDeviceInterface);
m_rootnode = NULL;
m_bucketmanager=new RAS_BucketManager();
2004-06-07 11:03:12 +00:00
m_attr_dict = PyDict_New(); /* new ref */
2002-10-12 11:37:38 +00:00
}
KX_Scene::~KX_Scene()
{
// The release of debug properties used to be in SCA_IScene::~SCA_IScene
// It's still there but we remove all properties here otherwise some
// reference might be hanging and causing late release of objects
RemoveAllDebugProperties();
while (GetRootParentList()->GetCount() > 0)
2002-10-12 11:37:38 +00:00
{
KX_GameObject* parentobj = (KX_GameObject*) GetRootParentList()->GetValue(0);
2002-10-12 11:37:38 +00:00
this->RemoveObject(parentobj);
}
if(m_objectlist)
m_objectlist->Release();
2002-10-12 11:37:38 +00:00
if (m_parentlist)
m_parentlist->Release();
if (m_inactivelist)
m_inactivelist->Release();
2002-10-12 11:37:38 +00:00
if (m_lightlist)
m_lightlist->Release();
if (m_tempObjectList)
m_tempObjectList->Release();
if (m_euthanasyobjects)
m_euthanasyobjects->Release();
2005-01-23 01:36:29 +00:00
2002-10-12 11:37:38 +00:00
if (m_logicmgr)
delete m_logicmgr;
if (m_physicsEnvironment)
delete m_physicsEnvironment;
if (m_soundScene)
delete m_soundScene;
if (m_networkScene)
delete m_networkScene;
if (m_bucketmanager)
{
delete m_bucketmanager;
}
PyDict_Clear(m_attr_dict);
Py_DECREF(m_attr_dict);
2002-10-12 11:37:38 +00:00
}
RAS_BucketManager* KX_Scene::GetBucketManager()
{
return m_bucketmanager;
}
CListValue* KX_Scene::GetObjectList()
{
return m_objectlist;
}
CListValue* KX_Scene::GetRootParentList()
{
return m_parentlist;
}
CListValue* KX_Scene::GetInactiveList()
{
return m_inactivelist;
}
2002-10-12 11:37:38 +00:00
CListValue* KX_Scene::GetLightList()
{
return m_lightlist;
}
SCA_LogicManager* KX_Scene::GetLogicManager()
{
return m_logicmgr;
}
SCA_TimeEventManager* KX_Scene::GetTimeEventManager()
{
return m_timemgr;
}
list<class KX_Camera*>* KX_Scene::GetCameras()
{
return &m_cameras;
}
2002-10-12 11:37:38 +00:00
void KX_Scene::SetFramingType(RAS_FrameSettings & frame_settings)
{
m_frame_settings = frame_settings;
};
/**
* Return a const reference to the framing
* type set by the above call.
* The contents are not guarenteed to be sensible
* if you don't call the above function.
*/
const RAS_FrameSettings& KX_Scene::GetFramingType() const
{
return m_frame_settings;
};
/**
* Store the current scene's viewport on the
* game engine canvas.
*/
void KX_Scene::SetSceneViewport(const RAS_Rect &viewport)
{
m_viewport = viewport;
}
const RAS_Rect& KX_Scene::GetSceneViewport() const
{
return m_viewport;
}
void KX_Scene::SetWorldInfo(class KX_WorldInfo* worldinfo)
{
m_worldinfo = worldinfo;
}
class KX_WorldInfo* KX_Scene::GetWorldInfo()
{
return m_worldinfo;
}
SND_Scene* KX_Scene::GetSoundScene()
{
return m_soundScene;
}
const STR_String& KX_Scene::GetName()
{
return m_sceneName;
}
void KX_Scene::Suspend()
{
m_suspend = true;
}
void KX_Scene::Resume()
{
m_suspend = false;
}
void KX_Scene::SetActivityCulling(bool b)
{
m_activity_culling = b;
}
bool KX_Scene::IsSuspended()
{
return m_suspend;
}
bool KX_Scene::IsClearingZBuffer()
{
return m_isclearingZbuffer;
}
void KX_Scene::EnableZBufferClearing(bool isclearingZbuffer)
{
m_isclearingZbuffer = isclearingZbuffer;
}
void KX_Scene::RemoveNodeDestructObject(class SG_IObject* node,class CValue* gameobj)
{
KX_GameObject* orgobj = (KX_GameObject*)gameobj;
if (NewRemoveObject(orgobj) != 0)
{
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
// object is not yet deleted because a reference is hanging somewhere.
// This should not happen anymore since we use proxy object for Python
// confident enough to put an assert?
//assert(false);
printf("Zombie object! name=%s\n", orgobj->GetName().ReadPtr());
orgobj->SetSGNode(NULL);
PHY_IGraphicController* ctrl = orgobj->GetGraphicController();
if (ctrl)
{
// a graphic controller is set, we must delete it as the node will be deleted
delete ctrl;
orgobj->SetGraphicController(NULL);
}
}
2002-10-12 11:37:38 +00:00
if (node)
delete node;
}
KX_GameObject* KX_Scene::AddNodeReplicaObject(class SG_IObject* node, class CValue* gameobj)
{
// for group duplication, limit the duplication of the hierarchy to the
// objects that are part of the group.
if (!IsObjectInGroup(gameobj))
return NULL;
2002-10-12 11:37:38 +00:00
KX_GameObject* orgobj = (KX_GameObject*)gameobj;
KX_GameObject* newobj = (KX_GameObject*)orgobj->GetReplica();
m_map_gameobject_to_replica.insert(orgobj, newobj);
// also register 'timers' (time properties) of the replica
int numprops = newobj->GetPropertyCount();
for (int i = 0; i < numprops; i++)
{
CValue* prop = newobj->GetProperty(i);
if (prop->GetProperty("timer"))
this->m_timemgr->AddTimeProperty(prop);
}
if (node)
{
newobj->SetSGNode((SG_Node*)node);
}
else
{
m_rootnode = new SG_Node(newobj,this,KX_Scene::m_callbacks);
// this fixes part of the scaling-added object bug
SG_Node* orgnode = orgobj->GetSGNode();
m_rootnode->SetLocalScale(orgnode->GetLocalScale());
m_rootnode->SetLocalPosition(orgnode->GetLocalPosition());
m_rootnode->SetLocalOrientation(orgnode->GetLocalOrientation());
// define the relationship between this node and it's parent.
KX_NormalParentRelation * parent_relation =
KX_NormalParentRelation::New();
m_rootnode->SetParentRelation(parent_relation);
newobj->SetSGNode(m_rootnode);
}
SG_IObject* replicanode = newobj->GetSGNode();
// SG_Node* rootnode = (replicanode == m_rootnode ? NULL : m_rootnode);
2002-10-12 11:37:38 +00:00
replicanode->SetSGClientObject(newobj);
// this is the list of object that are send to the graphics pipeline
m_objectlist->Add(newobj->AddRef());
BGE performance, 3rd round: culling and rasterizer. This commit extend the technique of dynamic linked list to the mesh slots so as to eliminate dumb scan or map lookup. It provides massive performance improvement in the culling and in the rasterizer when the majority of objects are static. Other improvements: - Compute the opengl matrix only for objects that are visible. - Simplify hash function for GEN_HasedPtr - Scan light list instead of general object list to render shadows - Remove redundant opengl calls to set specularity, shinyness and diffuse between each mesh slots. - Cache GPU material to avoid frequent call to GPU_material_from_blender - Only set once the fixed elements of mesh slot - Use more inline function The following table shows the performance increase between 2.48, 1st round and this round of improvement. The test was done with a scene containing 40000 objects, of which 1000 are in the view frustrum approximately. The object are simple textured cube to make sure the GPU is not the bottleneck. As some of the rasterizer processing time has moved under culling, I present the sum of scenegraph(includes culling)+rasterizer time Scenegraph+rasterizer(ms) 2.48 1st round 3rd round All objects static, 323.0 86.0 7.2 all visible, 1000 in the view frustrum All objects static, 219.0 49.7 N/A(*) all invisible. All objects moving, 323.0 105.6 34.7 all visible, 1000 in the view frustrum Scene destruction 40min 40min 4s (*) : this time is not representative because the frame rate was at 60fps. In that case, the GPU holds down the GE by frame sync. By design, the overhead of the rasterizer is 0 when the the objects are invisible. This table shows a global speed up between 9x and 45x compared to 2.48a for scenegraph, culling and rasterizer overhead. The speed up goes much higher when objects are invisible. An additional 2-4x speed up is possible in the scenegraph by upgrading the Moto library to use Eigen2 BLAS library instead of C++ classes but the scenegraph is already so fast that it is not a priority right now. Next speed up in logic: many things to do there...
2009-05-07 09:13:01 +00:00
if (newobj->IsLight())
m_lightlist->Add(newobj->AddRef());
newobj->AddMeshUser();
2002-10-12 11:37:38 +00:00
// logic cannot be replicated, until the whole hierarchy is replicated.
m_logicHierarchicalGameObjects.push_back(newobj);
//replicate controllers of this node
SGControllerList scenegraphcontrollers = orgobj->GetSGNode()->GetSGControllerList();
replicanode->RemoveAllControllers();
SGControllerList::iterator cit;
//int numcont = scenegraphcontrollers.size();
for (cit = scenegraphcontrollers.begin();!(cit==scenegraphcontrollers.end());++cit)
{
// controller replication is quite complicated
// only replicate ipo and physics controller for now
SG_Controller* replicacontroller = (*cit)->GetReplica((SG_Node*) replicanode);
if (replicacontroller)
{
replicacontroller->SetObject(replicanode);
replicanode->AddSGController(replicacontroller);
}
}
// replicate graphic controller
if (orgobj->GetGraphicController())
{
PHY_IMotionState* motionstate = new KX_MotionState(newobj->GetSGNode());
PHY_IGraphicController* newctrl = orgobj->GetGraphicController()->GetReplica(motionstate);
newctrl->setNewClientInfo(newobj->getClientInfo());
newobj->SetGraphicController(newctrl);
}
2002-10-12 11:37:38 +00:00
return newobj;
}
// before calling this method KX_Scene::ReplicateLogic(), make sure to
// have called 'GameObject::ReParentLogic' for each object this
// hierarchy that's because first ALL bricks must exist in the new
// replica of the hierarchy in order to make cross-links work properly
// !
// It is VERY important that the order of sensors and actuators in
// the replicated object is preserved: it is is used to reconnect the logic.
// This method is more robust then using the bricks name in case of complex
// group replication. The replication of logic bricks is done in
// SCA_IObject::ReParentLogic(), make sure it preserves the order of the bricks.
2002-10-12 11:37:38 +00:00
void KX_Scene::ReplicateLogic(KX_GameObject* newobj)
{
// also relink the controller to sensors/actuators
SCA_ControllerList& controllers = newobj->GetControllers();
//SCA_SensorList& sensors = newobj->GetSensors();
//SCA_ActuatorList& actuators = newobj->GetActuators();
for (SCA_ControllerList::iterator itc = controllers.begin(); !(itc==controllers.end());itc++)
{
SCA_IController* cont = (*itc);
cont->SetUeberExecutePriority(m_ueberExecutionPriority);
vector<SCA_ISensor*> linkedsensors = cont->GetLinkedSensors();
vector<SCA_IActuator*> linkedactuators = cont->GetLinkedActuators();
// disconnect the sensors and actuators
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
// do it directly on the list at this controller is not connected to anything at this stage
cont->GetLinkedSensors().clear();
cont->GetLinkedActuators().clear();
2002-10-12 11:37:38 +00:00
// now relink each sensor
for (vector<SCA_ISensor*>::iterator its = linkedsensors.begin();!(its==linkedsensors.end());its++)
{
SCA_ISensor* oldsensor = (*its);
SCA_IObject* oldsensorobj = oldsensor->GetParent();
SCA_IObject* newsensorobj = NULL;
2002-10-12 11:37:38 +00:00
// the original owner of the sensor has been replicated?
void **h_obj = m_map_gameobject_to_replica[oldsensorobj];
if (h_obj)
newsensorobj = (SCA_IObject*)(*h_obj);
if (!newsensorobj)
2002-10-12 11:37:38 +00:00
{
// no, then the sensor points outside the hierachy, keep it the same
if (m_objectlist->SearchValue(oldsensorobj))
// only replicate links that points to active objects
m_logicmgr->RegisterToSensor(cont,oldsensor);
2002-10-12 11:37:38 +00:00
}
else
{
// yes, then the new sensor has the same position
SCA_SensorList& sensorlist = oldsensorobj->GetSensors();
SCA_SensorList::iterator sit;
SCA_ISensor* newsensor = NULL;
int sensorpos;
2002-10-12 11:37:38 +00:00
for (sensorpos=0, sit=sensorlist.begin(); sit!=sensorlist.end(); sit++, sensorpos++)
2002-10-12 11:37:38 +00:00
{
if ((*sit) == oldsensor)
{
newsensor = newsensorobj->GetSensors().at(sensorpos);
break;
}
2002-10-12 11:37:38 +00:00
}
assert(newsensor != NULL);
m_logicmgr->RegisterToSensor(cont,newsensor);
2002-10-12 11:37:38 +00:00
}
}
// now relink each actuator
for (vector<SCA_IActuator*>::iterator ita = linkedactuators.begin();!(ita==linkedactuators.end());ita++)
{
SCA_IActuator* oldactuator = (*ita);
SCA_IObject* oldactuatorobj = oldactuator->GetParent();
SCA_IObject* newactuatorobj = NULL;
// the original owner of the sensor has been replicated?
void **h_obj = m_map_gameobject_to_replica[oldactuatorobj];
if (h_obj)
newactuatorobj = (SCA_IObject*)(*h_obj);
if (!newactuatorobj)
2002-10-12 11:37:38 +00:00
{
// no, then the sensor points outside the hierachy, keep it the same
if (m_objectlist->SearchValue(oldactuatorobj))
// only replicate links that points to active objects
m_logicmgr->RegisterToActuator(cont,oldactuator);
2002-10-12 11:37:38 +00:00
}
else
{
// yes, then the new sensor has the same position
SCA_ActuatorList& actuatorlist = oldactuatorobj->GetActuators();
SCA_ActuatorList::iterator ait;
SCA_IActuator* newactuator = NULL;
int actuatorpos;
2002-10-12 11:37:38 +00:00
for (actuatorpos=0, ait=actuatorlist.begin(); ait!=actuatorlist.end(); ait++, actuatorpos++)
2002-10-12 11:37:38 +00:00
{
if ((*ait) == oldactuator)
{
newactuator = newactuatorobj->GetActuators().at(actuatorpos);
break;
}
2002-10-12 11:37:38 +00:00
}
assert(newactuator != NULL);
m_logicmgr->RegisterToActuator(cont,newactuator);
newactuator->SetUeberExecutePriority(m_ueberExecutionPriority);
2002-10-12 11:37:38 +00:00
}
}
}
BGE logic patch: new "Add" mode for Ipo actuator, several corrections in state system. New Add mode for Ipo actuator ============================= A new Add button, mutually exclusive with Force button, is available in the Ipo actuator. When selected, it activates the Add mode that consists in adding the Ipo curve to the current object situation in world coordinates, or parent coordinates if the object has a parent. Scale Ipo curves are multiplied instead of added to the object current scale. If the local flag is selected, the Ipo curve is added (multiplied) in the object's local coordinates. Delta Ipo curves are handled identically to normal Ipo curve and there is no need to work with Delta Ipo curves provided that you make sure that the Ipo curve starts from origin. Origin means location 0 for Location Ipo curve, rotation 0 for Rotation Ipo curve and scale 1 for Scale Ipo curve. The "current object situation" means the object's location, rotation and scale at the start of the Ipo curve. For Loop Stop and Loop End Ipo actuators, this means at the start of each loop. This initial state is used as a base during the execution of the Ipo Curve but when the Ipo curve is restarted (later or immediately in case of Loop mode), the object current situation at that time is used as the new base. For reference, here is the exact operation of the Add mode for each type of Ipo curve (oLoc, oRot, oScale, oMat: object's loc/rot/scale and orientation matrix at the start of the curve; iLoc, iRot, iScale, iMat: Ipo curve loc/rot/scale and orientation matrix resulting from the rotation). Location Local=false: newLoc = oLoc+iLoc Local=true : newLoc = oLoc+oScale*(oMat*iLoc) Rotation Local=false: newMat = iMat*oMat Local=true : newMat = oMat*iMat Scale Local=false: newScale = oScale*iScale Local=true : newScale = oScale*iScale Add+Local mode is very useful to have dynamic object executing complex movement relative to their current location/orientation. Of cource, dynamics should be disabled during the execution of the curve. Several corrections in state system =================================== - Object initial state is taken into account when adding object dynamically - Fix bug with link count when adding object dynamically - Fix false on-off detection for Actuator sensor when actuator is trigged on negative event. - Fix Parent actuator false activation on negative event - Loop Ipo curve not restarting at correct frame when start frame is different from one.
2008-07-08 12:18:43 +00:00
// ready to set initial state
newobj->ResetState();
2002-10-12 11:37:38 +00:00
}
BGE patch: DUPLIGROUP option supported in BGE. Blender duplicates groups in the 3D view at the location of objects having the DUPLIGROUP option set. This feature is now supported in the BGE: the groups will be instantiated as in the 3D view when the scene is converted. This is useful to populate a scene with multiple enemies without having to actually duplicate the objects in the blend file. Notes: * The BGE applies the same criteria to instantiate the group as Blender to display them: if you see the group in the 3D view, it will be instantiated in the BGE. * Groups are instantiated as if the object having the DUPLIGROUP option (usually an empty) executed an AddObject actuator on the top objects of the group (objects without parent). * As a result, only intra-group parent relationship is supported: the BGE will not instantiate objects that have parents outside the group. * Intra-group logic bricks connections are preserved between the duplicated objects, even between the top objects of the group. * For best result, the state engine of the objects in the group should be self-contained: logic bricks should only have intra-group connections. Use messages to communicate with state engines outside the group. * Nested groups are supported: if one or more objects in the group have the DUPLIGROUP option set, the corresponding groups will be instantiated at the corresponding position and orientation. * Nested groups are instantiated as separate groups, not as one big group. * Linked groups are supported as well as groups containing objects from the active layers. * There is a difference in the way Blender displays the groups in the 3D view and how BGE instantiates them: Blender does not take into account the parent relationship in the group and displays the objects as if they were all children of the object having the DUPLIGROUP option. That's correct for the top objects of the group but not for the children. Hence the orientation of the children objects may be different in the BGE. * An AddGroup actuator will be added in a future release.
2008-07-15 20:05:23 +00:00
void KX_Scene::DupliGroupRecurse(CValue* obj, int level)
{
KX_GameObject* groupobj = (KX_GameObject*) obj;
KX_GameObject* replica;
KX_GameObject* gameobj;
BGE patch: DUPLIGROUP option supported in BGE. Blender duplicates groups in the 3D view at the location of objects having the DUPLIGROUP option set. This feature is now supported in the BGE: the groups will be instantiated as in the 3D view when the scene is converted. This is useful to populate a scene with multiple enemies without having to actually duplicate the objects in the blend file. Notes: * The BGE applies the same criteria to instantiate the group as Blender to display them: if you see the group in the 3D view, it will be instantiated in the BGE. * Groups are instantiated as if the object having the DUPLIGROUP option (usually an empty) executed an AddObject actuator on the top objects of the group (objects without parent). * As a result, only intra-group parent relationship is supported: the BGE will not instantiate objects that have parents outside the group. * Intra-group logic bricks connections are preserved between the duplicated objects, even between the top objects of the group. * For best result, the state engine of the objects in the group should be self-contained: logic bricks should only have intra-group connections. Use messages to communicate with state engines outside the group. * Nested groups are supported: if one or more objects in the group have the DUPLIGROUP option set, the corresponding groups will be instantiated at the corresponding position and orientation. * Nested groups are instantiated as separate groups, not as one big group. * Linked groups are supported as well as groups containing objects from the active layers. * There is a difference in the way Blender displays the groups in the 3D view and how BGE instantiates them: Blender does not take into account the parent relationship in the group and displays the objects as if they were all children of the object having the DUPLIGROUP option. That's correct for the top objects of the group but not for the children. Hence the orientation of the children objects may be different in the BGE. * An AddGroup actuator will be added in a future release.
2008-07-15 20:05:23 +00:00
Object* blgroupobj = groupobj->GetBlenderObject();
Group* group;
GroupObject *go;
vector<KX_GameObject*> duplilist;
if (!groupobj->GetSGNode() ||
!groupobj->IsDupliGroup() ||
BGE patch: DUPLIGROUP option supported in BGE. Blender duplicates groups in the 3D view at the location of objects having the DUPLIGROUP option set. This feature is now supported in the BGE: the groups will be instantiated as in the 3D view when the scene is converted. This is useful to populate a scene with multiple enemies without having to actually duplicate the objects in the blend file. Notes: * The BGE applies the same criteria to instantiate the group as Blender to display them: if you see the group in the 3D view, it will be instantiated in the BGE. * Groups are instantiated as if the object having the DUPLIGROUP option (usually an empty) executed an AddObject actuator on the top objects of the group (objects without parent). * As a result, only intra-group parent relationship is supported: the BGE will not instantiate objects that have parents outside the group. * Intra-group logic bricks connections are preserved between the duplicated objects, even between the top objects of the group. * For best result, the state engine of the objects in the group should be self-contained: logic bricks should only have intra-group connections. Use messages to communicate with state engines outside the group. * Nested groups are supported: if one or more objects in the group have the DUPLIGROUP option set, the corresponding groups will be instantiated at the corresponding position and orientation. * Nested groups are instantiated as separate groups, not as one big group. * Linked groups are supported as well as groups containing objects from the active layers. * There is a difference in the way Blender displays the groups in the 3D view and how BGE instantiates them: Blender does not take into account the parent relationship in the group and displays the objects as if they were all children of the object having the DUPLIGROUP option. That's correct for the top objects of the group but not for the children. Hence the orientation of the children objects may be different in the BGE. * An AddGroup actuator will be added in a future release.
2008-07-15 20:05:23 +00:00
level>MAX_DUPLI_RECUR)
return;
// we will add one group at a time
m_logicHierarchicalGameObjects.clear();
m_map_gameobject_to_replica.clear();
m_ueberExecutionPriority++;
// for groups will do something special:
// we will force the creation of objects to those in the group only
// Again, this is match what Blender is doing (it doesn't care of parent relationship)
m_groupGameObjects.clear();
BGE patch: DUPLIGROUP option supported in BGE. Blender duplicates groups in the 3D view at the location of objects having the DUPLIGROUP option set. This feature is now supported in the BGE: the groups will be instantiated as in the 3D view when the scene is converted. This is useful to populate a scene with multiple enemies without having to actually duplicate the objects in the blend file. Notes: * The BGE applies the same criteria to instantiate the group as Blender to display them: if you see the group in the 3D view, it will be instantiated in the BGE. * Groups are instantiated as if the object having the DUPLIGROUP option (usually an empty) executed an AddObject actuator on the top objects of the group (objects without parent). * As a result, only intra-group parent relationship is supported: the BGE will not instantiate objects that have parents outside the group. * Intra-group logic bricks connections are preserved between the duplicated objects, even between the top objects of the group. * For best result, the state engine of the objects in the group should be self-contained: logic bricks should only have intra-group connections. Use messages to communicate with state engines outside the group. * Nested groups are supported: if one or more objects in the group have the DUPLIGROUP option set, the corresponding groups will be instantiated at the corresponding position and orientation. * Nested groups are instantiated as separate groups, not as one big group. * Linked groups are supported as well as groups containing objects from the active layers. * There is a difference in the way Blender displays the groups in the 3D view and how BGE instantiates them: Blender does not take into account the parent relationship in the group and displays the objects as if they were all children of the object having the DUPLIGROUP option. That's correct for the top objects of the group but not for the children. Hence the orientation of the children objects may be different in the BGE. * An AddGroup actuator will be added in a future release.
2008-07-15 20:05:23 +00:00
group = blgroupobj->dup_group;
for(go=(GroupObject*)group->gobject.first; go; go=(GroupObject*)go->next)
{
Object* blenderobj = go->ob;
if (blgroupobj == blenderobj)
// this check is also in group_duplilist()
continue;
gameobj = (KX_GameObject*)m_logicmgr->FindGameObjByBlendObj(blenderobj);
BGE patch: DUPLIGROUP option supported in BGE. Blender duplicates groups in the 3D view at the location of objects having the DUPLIGROUP option set. This feature is now supported in the BGE: the groups will be instantiated as in the 3D view when the scene is converted. This is useful to populate a scene with multiple enemies without having to actually duplicate the objects in the blend file. Notes: * The BGE applies the same criteria to instantiate the group as Blender to display them: if you see the group in the 3D view, it will be instantiated in the BGE. * Groups are instantiated as if the object having the DUPLIGROUP option (usually an empty) executed an AddObject actuator on the top objects of the group (objects without parent). * As a result, only intra-group parent relationship is supported: the BGE will not instantiate objects that have parents outside the group. * Intra-group logic bricks connections are preserved between the duplicated objects, even between the top objects of the group. * For best result, the state engine of the objects in the group should be self-contained: logic bricks should only have intra-group connections. Use messages to communicate with state engines outside the group. * Nested groups are supported: if one or more objects in the group have the DUPLIGROUP option set, the corresponding groups will be instantiated at the corresponding position and orientation. * Nested groups are instantiated as separate groups, not as one big group. * Linked groups are supported as well as groups containing objects from the active layers. * There is a difference in the way Blender displays the groups in the 3D view and how BGE instantiates them: Blender does not take into account the parent relationship in the group and displays the objects as if they were all children of the object having the DUPLIGROUP option. That's correct for the top objects of the group but not for the children. Hence the orientation of the children objects may be different in the BGE. * An AddGroup actuator will be added in a future release.
2008-07-15 20:05:23 +00:00
if (gameobj == NULL)
{
// this object has not been converted!!!
// Should not happen as dupli group are created automatically
continue;
}
gameobj->SetBlenderGroupObject(blgroupobj);
if ((blenderobj->lay & group->layer)==0)
{
// object is not visible in the 3D view, will not be instantiated
continue;
}
m_groupGameObjects.insert(gameobj);
}
set<CValue*>::iterator oit;
for (oit=m_groupGameObjects.begin(); oit != m_groupGameObjects.end(); oit++)
{
gameobj = (KX_GameObject*)(*oit);
KX_GameObject *parent = gameobj->GetParent();
if (parent != NULL)
BGE patch: DUPLIGROUP option supported in BGE. Blender duplicates groups in the 3D view at the location of objects having the DUPLIGROUP option set. This feature is now supported in the BGE: the groups will be instantiated as in the 3D view when the scene is converted. This is useful to populate a scene with multiple enemies without having to actually duplicate the objects in the blend file. Notes: * The BGE applies the same criteria to instantiate the group as Blender to display them: if you see the group in the 3D view, it will be instantiated in the BGE. * Groups are instantiated as if the object having the DUPLIGROUP option (usually an empty) executed an AddObject actuator on the top objects of the group (objects without parent). * As a result, only intra-group parent relationship is supported: the BGE will not instantiate objects that have parents outside the group. * Intra-group logic bricks connections are preserved between the duplicated objects, even between the top objects of the group. * For best result, the state engine of the objects in the group should be self-contained: logic bricks should only have intra-group connections. Use messages to communicate with state engines outside the group. * Nested groups are supported: if one or more objects in the group have the DUPLIGROUP option set, the corresponding groups will be instantiated at the corresponding position and orientation. * Nested groups are instantiated as separate groups, not as one big group. * Linked groups are supported as well as groups containing objects from the active layers. * There is a difference in the way Blender displays the groups in the 3D view and how BGE instantiates them: Blender does not take into account the parent relationship in the group and displays the objects as if they were all children of the object having the DUPLIGROUP option. That's correct for the top objects of the group but not for the children. Hence the orientation of the children objects may be different in the BGE. * An AddGroup actuator will be added in a future release.
2008-07-15 20:05:23 +00:00
{
parent->Release(); // GetParent() increased the refcount
BGE patch: DUPLIGROUP option supported in BGE. Blender duplicates groups in the 3D view at the location of objects having the DUPLIGROUP option set. This feature is now supported in the BGE: the groups will be instantiated as in the 3D view when the scene is converted. This is useful to populate a scene with multiple enemies without having to actually duplicate the objects in the blend file. Notes: * The BGE applies the same criteria to instantiate the group as Blender to display them: if you see the group in the 3D view, it will be instantiated in the BGE. * Groups are instantiated as if the object having the DUPLIGROUP option (usually an empty) executed an AddObject actuator on the top objects of the group (objects without parent). * As a result, only intra-group parent relationship is supported: the BGE will not instantiate objects that have parents outside the group. * Intra-group logic bricks connections are preserved between the duplicated objects, even between the top objects of the group. * For best result, the state engine of the objects in the group should be self-contained: logic bricks should only have intra-group connections. Use messages to communicate with state engines outside the group. * Nested groups are supported: if one or more objects in the group have the DUPLIGROUP option set, the corresponding groups will be instantiated at the corresponding position and orientation. * Nested groups are instantiated as separate groups, not as one big group. * Linked groups are supported as well as groups containing objects from the active layers. * There is a difference in the way Blender displays the groups in the 3D view and how BGE instantiates them: Blender does not take into account the parent relationship in the group and displays the objects as if they were all children of the object having the DUPLIGROUP option. That's correct for the top objects of the group but not for the children. Hence the orientation of the children objects may be different in the BGE. * An AddGroup actuator will be added in a future release.
2008-07-15 20:05:23 +00:00
// this object is not a top parent. Either it is the child of another
// object in the group and it will be added automatically when the parent
// is added. Or it is the child of an object outside the group and the group
// is inconsistent, skip it anyway
continue;
}
replica = (KX_GameObject*) AddNodeReplicaObject(NULL,gameobj);
// add to 'rootparent' list (this is the list of top hierarchy objects, updated each frame)
m_parentlist->Add(replica->AddRef());
// recurse replication into children nodes
NodeList& children = gameobj->GetSGNode()->GetSGChildren();
replica->GetSGNode()->ClearSGChildren();
for (NodeList::iterator childit = children.begin();!(childit==children.end());++childit)
{
SG_Node* orgnode = (*childit);
SG_Node* childreplicanode = orgnode->GetSGReplica();
if (childreplicanode)
replica->GetSGNode()->AddChild(childreplicanode);
BGE patch: DUPLIGROUP option supported in BGE. Blender duplicates groups in the 3D view at the location of objects having the DUPLIGROUP option set. This feature is now supported in the BGE: the groups will be instantiated as in the 3D view when the scene is converted. This is useful to populate a scene with multiple enemies without having to actually duplicate the objects in the blend file. Notes: * The BGE applies the same criteria to instantiate the group as Blender to display them: if you see the group in the 3D view, it will be instantiated in the BGE. * Groups are instantiated as if the object having the DUPLIGROUP option (usually an empty) executed an AddObject actuator on the top objects of the group (objects without parent). * As a result, only intra-group parent relationship is supported: the BGE will not instantiate objects that have parents outside the group. * Intra-group logic bricks connections are preserved between the duplicated objects, even between the top objects of the group. * For best result, the state engine of the objects in the group should be self-contained: logic bricks should only have intra-group connections. Use messages to communicate with state engines outside the group. * Nested groups are supported: if one or more objects in the group have the DUPLIGROUP option set, the corresponding groups will be instantiated at the corresponding position and orientation. * Nested groups are instantiated as separate groups, not as one big group. * Linked groups are supported as well as groups containing objects from the active layers. * There is a difference in the way Blender displays the groups in the 3D view and how BGE instantiates them: Blender does not take into account the parent relationship in the group and displays the objects as if they were all children of the object having the DUPLIGROUP option. That's correct for the top objects of the group but not for the children. Hence the orientation of the children objects may be different in the BGE. * An AddGroup actuator will be added in a future release.
2008-07-15 20:05:23 +00:00
}
// don't replicate logic now: we assume that the objects in the group can have
// logic relationship, even outside parent relationship
// In order to match 3D view, the position of groupobj is used as a
// transformation matrix instead of the new position. This means that
// the group reference point is 0,0,0
BGE patch: DUPLIGROUP option supported in BGE. Blender duplicates groups in the 3D view at the location of objects having the DUPLIGROUP option set. This feature is now supported in the BGE: the groups will be instantiated as in the 3D view when the scene is converted. This is useful to populate a scene with multiple enemies without having to actually duplicate the objects in the blend file. Notes: * The BGE applies the same criteria to instantiate the group as Blender to display them: if you see the group in the 3D view, it will be instantiated in the BGE. * Groups are instantiated as if the object having the DUPLIGROUP option (usually an empty) executed an AddObject actuator on the top objects of the group (objects without parent). * As a result, only intra-group parent relationship is supported: the BGE will not instantiate objects that have parents outside the group. * Intra-group logic bricks connections are preserved between the duplicated objects, even between the top objects of the group. * For best result, the state engine of the objects in the group should be self-contained: logic bricks should only have intra-group connections. Use messages to communicate with state engines outside the group. * Nested groups are supported: if one or more objects in the group have the DUPLIGROUP option set, the corresponding groups will be instantiated at the corresponding position and orientation. * Nested groups are instantiated as separate groups, not as one big group. * Linked groups are supported as well as groups containing objects from the active layers. * There is a difference in the way Blender displays the groups in the 3D view and how BGE instantiates them: Blender does not take into account the parent relationship in the group and displays the objects as if they were all children of the object having the DUPLIGROUP option. That's correct for the top objects of the group but not for the children. Hence the orientation of the children objects may be different in the BGE. * An AddGroup actuator will be added in a future release.
2008-07-15 20:05:23 +00:00
// get the rootnode's scale
MT_Vector3 newscale = groupobj->NodeGetWorldScaling();
BGE patch: DUPLIGROUP option supported in BGE. Blender duplicates groups in the 3D view at the location of objects having the DUPLIGROUP option set. This feature is now supported in the BGE: the groups will be instantiated as in the 3D view when the scene is converted. This is useful to populate a scene with multiple enemies without having to actually duplicate the objects in the blend file. Notes: * The BGE applies the same criteria to instantiate the group as Blender to display them: if you see the group in the 3D view, it will be instantiated in the BGE. * Groups are instantiated as if the object having the DUPLIGROUP option (usually an empty) executed an AddObject actuator on the top objects of the group (objects without parent). * As a result, only intra-group parent relationship is supported: the BGE will not instantiate objects that have parents outside the group. * Intra-group logic bricks connections are preserved between the duplicated objects, even between the top objects of the group. * For best result, the state engine of the objects in the group should be self-contained: logic bricks should only have intra-group connections. Use messages to communicate with state engines outside the group. * Nested groups are supported: if one or more objects in the group have the DUPLIGROUP option set, the corresponding groups will be instantiated at the corresponding position and orientation. * Nested groups are instantiated as separate groups, not as one big group. * Linked groups are supported as well as groups containing objects from the active layers. * There is a difference in the way Blender displays the groups in the 3D view and how BGE instantiates them: Blender does not take into account the parent relationship in the group and displays the objects as if they were all children of the object having the DUPLIGROUP option. That's correct for the top objects of the group but not for the children. Hence the orientation of the children objects may be different in the BGE. * An AddGroup actuator will be added in a future release.
2008-07-15 20:05:23 +00:00
// set the replica's relative scale with the rootnode's scale
replica->NodeSetRelativeScale(newscale);
MT_Point3 offset(group->dupli_ofs);
MT_Point3 newpos = groupobj->NodeGetWorldPosition() +
newscale*(groupobj->NodeGetWorldOrientation() * (gameobj->NodeGetWorldPosition()-offset));
replica->NodeSetLocalPosition(newpos);
// set the orientation after position for softbody!
MT_Matrix3x3 newori = groupobj->NodeGetWorldOrientation() * gameobj->NodeGetWorldOrientation();
replica->NodeSetLocalOrientation(newori);
// update scenegraph for entire tree of children
BGE patch: DUPLIGROUP option supported in BGE. Blender duplicates groups in the 3D view at the location of objects having the DUPLIGROUP option set. This feature is now supported in the BGE: the groups will be instantiated as in the 3D view when the scene is converted. This is useful to populate a scene with multiple enemies without having to actually duplicate the objects in the blend file. Notes: * The BGE applies the same criteria to instantiate the group as Blender to display them: if you see the group in the 3D view, it will be instantiated in the BGE. * Groups are instantiated as if the object having the DUPLIGROUP option (usually an empty) executed an AddObject actuator on the top objects of the group (objects without parent). * As a result, only intra-group parent relationship is supported: the BGE will not instantiate objects that have parents outside the group. * Intra-group logic bricks connections are preserved between the duplicated objects, even between the top objects of the group. * For best result, the state engine of the objects in the group should be self-contained: logic bricks should only have intra-group connections. Use messages to communicate with state engines outside the group. * Nested groups are supported: if one or more objects in the group have the DUPLIGROUP option set, the corresponding groups will be instantiated at the corresponding position and orientation. * Nested groups are instantiated as separate groups, not as one big group. * Linked groups are supported as well as groups containing objects from the active layers. * There is a difference in the way Blender displays the groups in the 3D view and how BGE instantiates them: Blender does not take into account the parent relationship in the group and displays the objects as if they were all children of the object having the DUPLIGROUP option. That's correct for the top objects of the group but not for the children. Hence the orientation of the children objects may be different in the BGE. * An AddGroup actuator will be added in a future release.
2008-07-15 20:05:23 +00:00
replica->GetSGNode()->UpdateWorldData(0);
replica->GetSGNode()->SetBBox(gameobj->GetSGNode()->BBox());
replica->GetSGNode()->SetRadius(gameobj->GetSGNode()->Radius());
// we can now add the graphic controller to the physic engine
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
replica->ActivateGraphicController(true);
BGE patch: DUPLIGROUP option supported in BGE. Blender duplicates groups in the 3D view at the location of objects having the DUPLIGROUP option set. This feature is now supported in the BGE: the groups will be instantiated as in the 3D view when the scene is converted. This is useful to populate a scene with multiple enemies without having to actually duplicate the objects in the blend file. Notes: * The BGE applies the same criteria to instantiate the group as Blender to display them: if you see the group in the 3D view, it will be instantiated in the BGE. * Groups are instantiated as if the object having the DUPLIGROUP option (usually an empty) executed an AddObject actuator on the top objects of the group (objects without parent). * As a result, only intra-group parent relationship is supported: the BGE will not instantiate objects that have parents outside the group. * Intra-group logic bricks connections are preserved between the duplicated objects, even between the top objects of the group. * For best result, the state engine of the objects in the group should be self-contained: logic bricks should only have intra-group connections. Use messages to communicate with state engines outside the group. * Nested groups are supported: if one or more objects in the group have the DUPLIGROUP option set, the corresponding groups will be instantiated at the corresponding position and orientation. * Nested groups are instantiated as separate groups, not as one big group. * Linked groups are supported as well as groups containing objects from the active layers. * There is a difference in the way Blender displays the groups in the 3D view and how BGE instantiates them: Blender does not take into account the parent relationship in the group and displays the objects as if they were all children of the object having the DUPLIGROUP option. That's correct for the top objects of the group but not for the children. Hence the orientation of the children objects may be different in the BGE. * An AddGroup actuator will be added in a future release.
2008-07-15 20:05:23 +00:00
// done with replica
replica->Release();
}
// the logic must be replicated first because we need
// the new logic bricks before relinking
BGE patch: DUPLIGROUP option supported in BGE. Blender duplicates groups in the 3D view at the location of objects having the DUPLIGROUP option set. This feature is now supported in the BGE: the groups will be instantiated as in the 3D view when the scene is converted. This is useful to populate a scene with multiple enemies without having to actually duplicate the objects in the blend file. Notes: * The BGE applies the same criteria to instantiate the group as Blender to display them: if you see the group in the 3D view, it will be instantiated in the BGE. * Groups are instantiated as if the object having the DUPLIGROUP option (usually an empty) executed an AddObject actuator on the top objects of the group (objects without parent). * As a result, only intra-group parent relationship is supported: the BGE will not instantiate objects that have parents outside the group. * Intra-group logic bricks connections are preserved between the duplicated objects, even between the top objects of the group. * For best result, the state engine of the objects in the group should be self-contained: logic bricks should only have intra-group connections. Use messages to communicate with state engines outside the group. * Nested groups are supported: if one or more objects in the group have the DUPLIGROUP option set, the corresponding groups will be instantiated at the corresponding position and orientation. * Nested groups are instantiated as separate groups, not as one big group. * Linked groups are supported as well as groups containing objects from the active layers. * There is a difference in the way Blender displays the groups in the 3D view and how BGE instantiates them: Blender does not take into account the parent relationship in the group and displays the objects as if they were all children of the object having the DUPLIGROUP option. That's correct for the top objects of the group but not for the children. Hence the orientation of the children objects may be different in the BGE. * An AddGroup actuator will be added in a future release.
2008-07-15 20:05:23 +00:00
vector<KX_GameObject*>::iterator git;
for (git = m_logicHierarchicalGameObjects.begin();!(git==m_logicHierarchicalGameObjects.end());++git)
{
(*git)->ReParentLogic();
}
// relink any pointers as necessary, sort of a temporary solution
for (git = m_logicHierarchicalGameObjects.begin();!(git==m_logicHierarchicalGameObjects.end());++git)
{
// this will also relink the actuator to objects within the hierarchy
BGE patch: DUPLIGROUP option supported in BGE. Blender duplicates groups in the 3D view at the location of objects having the DUPLIGROUP option set. This feature is now supported in the BGE: the groups will be instantiated as in the 3D view when the scene is converted. This is useful to populate a scene with multiple enemies without having to actually duplicate the objects in the blend file. Notes: * The BGE applies the same criteria to instantiate the group as Blender to display them: if you see the group in the 3D view, it will be instantiated in the BGE. * Groups are instantiated as if the object having the DUPLIGROUP option (usually an empty) executed an AddObject actuator on the top objects of the group (objects without parent). * As a result, only intra-group parent relationship is supported: the BGE will not instantiate objects that have parents outside the group. * Intra-group logic bricks connections are preserved between the duplicated objects, even between the top objects of the group. * For best result, the state engine of the objects in the group should be self-contained: logic bricks should only have intra-group connections. Use messages to communicate with state engines outside the group. * Nested groups are supported: if one or more objects in the group have the DUPLIGROUP option set, the corresponding groups will be instantiated at the corresponding position and orientation. * Nested groups are instantiated as separate groups, not as one big group. * Linked groups are supported as well as groups containing objects from the active layers. * There is a difference in the way Blender displays the groups in the 3D view and how BGE instantiates them: Blender does not take into account the parent relationship in the group and displays the objects as if they were all children of the object having the DUPLIGROUP option. That's correct for the top objects of the group but not for the children. Hence the orientation of the children objects may be different in the BGE. * An AddGroup actuator will be added in a future release.
2008-07-15 20:05:23 +00:00
(*git)->Relink(&m_map_gameobject_to_replica);
// add the object in the layer of the parent
(*git)->SetLayer(groupobj->GetLayer());
// If the object was a light, we need to update it's RAS_LightObject as well
if ((*git)->IsLight())
{
KX_LightObject* lightobj = static_cast<KX_LightObject*>(*git);
lightobj->GetLightData()->m_layer = groupobj->GetLayer();
}
BGE patch: DUPLIGROUP option supported in BGE. Blender duplicates groups in the 3D view at the location of objects having the DUPLIGROUP option set. This feature is now supported in the BGE: the groups will be instantiated as in the 3D view when the scene is converted. This is useful to populate a scene with multiple enemies without having to actually duplicate the objects in the blend file. Notes: * The BGE applies the same criteria to instantiate the group as Blender to display them: if you see the group in the 3D view, it will be instantiated in the BGE. * Groups are instantiated as if the object having the DUPLIGROUP option (usually an empty) executed an AddObject actuator on the top objects of the group (objects without parent). * As a result, only intra-group parent relationship is supported: the BGE will not instantiate objects that have parents outside the group. * Intra-group logic bricks connections are preserved between the duplicated objects, even between the top objects of the group. * For best result, the state engine of the objects in the group should be self-contained: logic bricks should only have intra-group connections. Use messages to communicate with state engines outside the group. * Nested groups are supported: if one or more objects in the group have the DUPLIGROUP option set, the corresponding groups will be instantiated at the corresponding position and orientation. * Nested groups are instantiated as separate groups, not as one big group. * Linked groups are supported as well as groups containing objects from the active layers. * There is a difference in the way Blender displays the groups in the 3D view and how BGE instantiates them: Blender does not take into account the parent relationship in the group and displays the objects as if they were all children of the object having the DUPLIGROUP option. That's correct for the top objects of the group but not for the children. Hence the orientation of the children objects may be different in the BGE. * An AddGroup actuator will be added in a future release.
2008-07-15 20:05:23 +00:00
}
// replicate crosslinks etc. between logic bricks
for (git = m_logicHierarchicalGameObjects.begin();!(git==m_logicHierarchicalGameObjects.end());++git)
{
ReplicateLogic((*git));
}
// now look if object in the hierarchy have dupli group and recurse
for (git = m_logicHierarchicalGameObjects.begin();!(git==m_logicHierarchicalGameObjects.end());++git)
{
if ((*git) != groupobj && (*git)->IsDupliGroup())
// can't instantiate group immediately as it destroys m_logicHierarchicalGameObjects
duplilist.push_back((*git));
}
for (git = duplilist.begin(); !(git == duplilist.end()); ++git)
{
DupliGroupRecurse((*git), level+1);
}
}
2002-10-12 11:37:38 +00:00
SCA_IObject* KX_Scene::AddReplicaObject(class CValue* originalobject,
class CValue* parentobject,
int lifespan)
{
m_logicHierarchicalGameObjects.clear();
m_map_gameobject_to_replica.clear();
m_groupGameObjects.clear();
2002-10-12 11:37:38 +00:00
// todo: place a timebomb in the object, for temporarily objects :)
// lifespan of zero means 'this object lives forever'
KX_GameObject* originalobj = (KX_GameObject*) originalobject;
KX_GameObject* parentobj = (KX_GameObject*) parentobject;
m_ueberExecutionPriority++;
// lets create a replica
KX_GameObject* replica = (KX_GameObject*) AddNodeReplicaObject(NULL,originalobj);
if (lifespan > 0)
{
// add a timebomb to this object
// for now, convert between so called frames and realtime
m_tempObjectList->Add(replica->AddRef());
CValue *fval = new CFloatValue(lifespan*0.02);
replica->SetProperty("::timebomb",fval);
fval->Release();
2002-10-12 11:37:38 +00:00
}
// add to 'rootparent' list (this is the list of top hierarchy objects, updated each frame)
m_parentlist->Add(replica->AddRef());
// recurse replication into children nodes
NodeList& children = originalobj->GetSGNode()->GetSGChildren();
replica->GetSGNode()->ClearSGChildren();
for (NodeList::iterator childit = children.begin();!(childit==children.end());++childit)
{
SG_Node* orgnode = (*childit);
SG_Node* childreplicanode = orgnode->GetSGReplica();
if (childreplicanode)
replica->GetSGNode()->AddChild(childreplicanode);
2002-10-12 11:37:38 +00:00
}
// At this stage all the objects in the hierarchy have been duplicated,
// we can update the scenegraph, we need it for the duplication of logic
MT_Point3 newpos = ((KX_GameObject*) parentobject)->NodeGetWorldPosition();
replica->NodeSetLocalPosition(newpos);
MT_Matrix3x3 newori = ((KX_GameObject*) parentobject)->NodeGetWorldOrientation();
replica->NodeSetLocalOrientation(newori);
// get the rootnode's scale
MT_Vector3 newscale = parentobj->GetSGNode()->GetRootSGParent()->GetLocalScale();
// set the replica's relative scale with the rootnode's scale
replica->NodeSetRelativeScale(newscale);
replica->GetSGNode()->UpdateWorldData(0);
replica->GetSGNode()->SetBBox(originalobj->GetSGNode()->BBox());
replica->GetSGNode()->SetRadius(originalobj->GetSGNode()->Radius());
// the size is correct, we can add the graphic controller to the physic engine
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
replica->ActivateGraphicController(true);
// now replicate logic
2002-10-12 11:37:38 +00:00
vector<KX_GameObject*>::iterator git;
for (git = m_logicHierarchicalGameObjects.begin();!(git==m_logicHierarchicalGameObjects.end());++git)
{
(*git)->ReParentLogic();
}
// relink any pointers as necessary, sort of a temporary solution
for (git = m_logicHierarchicalGameObjects.begin();!(git==m_logicHierarchicalGameObjects.end());++git)
{
// this will also relink the actuators in the hierarchy
2002-10-12 11:37:38 +00:00
(*git)->Relink(&m_map_gameobject_to_replica);
// add the object in the layer of the parent
(*git)->SetLayer(parentobj->GetLayer());
// If the object was a light, we need to update it's RAS_LightObject as well
if ((*git)->IsLight())
{
KX_LightObject* lightobj = static_cast<KX_LightObject*>(*git);
lightobj->GetLightData()->m_layer = parentobj->GetLayer();
}
2002-10-12 11:37:38 +00:00
}
// replicate crosslinks etc. between logic bricks
for (git = m_logicHierarchicalGameObjects.begin();!(git==m_logicHierarchicalGameObjects.end());++git)
{
ReplicateLogic((*git));
}
// check if there are objects with dupligroup in the hierarchy
vector<KX_GameObject*> duplilist;
for (git = m_logicHierarchicalGameObjects.begin();!(git==m_logicHierarchicalGameObjects.end());++git)
{
if ((*git)->IsDupliGroup())
{
// separate list as m_logicHierarchicalGameObjects is also used by DupliGroupRecurse()
duplilist.push_back(*git);
}
}
for (git = duplilist.begin();!(git==duplilist.end());++git)
{
DupliGroupRecurse(*git, 0);
}
// don't release replica here because we are returning it, not done with it...
2002-10-12 11:37:38 +00:00
return replica;
}
void KX_Scene::RemoveObject(class CValue* gameobj)
{
KX_GameObject* newobj = (KX_GameObject*) gameobj;
// disconnect child from parent
2002-10-12 11:37:38 +00:00
SG_Node* node = newobj->GetSGNode();
if (node)
{
node->DisconnectFromParent();
// recursively destruct
node->Destruct();
}
//no need to do that: the object is destroyed and memory released
//newobj->SetSGNode(0);
2002-10-12 11:37:38 +00:00
}
void KX_Scene::DelayedRemoveObject(class CValue* gameobj)
{
//KX_GameObject* newobj = (KX_GameObject*) gameobj;
if (!m_euthanasyobjects->SearchValue(gameobj))
{
m_euthanasyobjects->Add(gameobj->AddRef());
}
}
int KX_Scene::NewRemoveObject(class CValue* gameobj)
2002-10-12 11:37:38 +00:00
{
int ret;
2002-10-12 11:37:38 +00:00
KX_GameObject* newobj = (KX_GameObject*) gameobj;
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
/* Invalidate the python reference, since the object may exist in script lists
* its possible that it wont be automatically invalidated, so do it manually here,
*
* if for some reason the object is added back into the scene python can always get a new Proxy
*/
newobj->InvalidateProxy();
// keep the blender->game object association up to date
// note that all the replicas of an object will have the same
// blender object, that's why we need to check the game object
// as only the deletion of the original object must be recorded
m_logicmgr->UnregisterGameObj(newobj->GetBlenderObject(), gameobj);
//todo: look at this
//GetPhysicsEnvironment()->RemovePhysicsController(gameobj->getPhysicsController());
2002-10-12 11:37:38 +00:00
// remove all sensors/controllers/actuators from logicsystem...
SCA_SensorList& sensors = newobj->GetSensors();
for (SCA_SensorList::iterator its = sensors.begin();
!(its==sensors.end());its++)
{
m_logicmgr->RemoveSensor(*its);
}
SCA_ControllerList& controllers = newobj->GetControllers();
for (SCA_ControllerList::iterator itc = controllers.begin();
!(itc==controllers.end());itc++)
{
m_logicmgr->RemoveController(*itc);
2002-10-12 11:37:38 +00:00
}
SCA_ActuatorList& actuators = newobj->GetActuators();
for (SCA_ActuatorList::iterator ita = actuators.begin();
!(ita==actuators.end());ita++)
{
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
m_logicmgr->RemoveActuator(*ita);
2002-10-12 11:37:38 +00:00
}
// the sensors/controllers/actuators must also be released, this is done in ~SCA_IObject
2002-10-12 11:37:38 +00:00
// now remove the timer properties from the time manager
int numprops = newobj->GetPropertyCount();
for (int i = 0; i < numprops; i++)
{
CValue* propval = newobj->GetProperty(i);
if (propval->GetProperty("timer"))
{
m_timemgr->RemoveTimeProperty(propval);
}
}
newobj->RemoveMeshes();
ret = 1;
if (newobj->IsLight() && m_lightlist->RemoveValue(newobj))
ret = newobj->Release();
2002-10-12 11:37:38 +00:00
if (m_objectlist->RemoveValue(newobj))
ret = newobj->Release();
2002-10-12 11:37:38 +00:00
if (m_tempObjectList->RemoveValue(newobj))
ret = newobj->Release();
2002-10-12 11:37:38 +00:00
if (m_parentlist->RemoveValue(newobj))
ret = newobj->Release();
if (m_inactivelist->RemoveValue(newobj))
ret = newobj->Release();
2002-10-12 11:37:38 +00:00
if (m_euthanasyobjects->RemoveValue(newobj))
ret = newobj->Release();
if (newobj == m_active_camera)
{
//no AddRef done on m_active_camera so no Release
//m_active_camera->Release();
m_active_camera = NULL;
}
// in case this is a camera
m_cameras.remove((KX_Camera*)newobj);
if (m_sceneConverter)
m_sceneConverter->UnregisterGameObject(newobj);
// return value will be 0 if the object is actually deleted (all reference gone)
return ret;
2002-10-12 11:37:38 +00:00
}
void KX_Scene::ReplaceMesh(class CValue* obj,void* meshobj)
2002-10-12 11:37:38 +00:00
{
KX_GameObject* gameobj = static_cast<KX_GameObject*>(obj);
RAS_MeshObject* mesh = static_cast<RAS_MeshObject*>(meshobj);
if(!gameobj || !mesh)
{
std::cout << "warning: invalid object, mesh will not be replaced" << std::endl;
return;
}
Patch: [ #2439 ] Makes objects react properly to deformations after a mesh replacement call. from brian hayward (bthayward) Detailed description: Currently, when an armature deformed object's mesh is replaced by the ReplaceMesh actuator, the new mesh fails to deform to the armature's movement. My patch fixes this by properly replacing the deform controller along with the mesh (when appropriete). For instance, if one had an animated character using any of the standard deformation techniques (armature, ipo, RVK, or AVK), that character's mesh would currently be prevented from changing mid-game. It could be replaced, but the new mesh would lack the controller which tells it how to deform. If one wanted to dynamiclly add a hat on top of the character's head, it would require storing a secondary prebuilt character (mesh, armature, logic, ect...) on another layer FOR EACH HAT the character could possibly wear, then swapping out the whole character when the hat change was desired. So if you had 4 possible hat/character combos, you would have 4 character meshes, 4 armatures, 4 sets of logic, and so on. I find this lack of flexibility to be unresonable. With my patch, one could accomplish the same thing mearly by making one version of the character in the main layer, and adding an invisible object atop the character's head (which is parented to the head bone). Then whenever it becomes desirable, one can replace the invisible object's mesh with the desirable hat's mesh, then make it visible. With my patch, the hat object would then continue to deform to the character's head regardless of which hat was currently being worn. *note 1* for armature/mesh deformations, the new mesh must have properly assigned vertex groups which match one or more of the bones of the target armature before the replaceMesh call is made. Otherwise the vertices won't react to the armature because they won't know how. (not sure if vertices can be scripted to change groups after the game has started) *note 2* The added processing time involved with replacing the object's deform controller is negligible.
2005-04-18 11:44:21 +00:00
gameobj->RemoveMeshes();
gameobj->AddMesh(mesh);
if (gameobj->m_isDeformable)
{
BL_DeformableGameObject* newobj = static_cast<BL_DeformableGameObject*>( gameobj );
if (newobj->GetDeformer())
{
delete newobj->GetDeformer();
newobj->SetDeformer(NULL);
Patch: [ #2439 ] Makes objects react properly to deformations after a mesh replacement call. from brian hayward (bthayward) Detailed description: Currently, when an armature deformed object's mesh is replaced by the ReplaceMesh actuator, the new mesh fails to deform to the armature's movement. My patch fixes this by properly replacing the deform controller along with the mesh (when appropriete). For instance, if one had an animated character using any of the standard deformation techniques (armature, ipo, RVK, or AVK), that character's mesh would currently be prevented from changing mid-game. It could be replaced, but the new mesh would lack the controller which tells it how to deform. If one wanted to dynamiclly add a hat on top of the character's head, it would require storing a secondary prebuilt character (mesh, armature, logic, ect...) on another layer FOR EACH HAT the character could possibly wear, then swapping out the whole character when the hat change was desired. So if you had 4 possible hat/character combos, you would have 4 character meshes, 4 armatures, 4 sets of logic, and so on. I find this lack of flexibility to be unresonable. With my patch, one could accomplish the same thing mearly by making one version of the character in the main layer, and adding an invisible object atop the character's head (which is parented to the head bone). Then whenever it becomes desirable, one can replace the invisible object's mesh with the desirable hat's mesh, then make it visible. With my patch, the hat object would then continue to deform to the character's head regardless of which hat was currently being worn. *note 1* for armature/mesh deformations, the new mesh must have properly assigned vertex groups which match one or more of the bones of the target armature before the replaceMesh call is made. Otherwise the vertices won't react to the armature because they won't know how. (not sure if vertices can be scripted to change groups after the game has started) *note 2* The added processing time involved with replacing the object's deform controller is negligible.
2005-04-18 11:44:21 +00:00
}
if (mesh->IsDeformed())
{
// we must create a new deformer but which one?
KX_GameObject* parentobj = newobj->GetParent();
// this always return the original game object (also for replicate)
Object* blendobj = newobj->GetBlenderObject();
// object that owns the new mesh
Object* oldblendobj = static_cast<struct Object*>(m_logicmgr->FindBlendObjByGameMeshName(mesh->GetName()));
Mesh* blendmesh = mesh->GetMesh();
BGE: Support mesh modifiers in the game engine. Realtime modifiers applied on mesh objects will be supported in the game engine with the following limitations: - Only real time modifiers are supported (basically all of them!) - Virtual modifiers resulting from parenting are not supported: armature, curve, lattice. You can still use these modifiers (armature is really not recommended) but in non parent mode. The BGE has it's own parenting capability for armature. - Modifiers are computed on the host (using blender modifier stack). - Modifiers are statically evaluated: any possible time dependency in the modifiers is not supported (don't know enough about modifiers to be more specific). - Modifiers are reevaluated if the underlying mesh is deformed due to shape action or armature action. Beware that this is very CPU intensive; modifiers should really be used for static objects only. - Physics is still based on the original mesh: if you have a mirror modifier, the physic shape will be limited to one half of the resulting object. Therefore, the modifiers should preferably be used on graphic objects. - Scripts have no access to the modified mesh. - Modifiers that are based on objects interaction (boolean,..) will not be dependent on the objects position in the GE. What you see in the 3D view is what you get in the GE regardless on the object position, velocity, etc. Besides that, the feature is compatible with all the BGE features that affect meshes: armature action, shape action, relace mesh, VideoTexture, add object, dupligroup. Known problems: - This feature is a bit hacky: the BGE uses the derived mesh draw functions to display the object. This drawing method is a bit slow and is not 100% compatible with the BGE. There may be some problems in multi-texture mode: the multi-texture coordinates are not sent to the GPU. Texface and GLSL on the other hand should be fully supported. - Culling is still based on the extend of the original mesh. If you have a modifer that extends the size of the mesh, the object may disappear while still in the view frustrum. - Derived mesh is not shared between replicas. The derived mesh is allocated and computed for each object with modifiers, regardless if they are static replicas. - Display list are not created on objects with modifiers. I should be able to fix the above problems before release. However, the feature is already useful for game development. Once you are ready to release the game, you can apply the modifiers to get back display list support and mesh sharing capability. MSVC, scons, Cmake, makefile updated. Enjoy /benoit
2009-04-21 11:01:09 +00:00
bool bHasModifier = BL_ModifierDeformer::HasCompatibleDeformer(blendobj);
bool bHasShapeKey = blendmesh->key != NULL && blendmesh->key->type==KEY_RELATIVE;
bool bHasDvert = blendmesh->dvert != NULL;
bool bHasArmature =
parentobj && // current parent is armature
parentobj->GetGameObjectType() == SCA_IObject::OBJ_ARMATURE &&
oldblendobj && // needed for mesh deform
blendobj->parent && // original object had armature (not sure this test is needed)
blendobj->parent->type == OB_ARMATURE &&
blendobj->partype==PARSKEL &&
blendmesh->dvert!=NULL; // mesh has vertex group
bool releaseParent = true;
if (oldblendobj==NULL) {
std::cout << "warning: ReplaceMesh() new mesh is not used in an object from the current scene, you will get incorrect behavior" << std::endl;
BGE: Support mesh modifiers in the game engine. Realtime modifiers applied on mesh objects will be supported in the game engine with the following limitations: - Only real time modifiers are supported (basically all of them!) - Virtual modifiers resulting from parenting are not supported: armature, curve, lattice. You can still use these modifiers (armature is really not recommended) but in non parent mode. The BGE has it's own parenting capability for armature. - Modifiers are computed on the host (using blender modifier stack). - Modifiers are statically evaluated: any possible time dependency in the modifiers is not supported (don't know enough about modifiers to be more specific). - Modifiers are reevaluated if the underlying mesh is deformed due to shape action or armature action. Beware that this is very CPU intensive; modifiers should really be used for static objects only. - Physics is still based on the original mesh: if you have a mirror modifier, the physic shape will be limited to one half of the resulting object. Therefore, the modifiers should preferably be used on graphic objects. - Scripts have no access to the modified mesh. - Modifiers that are based on objects interaction (boolean,..) will not be dependent on the objects position in the GE. What you see in the 3D view is what you get in the GE regardless on the object position, velocity, etc. Besides that, the feature is compatible with all the BGE features that affect meshes: armature action, shape action, relace mesh, VideoTexture, add object, dupligroup. Known problems: - This feature is a bit hacky: the BGE uses the derived mesh draw functions to display the object. This drawing method is a bit slow and is not 100% compatible with the BGE. There may be some problems in multi-texture mode: the multi-texture coordinates are not sent to the GPU. Texface and GLSL on the other hand should be fully supported. - Culling is still based on the extend of the original mesh. If you have a modifer that extends the size of the mesh, the object may disappear while still in the view frustrum. - Derived mesh is not shared between replicas. The derived mesh is allocated and computed for each object with modifiers, regardless if they are static replicas. - Display list are not created on objects with modifiers. I should be able to fix the above problems before release. However, the feature is already useful for game development. Once you are ready to release the game, you can apply the modifiers to get back display list support and mesh sharing capability. MSVC, scons, Cmake, makefile updated. Enjoy /benoit
2009-04-21 11:01:09 +00:00
bHasShapeKey= bHasDvert= bHasArmature=bHasModifier= false;
}
BGE: Support mesh modifiers in the game engine. Realtime modifiers applied on mesh objects will be supported in the game engine with the following limitations: - Only real time modifiers are supported (basically all of them!) - Virtual modifiers resulting from parenting are not supported: armature, curve, lattice. You can still use these modifiers (armature is really not recommended) but in non parent mode. The BGE has it's own parenting capability for armature. - Modifiers are computed on the host (using blender modifier stack). - Modifiers are statically evaluated: any possible time dependency in the modifiers is not supported (don't know enough about modifiers to be more specific). - Modifiers are reevaluated if the underlying mesh is deformed due to shape action or armature action. Beware that this is very CPU intensive; modifiers should really be used for static objects only. - Physics is still based on the original mesh: if you have a mirror modifier, the physic shape will be limited to one half of the resulting object. Therefore, the modifiers should preferably be used on graphic objects. - Scripts have no access to the modified mesh. - Modifiers that are based on objects interaction (boolean,..) will not be dependent on the objects position in the GE. What you see in the 3D view is what you get in the GE regardless on the object position, velocity, etc. Besides that, the feature is compatible with all the BGE features that affect meshes: armature action, shape action, relace mesh, VideoTexture, add object, dupligroup. Known problems: - This feature is a bit hacky: the BGE uses the derived mesh draw functions to display the object. This drawing method is a bit slow and is not 100% compatible with the BGE. There may be some problems in multi-texture mode: the multi-texture coordinates are not sent to the GPU. Texface and GLSL on the other hand should be fully supported. - Culling is still based on the extend of the original mesh. If you have a modifer that extends the size of the mesh, the object may disappear while still in the view frustrum. - Derived mesh is not shared between replicas. The derived mesh is allocated and computed for each object with modifiers, regardless if they are static replicas. - Display list are not created on objects with modifiers. I should be able to fix the above problems before release. However, the feature is already useful for game development. Once you are ready to release the game, you can apply the modifiers to get back display list support and mesh sharing capability. MSVC, scons, Cmake, makefile updated. Enjoy /benoit
2009-04-21 11:01:09 +00:00
if (bHasModifier)
{
BL_ModifierDeformer* modifierDeformer;
if (bHasShapeKey || bHasArmature)
{
modifierDeformer = new BL_ModifierDeformer(
newobj,
oldblendobj, blendobj,
static_cast<BL_SkinMeshObject*>(mesh),
true,
static_cast<BL_ArmatureObject*>( parentobj )
);
releaseParent= false;
modifierDeformer->LoadShapeDrivers(blendobj->parent);
}
else
{
modifierDeformer = new BL_ModifierDeformer(
newobj,
oldblendobj, blendobj,
static_cast<BL_SkinMeshObject*>(mesh),
false,
NULL
);
}
newobj->SetDeformer(modifierDeformer);
}
else if (bHasShapeKey)
{
BL_ShapeDeformer* shapeDeformer;
if (bHasArmature)
{
shapeDeformer = new BL_ShapeDeformer(
newobj,
oldblendobj, blendobj,
static_cast<BL_SkinMeshObject*>(mesh),
true,
BGE: Support mesh modifiers in the game engine. Realtime modifiers applied on mesh objects will be supported in the game engine with the following limitations: - Only real time modifiers are supported (basically all of them!) - Virtual modifiers resulting from parenting are not supported: armature, curve, lattice. You can still use these modifiers (armature is really not recommended) but in non parent mode. The BGE has it's own parenting capability for armature. - Modifiers are computed on the host (using blender modifier stack). - Modifiers are statically evaluated: any possible time dependency in the modifiers is not supported (don't know enough about modifiers to be more specific). - Modifiers are reevaluated if the underlying mesh is deformed due to shape action or armature action. Beware that this is very CPU intensive; modifiers should really be used for static objects only. - Physics is still based on the original mesh: if you have a mirror modifier, the physic shape will be limited to one half of the resulting object. Therefore, the modifiers should preferably be used on graphic objects. - Scripts have no access to the modified mesh. - Modifiers that are based on objects interaction (boolean,..) will not be dependent on the objects position in the GE. What you see in the 3D view is what you get in the GE regardless on the object position, velocity, etc. Besides that, the feature is compatible with all the BGE features that affect meshes: armature action, shape action, relace mesh, VideoTexture, add object, dupligroup. Known problems: - This feature is a bit hacky: the BGE uses the derived mesh draw functions to display the object. This drawing method is a bit slow and is not 100% compatible with the BGE. There may be some problems in multi-texture mode: the multi-texture coordinates are not sent to the GPU. Texface and GLSL on the other hand should be fully supported. - Culling is still based on the extend of the original mesh. If you have a modifer that extends the size of the mesh, the object may disappear while still in the view frustrum. - Derived mesh is not shared between replicas. The derived mesh is allocated and computed for each object with modifiers, regardless if they are static replicas. - Display list are not created on objects with modifiers. I should be able to fix the above problems before release. However, the feature is already useful for game development. Once you are ready to release the game, you can apply the modifiers to get back display list support and mesh sharing capability. MSVC, scons, Cmake, makefile updated. Enjoy /benoit
2009-04-21 11:01:09 +00:00
true,
static_cast<BL_ArmatureObject*>( parentobj )
);
releaseParent= false;
shapeDeformer->LoadShapeDrivers(blendobj->parent);
}
else
{
shapeDeformer = new BL_ShapeDeformer(
newobj,
oldblendobj, blendobj,
static_cast<BL_SkinMeshObject*>(mesh),
false,
BGE: Support mesh modifiers in the game engine. Realtime modifiers applied on mesh objects will be supported in the game engine with the following limitations: - Only real time modifiers are supported (basically all of them!) - Virtual modifiers resulting from parenting are not supported: armature, curve, lattice. You can still use these modifiers (armature is really not recommended) but in non parent mode. The BGE has it's own parenting capability for armature. - Modifiers are computed on the host (using blender modifier stack). - Modifiers are statically evaluated: any possible time dependency in the modifiers is not supported (don't know enough about modifiers to be more specific). - Modifiers are reevaluated if the underlying mesh is deformed due to shape action or armature action. Beware that this is very CPU intensive; modifiers should really be used for static objects only. - Physics is still based on the original mesh: if you have a mirror modifier, the physic shape will be limited to one half of the resulting object. Therefore, the modifiers should preferably be used on graphic objects. - Scripts have no access to the modified mesh. - Modifiers that are based on objects interaction (boolean,..) will not be dependent on the objects position in the GE. What you see in the 3D view is what you get in the GE regardless on the object position, velocity, etc. Besides that, the feature is compatible with all the BGE features that affect meshes: armature action, shape action, relace mesh, VideoTexture, add object, dupligroup. Known problems: - This feature is a bit hacky: the BGE uses the derived mesh draw functions to display the object. This drawing method is a bit slow and is not 100% compatible with the BGE. There may be some problems in multi-texture mode: the multi-texture coordinates are not sent to the GPU. Texface and GLSL on the other hand should be fully supported. - Culling is still based on the extend of the original mesh. If you have a modifer that extends the size of the mesh, the object may disappear while still in the view frustrum. - Derived mesh is not shared between replicas. The derived mesh is allocated and computed for each object with modifiers, regardless if they are static replicas. - Display list are not created on objects with modifiers. I should be able to fix the above problems before release. However, the feature is already useful for game development. Once you are ready to release the game, you can apply the modifiers to get back display list support and mesh sharing capability. MSVC, scons, Cmake, makefile updated. Enjoy /benoit
2009-04-21 11:01:09 +00:00
true,
NULL
);
}
newobj->SetDeformer( shapeDeformer);
}
else if (bHasArmature)
{
BL_SkinDeformer* skinDeformer = new BL_SkinDeformer(
newobj,
oldblendobj, blendobj,
static_cast<BL_SkinMeshObject*>(mesh),
true,
BGE: Support mesh modifiers in the game engine. Realtime modifiers applied on mesh objects will be supported in the game engine with the following limitations: - Only real time modifiers are supported (basically all of them!) - Virtual modifiers resulting from parenting are not supported: armature, curve, lattice. You can still use these modifiers (armature is really not recommended) but in non parent mode. The BGE has it's own parenting capability for armature. - Modifiers are computed on the host (using blender modifier stack). - Modifiers are statically evaluated: any possible time dependency in the modifiers is not supported (don't know enough about modifiers to be more specific). - Modifiers are reevaluated if the underlying mesh is deformed due to shape action or armature action. Beware that this is very CPU intensive; modifiers should really be used for static objects only. - Physics is still based on the original mesh: if you have a mirror modifier, the physic shape will be limited to one half of the resulting object. Therefore, the modifiers should preferably be used on graphic objects. - Scripts have no access to the modified mesh. - Modifiers that are based on objects interaction (boolean,..) will not be dependent on the objects position in the GE. What you see in the 3D view is what you get in the GE regardless on the object position, velocity, etc. Besides that, the feature is compatible with all the BGE features that affect meshes: armature action, shape action, relace mesh, VideoTexture, add object, dupligroup. Known problems: - This feature is a bit hacky: the BGE uses the derived mesh draw functions to display the object. This drawing method is a bit slow and is not 100% compatible with the BGE. There may be some problems in multi-texture mode: the multi-texture coordinates are not sent to the GPU. Texface and GLSL on the other hand should be fully supported. - Culling is still based on the extend of the original mesh. If you have a modifer that extends the size of the mesh, the object may disappear while still in the view frustrum. - Derived mesh is not shared between replicas. The derived mesh is allocated and computed for each object with modifiers, regardless if they are static replicas. - Display list are not created on objects with modifiers. I should be able to fix the above problems before release. However, the feature is already useful for game development. Once you are ready to release the game, you can apply the modifiers to get back display list support and mesh sharing capability. MSVC, scons, Cmake, makefile updated. Enjoy /benoit
2009-04-21 11:01:09 +00:00
true,
static_cast<BL_ArmatureObject*>( parentobj )
);
releaseParent= false;
newobj->SetDeformer(skinDeformer);
}
else if (bHasDvert)
{
BL_MeshDeformer* meshdeformer = new BL_MeshDeformer(
newobj, oldblendobj, static_cast<BL_SkinMeshObject*>(mesh)
);
newobj->SetDeformer(meshdeformer);
}
// release parent reference if its not being used
if( releaseParent && parentobj)
parentobj->Release();
Patch: [ #2439 ] Makes objects react properly to deformations after a mesh replacement call. from brian hayward (bthayward) Detailed description: Currently, when an armature deformed object's mesh is replaced by the ReplaceMesh actuator, the new mesh fails to deform to the armature's movement. My patch fixes this by properly replacing the deform controller along with the mesh (when appropriete). For instance, if one had an animated character using any of the standard deformation techniques (armature, ipo, RVK, or AVK), that character's mesh would currently be prevented from changing mid-game. It could be replaced, but the new mesh would lack the controller which tells it how to deform. If one wanted to dynamiclly add a hat on top of the character's head, it would require storing a secondary prebuilt character (mesh, armature, logic, ect...) on another layer FOR EACH HAT the character could possibly wear, then swapping out the whole character when the hat change was desired. So if you had 4 possible hat/character combos, you would have 4 character meshes, 4 armatures, 4 sets of logic, and so on. I find this lack of flexibility to be unresonable. With my patch, one could accomplish the same thing mearly by making one version of the character in the main layer, and adding an invisible object atop the character's head (which is parented to the head bone). Then whenever it becomes desirable, one can replace the invisible object's mesh with the desirable hat's mesh, then make it visible. With my patch, the hat object would then continue to deform to the character's head regardless of which hat was currently being worn. *note 1* for armature/mesh deformations, the new mesh must have properly assigned vertex groups which match one or more of the bones of the target armature before the replaceMesh call is made. Otherwise the vertices won't react to the armature because they won't know how. (not sure if vertices can be scripted to change groups after the game has started) *note 2* The added processing time involved with replacing the object's deform controller is negligible.
2005-04-18 11:44:21 +00:00
}
}
gameobj->AddMeshUser();
2002-10-12 11:37:38 +00:00
}
KX_Camera* KX_Scene::FindCamera(KX_Camera* cam)
{
list<KX_Camera*>::iterator it = m_cameras.begin();
2002-10-12 11:37:38 +00:00
while ( (it != m_cameras.end())
&& ((*it) != cam) ) {
it++;
}
return ((it == m_cameras.end()) ? NULL : (*it));
}
KX_Camera* KX_Scene::FindCamera(STR_String& name)
{
list<KX_Camera*>::iterator it = m_cameras.begin();
2002-10-12 11:37:38 +00:00
while ( (it != m_cameras.end())
&& ((*it)->GetName() != name) ) {
it++;
}
return ((it == m_cameras.end()) ? NULL : (*it));
}
void KX_Scene::AddCamera(KX_Camera* cam)
{
if (!FindCamera(cam))
m_cameras.push_back(cam);
2002-10-12 11:37:38 +00:00
}
2002-10-12 11:37:38 +00:00
KX_Camera* KX_Scene::GetActiveCamera()
{
// NULL if not defined
return m_active_camera;
}
void KX_Scene::SetActiveCamera(KX_Camera* cam)
{
// only set if the cam is in the active list? Or add it otherwise?
if (!FindCamera(cam)){
AddCamera(cam);
if (cam) std::cout << "Added cam " << cam->GetName() << std::endl;
}
m_active_camera = cam;
}
void KX_Scene::SetCameraOnTop(KX_Camera* cam)
{
if (!FindCamera(cam)){
// adding is always done at the back, so that's all that needs to be done
AddCamera(cam);
if (cam) std::cout << "Added cam " << cam->GetName() << std::endl;
} else {
m_cameras.remove(cam);
m_cameras.push_back(cam);
}
}
2002-10-12 11:37:38 +00:00
void KX_Scene::UpdateMeshTransformations()
{
// do this incrementally in the future
for (int i = 0; i < m_objectlist->GetCount(); i++)
{
KX_GameObject* gameobj = (KX_GameObject*)m_objectlist->GetValue(i);
gameobj->GetOpenGLMatrix();
}
}
void KX_Scene::MarkVisible(SG_Tree *node, RAS_IRasterizer* rasty, KX_Camera* cam, int layer)
2002-10-12 11:37:38 +00:00
{
int intersect = KX_Camera::INTERSECT;
KX_GameObject *gameobj = node->Client()?(KX_GameObject*) node->Client()->GetSGClientObject():NULL;
bool visible = (gameobj && gameobj->GetVisible() && (!layer || (gameobj->GetLayer() & layer)));
bool dotest = visible || node->Left() || node->Right();
/* If the camera is inside the box, assume intersect. */
if (dotest && !node->inside( cam->NodeGetWorldPosition()))
{
MT_Scalar radius = node->Radius();
MT_Point3 center = node->Center();
intersect = cam->SphereInsideFrustum(center, radius);
if (intersect == KX_Camera::INTERSECT)
{
MT_Point3 box[8];
node->get(box);
intersect = cam->BoxInsideFrustum(box);
}
}
switch (intersect)
{
case KX_Camera::OUTSIDE:
MarkSubTreeVisible(node, rasty, false, cam);
break;
case KX_Camera::INTERSECT:
if (gameobj)
MarkVisible(rasty, gameobj, cam, layer);
if (node->Left())
MarkVisible(node->Left(), rasty, cam, layer);
if (node->Right())
MarkVisible(node->Right(), rasty, cam, layer);
break;
case KX_Camera::INSIDE:
MarkSubTreeVisible(node, rasty, true, cam, layer);
break;
}
}
void KX_Scene::MarkSubTreeVisible(SG_Tree *node, RAS_IRasterizer* rasty, bool visible, KX_Camera* cam, int layer)
{
if (node->Client())
{
KX_GameObject *gameobj = (KX_GameObject*) node->Client()->GetSGClientObject();
if (gameobj->GetVisible())
{
if (visible)
{
int nummeshes = gameobj->GetMeshCount();
// this adds the vertices to the display list
for (int m=0;m<nummeshes;m++)
(gameobj->GetMesh(m))->SchedulePolygons(rasty->GetDrawingMode());
}
gameobj->SetCulled(!visible);
gameobj->UpdateBuckets(false);
}
}
if (node->Left())
MarkSubTreeVisible(node->Left(), rasty, visible, cam, layer);
if (node->Right())
MarkSubTreeVisible(node->Right(), rasty, visible, cam, layer);
}
void KX_Scene::MarkVisible(RAS_IRasterizer* rasty, KX_GameObject* gameobj,KX_Camera* cam,int layer)
{
// User (Python/Actuator) has forced object invisible...
if (!gameobj->GetSGNode() || !gameobj->GetVisible())
return;
// Shadow lamp layers
if(layer && !(gameobj->GetLayer() & layer)) {
gameobj->SetCulled(true);
gameobj->UpdateBuckets(false);
return;
}
// If Frustum culling is off, the object is always visible.
bool vis = !cam->GetFrustumCulling();
// If the camera is inside this node, then the object is visible.
if (!vis)
2002-10-12 11:37:38 +00:00
{
vis = gameobj->GetSGNode()->inside( cam->GetCameraLocation() );
}
// Test the object's bound sphere against the view frustum.
if (!vis)
{
MT_Vector3 scale = gameobj->GetSGNode()->GetWorldScaling();
MT_Scalar radius = fabs(scale[scale.closestAxis()] * gameobj->GetSGNode()->Radius());
switch (cam->SphereInsideFrustum(gameobj->NodeGetWorldPosition(), radius))
{
case KX_Camera::INSIDE:
vis = true;
break;
case KX_Camera::OUTSIDE:
vis = false;
break;
case KX_Camera::INTERSECT:
// Test the object's bound box against the view frustum.
MT_Point3 box[8];
gameobj->GetSGNode()->getBBox(box);
vis = cam->BoxInsideFrustum(box) != KX_Camera::OUTSIDE;
break;
}
}
if (vis)
{
int nummeshes = gameobj->GetMeshCount();
2002-10-12 11:37:38 +00:00
for (int m=0;m<nummeshes;m++)
2002-10-12 11:37:38 +00:00
{
// this adds the vertices to the display list
(gameobj->GetMesh(m))->SchedulePolygons(rasty->GetDrawingMode());
2002-10-12 11:37:38 +00:00
}
// Visibility/ non-visibility are marked
// elsewhere now.
gameobj->SetCulled(false);
gameobj->UpdateBuckets(false);
} else {
gameobj->SetCulled(true);
gameobj->UpdateBuckets(false);
}
}
void KX_Scene::PhysicsCullingCallback(KX_ClientObjectInfo* objectInfo, void* cullingInfo)
{
KX_GameObject* gameobj = objectInfo->m_gameobject;
if (!gameobj->GetVisible())
// ideally, invisible objects should be removed from the culling tree temporarily
return;
if(((CullingInfo*)cullingInfo)->m_layer && !(gameobj->GetLayer() & ((CullingInfo*)cullingInfo)->m_layer))
// used for shadow: object is not in shadow layer
return;
// make object visible
gameobj->SetCulled(false);
gameobj->UpdateBuckets(false);
}
void KX_Scene::CalculateVisibleMeshes(RAS_IRasterizer* rasty,KX_Camera* cam, int layer)
{
bool dbvt_culling = false;
if (m_dbvt_culling)
{
// test culling through Bullet
PHY__Vector4 planes[6];
// get the clip planes
MT_Vector4* cplanes = cam->GetNormalizedClipPlanes();
// and convert
planes[0].setValue(cplanes[4].getValue()); // near
planes[1].setValue(cplanes[5].getValue()); // far
planes[2].setValue(cplanes[0].getValue()); // left
planes[3].setValue(cplanes[1].getValue()); // right
planes[4].setValue(cplanes[2].getValue()); // top
planes[5].setValue(cplanes[3].getValue()); // bottom
CullingInfo info(layer);
dbvt_culling = m_physicsEnvironment->cullingTest(PhysicsCullingCallback,&info,planes,5,m_dbvt_occlusion_res);
}
if (!dbvt_culling) {
// the physics engine couldn't help us, do it the hard way
for (int i = 0; i < m_objectlist->GetCount(); i++)
{
MarkVisible(rasty, static_cast<KX_GameObject*>(m_objectlist->GetValue(i)), cam, layer);
}
2002-10-12 11:37:38 +00:00
}
}
// logic stuff
void KX_Scene::LogicBeginFrame(double curtime)
2002-10-12 11:37:38 +00:00
{
// have a look at temp objects ...
int lastobj = m_tempObjectList->GetCount() - 1;
for (int i = lastobj; i >= 0; i--)
{
CValue* objval = m_tempObjectList->GetValue(i);
CFloatValue* propval = (CFloatValue*) objval->GetProperty("::timebomb");
if (propval)
{
float timeleft = propval->GetNumber() - 1.0/KX_KetsjiEngine::GetTicRate();
2002-10-12 11:37:38 +00:00
if (timeleft > 0)
{
propval->SetFloat(timeleft);
}
else
{
DelayedRemoveObject(objval);
// remove obj
}
}
else
{
// all object is the tempObjectList should have a clock
}
}
m_logicmgr->BeginFrame(curtime, 1.0/KX_KetsjiEngine::GetTicRate());
2002-10-12 11:37:38 +00:00
}
void KX_Scene::LogicUpdateFrame(double curtime, bool frame)
2002-10-12 11:37:38 +00:00
{
m_logicmgr->UpdateFrame(curtime, frame);
2002-10-12 11:37:38 +00:00
}
void KX_Scene::LogicEndFrame()
{
m_logicmgr->EndFrame();
int numobj = m_euthanasyobjects->GetCount();
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
KX_GameObject* obj;
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
while ((numobj = m_euthanasyobjects->GetCount()) > 0)
{
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
// remove the object from this list to make sure we will not hit it again
obj = (KX_GameObject*)m_euthanasyobjects->GetValue(numobj-1);
m_euthanasyobjects->Remove(numobj-1);
obj->Release();
RemoveObject(obj);
}
2002-10-12 11:37:38 +00:00
}
/**
* UpdateParents: SceneGraph transformation update.
*/
void KX_Scene::UpdateParents(double curtime)
{
// we use the SG dynamic list
SG_Node* node;
2002-10-12 11:37:38 +00:00
while ((node = SG_Node::GetNextScheduled(m_sghead)) != NULL)
2002-10-12 11:37:38 +00:00
{
node->UpdateWorldData(curtime);
2002-10-12 11:37:38 +00:00
}
//for (int i=0; i<GetRootParentList()->GetCount(); i++)
//{
// KX_GameObject* parentobj = (KX_GameObject*)GetRootParentList()->GetValue(i);
// parentobj->NodeUpdateGS(curtime);
//}
// the list must be empty here
assert(m_sghead.Empty());
// some nodes may be ready for reschedule, move them to schedule list for next time
while ((node = SG_Node::GetNextRescheduled(m_sghead)) != NULL)
{
node->Schedule(m_sghead);
}
}
2002-10-12 11:37:38 +00:00
RAS_MaterialBucket* KX_Scene::FindBucket(class RAS_IPolyMaterial* polymat, bool &bucketCreated)
2002-10-12 11:37:38 +00:00
{
return m_bucketmanager->FindBucket(polymat, bucketCreated);
2002-10-12 11:37:38 +00:00
}
void KX_Scene::RenderBuckets(const MT_Transform & cameratransform,
class RAS_IRasterizer* rasty,
class RAS_IRenderTools* rendertools)
{
m_bucketmanager->Renderbuckets(cameratransform,rasty,rendertools);
KX_BlenderMaterial::EndFrame();
2002-10-12 11:37:38 +00:00
}
void KX_Scene::UpdateObjectActivity(void)
{
if (m_activity_culling) {
/* determine the activity criterium and set objects accordingly */
int i=0;
MT_Point3 camloc = GetActiveCamera()->NodeGetWorldPosition(); //GetCameraLocation();
for (i=0;i<GetObjectList()->GetCount();i++)
{
KX_GameObject* ob = (KX_GameObject*) GetObjectList()->GetValue(i);
if (!ob->GetIgnoreActivityCulling()) {
/* Simple test: more than 10 away from the camera, count
* Manhattan distance. */
MT_Point3 obpos = ob->NodeGetWorldPosition();
if ( (fabs(camloc[0] - obpos[0]) > m_activity_box_radius)
|| (fabs(camloc[1] - obpos[1]) > m_activity_box_radius)
|| (fabs(camloc[2] - obpos[2]) > m_activity_box_radius) )
{
ob->Suspend();
} else {
ob->Resume();
}
}
}
}
}
void KX_Scene::SetActivityCullingRadius(float f)
{
if (f < 0.5)
f = 0.5;
m_activity_box_radius = f;
}
NG_NetworkDeviceInterface* KX_Scene::GetNetworkDeviceInterface()
{
return m_networkDeviceInterface;
}
NG_NetworkScene* KX_Scene::GetNetworkScene()
{
return m_networkScene;
}
void KX_Scene::SetNetworkDeviceInterface(NG_NetworkDeviceInterface* newInterface)
{
m_networkDeviceInterface = newInterface;
}
void KX_Scene::SetNetworkScene(NG_NetworkScene *newScene)
{
m_networkScene = newScene;
}
void KX_Scene::SetGravity(const MT_Vector3& gravity)
{
GetPhysicsEnvironment()->setGravity(gravity[0],gravity[1],gravity[2]);
}
void KX_Scene::SetNodeTree(SG_Tree* root)
{
m_objecttree = root;
}
void KX_Scene::SetSceneConverter(class KX_BlenderSceneConverter* sceneConverter)
{
m_sceneConverter = sceneConverter;
}
void KX_Scene::SetPhysicsEnvironment(class PHY_IPhysicsEnvironment* physEnv)
{
m_physicsEnvironment = physEnv;
KX_TouchEventManager* touchmgr = new KX_TouchEventManager(m_logicmgr, physEnv);
m_logicmgr->RegisterEventManager(touchmgr);
return;
}
void KX_Scene::setSuspendedTime(double suspendedtime)
{
m_suspendedtime = suspendedtime;
}
double KX_Scene::getSuspendedTime()
{
return m_suspendedtime;
}
void KX_Scene::setSuspendedDelta(double suspendeddelta)
{
m_suspendeddelta = suspendeddelta;
}
double KX_Scene::getSuspendedDelta()
{
return m_suspendeddelta;
}
2004-06-07 11:03:12 +00:00
//----------------------------------------------------------------------------
//Python
PyTypeObject KX_Scene::Type = {
#if (PY_VERSION_HEX >= 0x02060000)
PyVarObject_HEAD_INIT(NULL, 0)
#else
/* python 2.5 and below */
PyObject_HEAD_INIT( NULL ) /* required py macro */
0, /* ob_size */
#endif
2004-06-07 11:03:12 +00:00
"KX_Scene",
sizeof(PyObjectPlus_Proxy),
2004-06-07 11:03:12 +00:00
0,
py_base_dealloc,
2004-06-07 11:03:12 +00:00
0,
0,
0,
0,
py_base_repr,
0,0,0,0,0,0,
py_base_getattro,
py_base_setattro,
0,0,0,0,0,0,0,0,0,
Methods
2004-06-07 11:03:12 +00:00
};
PyParentObject KX_Scene::Parents[] = {
&KX_Scene::Type,
&CValue::Type,
NULL
};
PyMethodDef KX_Scene::Methods[] = {
KX_PYMETHODTABLE_NOARGS(KX_Scene, getLightList),
KX_PYMETHODTABLE_NOARGS(KX_Scene, getObjectList),
KX_PYMETHODTABLE_NOARGS(KX_Scene, getName),
KX_PYMETHODTABLE(KX_Scene, addObject),
{NULL,NULL} //Sentinel
};
PyObject* KX_Scene::pyattr_get_name(void *self_v, const KX_PYATTRIBUTE_DEF *attrdef)
{
KX_Scene* self= static_cast<KX_Scene*>(self_v);
return PyString_FromString(self->GetName().ReadPtr());
}
PyObject* KX_Scene::pyattr_get_objects(void *self_v, const KX_PYATTRIBUTE_DEF *attrdef)
{
KX_Scene* self= static_cast<KX_Scene*>(self_v);
return self->GetObjectList()->GetProxy();
}
PyObject* KX_Scene::pyattr_get_objects_inactive(void *self_v, const KX_PYATTRIBUTE_DEF *attrdef)
{
KX_Scene* self= static_cast<KX_Scene*>(self_v);
return self->GetInactiveList()->GetProxy();
}
PyObject* KX_Scene::pyattr_get_lights(void *self_v, const KX_PYATTRIBUTE_DEF *attrdef)
{
KX_Scene* self= static_cast<KX_Scene*>(self_v);
return self->GetLightList()->GetProxy();
}
PyObject* KX_Scene::pyattr_get_cameras(void *self_v, const KX_PYATTRIBUTE_DEF *attrdef)
{
/* With refcounts in this case...
* the new CListValue is owned by python, so its possible python holds onto it longer then the BGE
* however this is the same with "scene.objects + []", when you make a copy by adding lists.
*/
KX_Scene* self= static_cast<KX_Scene*>(self_v);
CListValue* clist = new CListValue();
/* return self->GetCameras()->GetProxy(); */
list<KX_Camera*>::iterator it = self->GetCameras()->begin();
while (it != self->GetCameras()->end()) {
clist->Add((*it)->AddRef());
it++;
}
return clist->NewProxy(true);
}
PyObject* KX_Scene::pyattr_get_active_camera(void *self_v, const KX_PYATTRIBUTE_DEF *attrdef)
{
KX_Scene* self= static_cast<KX_Scene*>(self_v);
return self->GetActiveCamera()->GetProxy();
}
int KX_Scene::pyattr_set_active_camera(void *self_v, const KX_PYATTRIBUTE_DEF *attrdef, PyObject *value)
{
KX_Scene* self= static_cast<KX_Scene*>(self_v);
KX_Camera *camOb;
if (!ConvertPythonToCamera(value, &camOb, false, "scene.active_camera = value: KX_Scene"))
return PY_SET_ATTR_FAIL;
self->SetActiveCamera(camOb);
return PY_SET_ATTR_SUCCESS;
}
PyAttributeDef KX_Scene::Attributes[] = {
KX_PYATTRIBUTE_RO_FUNCTION("name", KX_Scene, pyattr_get_name),
KX_PYATTRIBUTE_RO_FUNCTION("objects", KX_Scene, pyattr_get_objects),
Name attributes added since 2.48a more consistently. BL_ActionActuator::blendin -> blendIn BL_ActionActuator::end -> frameEnd BL_ActionActuator::property -> propName BL_ActionActuator::start -> frameStart BL_ActionActuator::type -> mode BL_ShapeActionActuator::blendin -> blendIn BL_ShapeActionActuator::end -> frameEnd BL_ShapeActionActuator::frameProperty -> framePropName BL_ShapeActionActuator::property -> propName BL_ShapeActionActuator::start -> frameStart BL_ShapeActionActuator::type -> mode KX_CameraActuator::xy -> useXY KX_ConstraintActuator::property -> propName KX_GameActuator::file -> fileName KX_GameObject::localScaling -> localScaling KX_GameObject::worldScaling -> worldScaling KX_IpoActuator::endFrame -> frameEnd KX_IpoActuator::startFrame -> frameStart KX_IpoActuator::type -> mode KX_RaySensor::property -> propName KX_SCA_DynamicActuator::operation -> mode KX_Scene::objects_inactive -> objectsInactive KX_SoundActuator::filename -> fileName KX_SoundActuator::type -> mode KX_TouchSensor::objectHit -> hitObject KX_TouchSensor::objectHitList -> hitObjectList KX_TouchSensor::property -> propName KX_TouchSensor::pulseCollisions -> usePulseCollision KX_VisibilityActuator::occlusion -> useOcclusion KX_VisibilityActuator::recursion -> useRecursion SCA_2DFilterActuator::passNb -> passNumber SCA_PropertyActuator::property -> propName SCA_PropertyActuator::type -> mode SCA_PropertySensor::property -> propName SCA_PropertySensor::type -> mode SCA_RandomActuator::property -> propName
2009-05-15 03:26:53 +00:00
KX_PYATTRIBUTE_RO_FUNCTION("objectsInactive", KX_Scene, pyattr_get_objects_inactive), KX_PYATTRIBUTE_RO_FUNCTION("lights", KX_Scene, pyattr_get_lights),
KX_PYATTRIBUTE_RO_FUNCTION("cameras", KX_Scene, pyattr_get_cameras),
KX_PYATTRIBUTE_RO_FUNCTION("lights", KX_Scene, pyattr_get_lights),
KX_PYATTRIBUTE_RW_FUNCTION("active_camera", KX_Scene, pyattr_get_active_camera, pyattr_set_active_camera),
KX_PYATTRIBUTE_BOOL_RO("suspended", KX_Scene, m_suspend),
KX_PYATTRIBUTE_BOOL_RO("activity_culling", KX_Scene, m_activity_culling),
KX_PYATTRIBUTE_FLOAT_RW("activity_culling_radius", 0.5f, FLT_MAX, KX_Scene, m_activity_box_radius),
KX_PYATTRIBUTE_BOOL_RO("dbvt_culling", KX_Scene, m_dbvt_culling),
{ NULL } //Sentinel
};
PyObject* KX_Scene::py_getattro__internal(PyObject *attr)
{
py_getattro_up(PyObjectPlus);
}
int KX_Scene::py_setattro__internal(PyObject *attr, PyObject *value)
{
py_setattro_up(PyObjectPlus);
}
PyObject* KX_Scene::py_getattro(PyObject *attr)
2004-06-07 11:03:12 +00:00
{
PyObject *object = py_getattro__internal(attr);
if (object==NULL)
2004-06-07 11:03:12 +00:00
{
PyErr_Clear();
object = PyDict_GetItem(m_attr_dict, attr);
if(object) {
Py_INCREF(object);
}
else {
PyErr_Format(PyExc_AttributeError, "value = scene.myAttr: KX_Scene, attribute \"%s\" not found", PyString_AsString(attr));
}
2004-06-07 11:03:12 +00:00
}
return object;
2004-06-07 11:03:12 +00:00
}
PyObject* KX_Scene::py_getattro_dict() {
//py_getattro_dict_up(PyObjectPlus);
PyObject *dict= py_getattr_dict(PyObjectPlus::py_getattro_dict(), Type.tp_dict);
if(dict==NULL)
return NULL;
/* normally just return this but KX_Scene has some more items */
PyDict_Update(dict, m_attr_dict);
return dict;
}
int KX_Scene::py_setattro(PyObject *attr, PyObject *value)
{
int ret= py_setattro__internal(attr, value);
if (ret==PY_SET_ATTR_MISSING) {
if (PyDict_SetItem(m_attr_dict, attr, value)==0) {
PyErr_Clear();
ret= PY_SET_ATTR_SUCCESS;
}
else {
PyErr_SetString(PyExc_AttributeError, "scene.UserAttr = value: KX_Scenes, failed assigning value to internal dictionary");
ret= PY_SET_ATTR_FAIL;
}
}
return ret;
}
int KX_Scene::py_delattro(PyObject *attr)
2004-06-07 11:03:12 +00:00
{
PyDict_DelItem(m_attr_dict, attr);
return 0;
2004-06-07 11:03:12 +00:00
}
KX_PYMETHODDEF_DOC_NOARGS(KX_Scene, getLightList,
2004-06-07 11:03:12 +00:00
"getLightList() -> list [KX_Light]\n"
"Returns a list of all lights in the scene.\n"
)
{
ShowDeprecationWarning("getLightList()", "the lights property");
return m_lightlist->GetProxy();
2004-06-07 11:03:12 +00:00
}
KX_PYMETHODDEF_DOC_NOARGS(KX_Scene, getObjectList,
2004-06-07 11:03:12 +00:00
"getObjectList() -> list [KX_GameObject]\n"
"Returns a list of all game objects in the scene.\n"
)
{
ShowDeprecationWarning("getObjectList()", "the objects property");
return m_objectlist->GetProxy();
2004-06-07 11:03:12 +00:00
}
KX_PYMETHODDEF_DOC_NOARGS(KX_Scene, getName,
2004-06-07 11:03:12 +00:00
"getName() -> string\n"
"Returns the name of the scene.\n"
)
{
ShowDeprecationWarning("getName()", "the name property");
2004-06-07 11:03:12 +00:00
return PyString_FromString(GetName());
}
KX_PYMETHODDEF_DOC(KX_Scene, addObject,
"addObject(object, other, time=0)\n"
"Returns the added object.\n")
{
PyObject *pyob, *pyother;
KX_GameObject *ob, *other;
int time = 0;
if (!PyArg_ParseTuple(args, "OO|i:addObject", &pyob, &pyother, &time))
return NULL;
if ( !ConvertPythonToGameObject(pyob, &ob, false, "scene.addObject(object, other, time): KX_Scene (first argument)") ||
!ConvertPythonToGameObject(pyother, &other, false, "scene.addObject(object, other, time): KX_Scene (second argument)") )
return NULL;
SCA_IObject* replica = AddReplicaObject((SCA_IObject*)ob, other, time);
// release here because AddReplicaObject AddRef's
// the object is added to the scene so we dont want python to own a reference
replica->Release();
return replica->GetProxy();
}