blender/source/gameengine/Ketsji/KX_Scene.cpp

2403 lines
66 KiB
C++
Raw Normal View History

2002-10-12 11:37:38 +00:00
/*
* ***** BEGIN GPL LICENSE BLOCK *****
2002-10-12 11:37:38 +00:00
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
2002-10-12 11:37:38 +00:00
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software Foundation,
2010-02-12 13:34:04 +00:00
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
2002-10-12 11:37:38 +00:00
*
* The Original Code is Copyright (C) 2001-2002 by NaN Holding BV.
* All rights reserved.
*
* The Original Code is: all of this file.
*
* Contributor(s): none yet.
*
* ***** END GPL LICENSE BLOCK *****
2002-10-12 11:37:38 +00:00
* Ketsji scene. Holds references to all scene data.
*/
2011-02-25 13:35:59 +00:00
/** \file gameengine/Ketsji/KX_Scene.cpp
* \ingroup ketsji
*/
#if defined(WIN32) && !defined(FREE_WINDOWS)
2002-10-12 11:37:38 +00:00
#pragma warning (disable : 4786)
#endif //WIN32
#include "KX_Scene.h"
#include "KX_PythonInit.h"
2005-01-23 01:36:29 +00:00
#include "MT_assert.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"
2002-10-12 11:37:38 +00:00
#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"
#include "SCA_BasicEventManager.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"
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 "BL_System.h"
2002-10-12 11:37:38 +00:00
#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"
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
#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"
#include "KX_ObstacleSimulation.h"
#ifdef USE_BULLET
#include "KX_SoftBodyDeformer.h"
#include "KX_ConvertPhysicsObject.h"
#include "CcdPhysicsEnvironment.h"
#include "CcdPhysicsController.h"
#endif
2002-10-12 11:37:38 +00:00
#include "KX_Light.h"
#include <stdio.h>
static void *KX_SceneReplicationFunc(SG_IObject* node,void* gameobj,void* scene)
2002-10-12 11:37:38 +00:00
{
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;
}
static void *KX_SceneDestructionFunc(SG_IObject* node,void* gameobj,void* scene)
2002-10-12 11:37:38 +00:00
{
((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,
const STR_String& sceneName,
Scene *scene,
class RAS_ICanvas* canvas):
PyObjectPlus(),
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_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_animatedlist = new CListValue();
2002-10-12 11:37:38 +00:00
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, canvas);
2002-10-12 11:37:38 +00:00
//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);
//SCA_RandomEventManager* rndmgr = new SCA_RandomEventManager(m_logicmgr);
SCA_BasicEventManager* basicmgr = new SCA_BasicEventManager(m_logicmgr);
//KX_RayEventManager* raymgr = new KX_RayEventManager(m_logicmgr);
2002-10-12 11:37:38 +00:00
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);
2002-10-12 11:37:38 +00:00
m_logicmgr->RegisterEventManager(netmgr);
m_logicmgr->RegisterEventManager(basicmgr);
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
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
bool showObstacleSimulation = scene->gm.flag & GAME_SHOW_OBSTACLE_SIMULATION;
switch (scene->gm.obstacleSimulation)
{
case OBSTSIMULATION_TOI_rays:
m_obstacleSimulation = new KX_ObstacleSimulationTOI_rays((MT_Scalar)scene->gm.levelHeight, showObstacleSimulation);
break;
case OBSTSIMULATION_TOI_cells:
m_obstacleSimulation = new KX_ObstacleSimulationTOI_cells((MT_Scalar)scene->gm.levelHeight, showObstacleSimulation);
break;
default:
m_obstacleSimulation = NULL;
}
#ifdef WITH_PYTHON
m_attr_dict = PyDict_New(); /* new ref */
m_draw_call_pre = NULL;
m_draw_call_post = NULL;
#endif
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_obstacleSimulation)
delete m_obstacleSimulation;
if (m_objectlist)
2002-10-12 11:37:38 +00:00
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
if (m_animatedlist)
m_animatedlist->Release();
2002-10-12 11:37:38 +00:00
if (m_logicmgr)
delete m_logicmgr;
if (m_physicsEnvironment)
delete m_physicsEnvironment;
if (m_networkScene)
delete m_networkScene;
if (m_bucketmanager)
{
delete m_bucketmanager;
}
#ifdef WITH_PYTHON
PyDict_Clear(m_attr_dict);
/* Py_CLEAR: Py_DECREF's and NULL's */
Py_CLEAR(m_attr_dict);
/* these may be NULL but the macro checks */
Py_CLEAR(m_draw_call_pre);
Py_CLEAR(m_draw_call_post);
#endif
2002-10-12 11:37:38 +00:00
}
RAS_BucketManager* KX_Scene::GetBucketManager()
{
return m_bucketmanager;
}
CListValue* KX_Scene::GetTempObjectList()
{
return m_tempObjectList;
}
2002-10-12 11:37:38 +00:00
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;
}
Patch:[#25163] BGE support for Blender Font objects - unicode support Problem/Bug: ------------ There were no way to have proper unicode characters (e.g. Japanese) in Blender Game Engine. Now we can :) You can see a sample here: http://blog.mikepan.com/multi-language-support-in-blender/ Functionality Explanation: -------------------------- This patch converts the Blender Font Objects to a new BGE type: KX_FontObject This object inherits KX_GameObject.cpp and has the following properties: - text (the text of the object) - size (taken from the Blender object, usually is 1.0) - resolution (1.0 by default, maybe not really needed, but at least for debugging/the time being it's nice to have) The way we deal with linked objects is different than Blender. In Blender the text and size are a property of the Text databock. Therefore linked objects necessarily share the same text (and size, although the size of the object datablock affects that too). In BGE they are stored and accessed per object. Without that it would be problematic to have addObject adding texts that don't share the same data. Known problems/limitations/ToDo: -------------------------------- 1) support for packed font and the <builtin> 2) figure why some fonts are displayed in a different size in 3DView/BGE (BLF) 3) investigate some glitches I see some times 4) support for multiline 5) support for more Blender Font Object options (text aligment, text boxes, ...) [1] Diego (bdiego) evantually will help on that. For the time being we are using the "default" (ui) font to replace the <builtin>. [2] but not all of them. I need to cross check who is calculating the size/dpi in/correctly - Blender or BLF. (e.g. fonts that work well - MS Gothic) [3] I think this may be related to the resolution we are drawing the font [4] It can't/will not be handled inside BFL. So the way I see it is to implement a mini text library/api that works as a middlelayer between the drawing step and BLF. So instead of: BLF_draw(fontid, (char *)text, strlen(text)); We would do: MAGIC_ROUTINE_IM_NOT_BLF_draw(fontir, (char *)text, styleflag, width, height); [5] don't hold your breath ... but if someone wants to have fun in the holidays the (4) and (5) are part of the same problem. Code Explanation: ----------------- The patch should be simple to read. They are three may parts: 1) BL_BlenderDataConversion.cpp:: converts the OB_FONT object into a KX_FontObject.cpp and store it in the KX_Scene->m_fonts 2) KetsjiEngine.cpp::RenderFonts:: loop through the texts and call their internal drawing routine. 3) KX_FontObject.cpp:: a) constructor: load the font of the object, and store other values. b) DrawText: calculate the aspect for the given size (sounds hacky but this is how blf works) and call the render routine in RenderTools 4) KX_BlenderGL.cpp (called from rendertools) ::BL_print_game_line:: Draws the text. Using the BLF API *) In order to handle visibility of the object added with AddObject I'm adding to the m_scene.m_fonts list only the Fonts in a visible layer - unlike Cameras and Lamps where all the objects are added. Acknowledgements: ---------------- Thanks Benoit for the review and adjustment suggestions. Thanks Diego for the BFL expertise, patches and support (Latin community ftw) Thanks my boss for letting me do part of this patch during work time. Good thing we are starting a project in a partnership with a Japanese Foundation and eventual will need unicode in BGE :) for more details on that - www.nereusprogram.org - let's call it the main sponsor of this "bug feature" ;)
2010-12-16 10:25:41 +00:00
list<class KX_FontObject*>* KX_Scene::GetFonts()
{
return &m_fonts;
}
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 guaranteed to be sensible
2002-10-12 11:37:38 +00:00
* if you don't call the above function.
*/
const RAS_FrameSettings& KX_Scene::GetFramingType() const
{
return m_frame_settings;
2012-09-16 04:58:18 +00:00
};
2002-10-12 11:37:38 +00:00
/**
* 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;
}
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)
{
2012-09-16 04:58:18 +00:00
KX_GameObject* orgobj = (KX_GameObject*)gameobj;
if (NewRemoveObject(orgobj) != 0)
{
// 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());
if (newobj->GetGameObjectType()==SCA_IObject::OBJ_LIGHT)
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
2010-04-25 15:24:18 +00:00
// the replicated object is preserved: it 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
// 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)
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* 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
replica->ActivateGraphicController(true);
// set references for dupli-group
// groupobj holds a list of all objects, that belongs to this group
groupobj->AddInstanceObjects(replica);
// every object gets the reference to its dupli-group object
replica->SetDupliGroupObject(groupobj);
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)->GetGameObjectType()==SCA_IObject::OBJ_LIGHT)
{
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());
// this convert the life from frames to sort-of seconds, hard coded 0.02 that assumes we have 50 frames per second
// if you change this value, make sure you change it in KX_GameObject::pyattr_get_life property too
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
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)->GetGameObjectType()==SCA_IObject::OBJ_LIGHT)
{
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;
/* 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();
2002-10-12 11:37:38 +00:00
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++)
{
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);
}
}
// if the object is the dupligroup proxy, you have to cleanup all m_pDupliGroupObject's in all
// instances refering to this group
if(newobj->GetInstanceObjects()) {
for (int i = 0; i < newobj->GetInstanceObjects()->GetCount(); i++) {
KX_GameObject* instance = (KX_GameObject*)newobj->GetInstanceObjects()->GetValue(i);
instance->RemoveDupliGroupObject();
}
}
// if this object was part of a group, make sure to remove it from that group's instance list
KX_GameObject* group = newobj->GetDupliGroupObject();
if (group)
group->RemoveInstanceObject(newobj);
2002-10-12 11:37:38 +00:00
newobj->RemoveMeshes();
ret = 1;
if (newobj->GetGameObjectType()==SCA_IObject::OBJ_LIGHT && 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 (m_animatedlist->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);
Patch:[#25163] BGE support for Blender Font objects - unicode support Problem/Bug: ------------ There were no way to have proper unicode characters (e.g. Japanese) in Blender Game Engine. Now we can :) You can see a sample here: http://blog.mikepan.com/multi-language-support-in-blender/ Functionality Explanation: -------------------------- This patch converts the Blender Font Objects to a new BGE type: KX_FontObject This object inherits KX_GameObject.cpp and has the following properties: - text (the text of the object) - size (taken from the Blender object, usually is 1.0) - resolution (1.0 by default, maybe not really needed, but at least for debugging/the time being it's nice to have) The way we deal with linked objects is different than Blender. In Blender the text and size are a property of the Text databock. Therefore linked objects necessarily share the same text (and size, although the size of the object datablock affects that too). In BGE they are stored and accessed per object. Without that it would be problematic to have addObject adding texts that don't share the same data. Known problems/limitations/ToDo: -------------------------------- 1) support for packed font and the <builtin> 2) figure why some fonts are displayed in a different size in 3DView/BGE (BLF) 3) investigate some glitches I see some times 4) support for multiline 5) support for more Blender Font Object options (text aligment, text boxes, ...) [1] Diego (bdiego) evantually will help on that. For the time being we are using the "default" (ui) font to replace the <builtin>. [2] but not all of them. I need to cross check who is calculating the size/dpi in/correctly - Blender or BLF. (e.g. fonts that work well - MS Gothic) [3] I think this may be related to the resolution we are drawing the font [4] It can't/will not be handled inside BFL. So the way I see it is to implement a mini text library/api that works as a middlelayer between the drawing step and BLF. So instead of: BLF_draw(fontid, (char *)text, strlen(text)); We would do: MAGIC_ROUTINE_IM_NOT_BLF_draw(fontir, (char *)text, styleflag, width, height); [5] don't hold your breath ... but if someone wants to have fun in the holidays the (4) and (5) are part of the same problem. Code Explanation: ----------------- The patch should be simple to read. They are three may parts: 1) BL_BlenderDataConversion.cpp:: converts the OB_FONT object into a KX_FontObject.cpp and store it in the KX_Scene->m_fonts 2) KetsjiEngine.cpp::RenderFonts:: loop through the texts and call their internal drawing routine. 3) KX_FontObject.cpp:: a) constructor: load the font of the object, and store other values. b) DrawText: calculate the aspect for the given size (sounds hacky but this is how blf works) and call the render routine in RenderTools 4) KX_BlenderGL.cpp (called from rendertools) ::BL_print_game_line:: Draws the text. Using the BLF API *) In order to handle visibility of the object added with AddObject I'm adding to the m_scene.m_fonts list only the Fonts in a visible layer - unlike Cameras and Lamps where all the objects are added. Acknowledgements: ---------------- Thanks Benoit for the review and adjustment suggestions. Thanks Diego for the BFL expertise, patches and support (Latin community ftw) Thanks my boss for letting me do part of this patch during work time. Good thing we are starting a project in a partnership with a Japanese Foundation and eventual will need unicode in BGE :) for more details on that - www.nereusprogram.org - let's call it the main sponsor of this "bug feature" ;)
2010-12-16 10:25:41 +00:00
// in case this is a font
m_fonts.remove((KX_FontObject*)newobj);
/* currently does nothing, keep in case we need to Unregister something */
#if 0
if (m_sceneConverter)
m_sceneConverter->UnregisterGameObject(newobj);
#endif
// 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, bool use_gfx, bool use_phys)
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) {
std::cout << "KX_Scene::ReplaceMesh Warning: invalid object, doing nothing" << 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
if (use_gfx && mesh != NULL)
2012-09-16 04:58:18 +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->GetMesh())
{
// 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();
bool bHasModifier = BL_ModifierDeformer::HasCompatibleDeformer(blendobj);
bool bHasShapeKey = blendmesh->key != NULL && blendmesh->key->type==KEY_RELATIVE;
bool bHasDvert = blendmesh->dvert != NULL;
bool bHasArmature =
BL_ModifierDeformer::HasArmatureDeformer(blendobj) &&
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 &&
blendmesh->dvert!=NULL; // mesh has vertex group
#ifdef USE_BULLET
bool bHasSoftBody = (!parentobj && (blendobj->gameflag & OB_SOFT_BODY));
#endif
bool releaseParent = true;
if (oldblendobj==NULL) {
if (bHasModifier || bHasShapeKey || bHasDvert || bHasArmature) {
std::cout << "warning: ReplaceMesh() new mesh is not used in an object from the current scene, you will get incorrect behavior" << std::endl;
bHasShapeKey= bHasDvert= bHasArmature=bHasModifier= false;
}
}
if (bHasModifier)
{
BL_ModifierDeformer* modifierDeformer;
if (bHasShapeKey || bHasArmature)
{
modifierDeformer = new BL_ModifierDeformer(
newobj,
m_blenderScene,
oldblendobj, blendobj,
mesh,
true,
static_cast<BL_ArmatureObject*>( parentobj )
);
releaseParent= false;
modifierDeformer->LoadShapeDrivers(blendobj->parent);
}
else
{
modifierDeformer = new BL_ModifierDeformer(
newobj,
m_blenderScene,
oldblendobj, blendobj,
mesh,
false,
NULL
);
}
newobj->SetDeformer(modifierDeformer);
}
else if (bHasShapeKey)
{
BL_ShapeDeformer* shapeDeformer;
if (bHasArmature)
{
shapeDeformer = new BL_ShapeDeformer(
newobj,
oldblendobj, blendobj,
mesh,
true,
true,
static_cast<BL_ArmatureObject*>( parentobj )
);
releaseParent= false;
shapeDeformer->LoadShapeDrivers(blendobj->parent);
}
else
{
shapeDeformer = new BL_ShapeDeformer(
newobj,
oldblendobj, blendobj,
mesh,
false,
true,
NULL
);
}
newobj->SetDeformer( shapeDeformer);
}
else if (bHasArmature)
{
BL_SkinDeformer* skinDeformer = new BL_SkinDeformer(
newobj,
oldblendobj, blendobj,
mesh,
true,
true,
static_cast<BL_ArmatureObject*>( parentobj )
);
releaseParent= false;
newobj->SetDeformer(skinDeformer);
}
else if (bHasDvert)
{
BL_MeshDeformer* meshdeformer = new BL_MeshDeformer(
newobj, oldblendobj, mesh
);
newobj->SetDeformer(meshdeformer);
}
#ifdef USE_BULLET
else if (bHasSoftBody)
{
KX_SoftBodyDeformer *softdeformer = new KX_SoftBodyDeformer(mesh, newobj);
newobj->SetDeformer(softdeformer);
}
#endif
// 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();
}
#ifdef USE_BULLET
if (use_phys) { /* update the new assigned mesh with the physics mesh */
KX_ReInstanceBulletShapeFromMesh(gameobj, NULL, use_gfx?NULL:mesh);
}
#endif
2002-10-12 11:37:38 +00:00
}
Patch:[#25163] BGE support for Blender Font objects - unicode support Problem/Bug: ------------ There were no way to have proper unicode characters (e.g. Japanese) in Blender Game Engine. Now we can :) You can see a sample here: http://blog.mikepan.com/multi-language-support-in-blender/ Functionality Explanation: -------------------------- This patch converts the Blender Font Objects to a new BGE type: KX_FontObject This object inherits KX_GameObject.cpp and has the following properties: - text (the text of the object) - size (taken from the Blender object, usually is 1.0) - resolution (1.0 by default, maybe not really needed, but at least for debugging/the time being it's nice to have) The way we deal with linked objects is different than Blender. In Blender the text and size are a property of the Text databock. Therefore linked objects necessarily share the same text (and size, although the size of the object datablock affects that too). In BGE they are stored and accessed per object. Without that it would be problematic to have addObject adding texts that don't share the same data. Known problems/limitations/ToDo: -------------------------------- 1) support for packed font and the <builtin> 2) figure why some fonts are displayed in a different size in 3DView/BGE (BLF) 3) investigate some glitches I see some times 4) support for multiline 5) support for more Blender Font Object options (text aligment, text boxes, ...) [1] Diego (bdiego) evantually will help on that. For the time being we are using the "default" (ui) font to replace the <builtin>. [2] but not all of them. I need to cross check who is calculating the size/dpi in/correctly - Blender or BLF. (e.g. fonts that work well - MS Gothic) [3] I think this may be related to the resolution we are drawing the font [4] It can't/will not be handled inside BFL. So the way I see it is to implement a mini text library/api that works as a middlelayer between the drawing step and BLF. So instead of: BLF_draw(fontid, (char *)text, strlen(text)); We would do: MAGIC_ROUTINE_IM_NOT_BLF_draw(fontir, (char *)text, styleflag, width, height); [5] don't hold your breath ... but if someone wants to have fun in the holidays the (4) and (5) are part of the same problem. Code Explanation: ----------------- The patch should be simple to read. They are three may parts: 1) BL_BlenderDataConversion.cpp:: converts the OB_FONT object into a KX_FontObject.cpp and store it in the KX_Scene->m_fonts 2) KetsjiEngine.cpp::RenderFonts:: loop through the texts and call their internal drawing routine. 3) KX_FontObject.cpp:: a) constructor: load the font of the object, and store other values. b) DrawText: calculate the aspect for the given size (sounds hacky but this is how blf works) and call the render routine in RenderTools 4) KX_BlenderGL.cpp (called from rendertools) ::BL_print_game_line:: Draws the text. Using the BLF API *) In order to handle visibility of the object added with AddObject I'm adding to the m_scene.m_fonts list only the Fonts in a visible layer - unlike Cameras and Lamps where all the objects are added. Acknowledgements: ---------------- Thanks Benoit for the review and adjustment suggestions. Thanks Diego for the BFL expertise, patches and support (Latin community ftw) Thanks my boss for letting me do part of this patch during work time. Good thing we are starting a project in a partnership with a Japanese Foundation and eventual will need unicode in BGE :) for more details on that - www.nereusprogram.org - let's call it the main sponsor of this "bug feature" ;)
2010-12-16 10:25:41 +00:00
/* Font Object routines */
void KX_Scene::AddFont(KX_FontObject* font)
{
if (!FindFont(font))
m_fonts.push_back(font);
2002-10-12 11:37:38 +00:00
}
Patch:[#25163] BGE support for Blender Font objects - unicode support Problem/Bug: ------------ There were no way to have proper unicode characters (e.g. Japanese) in Blender Game Engine. Now we can :) You can see a sample here: http://blog.mikepan.com/multi-language-support-in-blender/ Functionality Explanation: -------------------------- This patch converts the Blender Font Objects to a new BGE type: KX_FontObject This object inherits KX_GameObject.cpp and has the following properties: - text (the text of the object) - size (taken from the Blender object, usually is 1.0) - resolution (1.0 by default, maybe not really needed, but at least for debugging/the time being it's nice to have) The way we deal with linked objects is different than Blender. In Blender the text and size are a property of the Text databock. Therefore linked objects necessarily share the same text (and size, although the size of the object datablock affects that too). In BGE they are stored and accessed per object. Without that it would be problematic to have addObject adding texts that don't share the same data. Known problems/limitations/ToDo: -------------------------------- 1) support for packed font and the <builtin> 2) figure why some fonts are displayed in a different size in 3DView/BGE (BLF) 3) investigate some glitches I see some times 4) support for multiline 5) support for more Blender Font Object options (text aligment, text boxes, ...) [1] Diego (bdiego) evantually will help on that. For the time being we are using the "default" (ui) font to replace the <builtin>. [2] but not all of them. I need to cross check who is calculating the size/dpi in/correctly - Blender or BLF. (e.g. fonts that work well - MS Gothic) [3] I think this may be related to the resolution we are drawing the font [4] It can't/will not be handled inside BFL. So the way I see it is to implement a mini text library/api that works as a middlelayer between the drawing step and BLF. So instead of: BLF_draw(fontid, (char *)text, strlen(text)); We would do: MAGIC_ROUTINE_IM_NOT_BLF_draw(fontir, (char *)text, styleflag, width, height); [5] don't hold your breath ... but if someone wants to have fun in the holidays the (4) and (5) are part of the same problem. Code Explanation: ----------------- The patch should be simple to read. They are three may parts: 1) BL_BlenderDataConversion.cpp:: converts the OB_FONT object into a KX_FontObject.cpp and store it in the KX_Scene->m_fonts 2) KetsjiEngine.cpp::RenderFonts:: loop through the texts and call their internal drawing routine. 3) KX_FontObject.cpp:: a) constructor: load the font of the object, and store other values. b) DrawText: calculate the aspect for the given size (sounds hacky but this is how blf works) and call the render routine in RenderTools 4) KX_BlenderGL.cpp (called from rendertools) ::BL_print_game_line:: Draws the text. Using the BLF API *) In order to handle visibility of the object added with AddObject I'm adding to the m_scene.m_fonts list only the Fonts in a visible layer - unlike Cameras and Lamps where all the objects are added. Acknowledgements: ---------------- Thanks Benoit for the review and adjustment suggestions. Thanks Diego for the BFL expertise, patches and support (Latin community ftw) Thanks my boss for letting me do part of this patch during work time. Good thing we are starting a project in a partnership with a Japanese Foundation and eventual will need unicode in BGE :) for more details on that - www.nereusprogram.org - let's call it the main sponsor of this "bug feature" ;)
2010-12-16 10:25:41 +00:00
KX_FontObject* KX_Scene::FindFont(KX_FontObject* font)
{
list<KX_FontObject*>::iterator it = m_fonts.begin();
while ( (it != m_fonts.end())
&& ((*it) != font) ) {
++it;
}
return ((it == m_fonts.end()) ? NULL : (*it));
}
/* Camera Object routines */
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++;
2002-10-12 11:37:38 +00:00
}
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++;
2002-10-12 11:37:38 +00:00
}
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()
2012-09-16 04:58:18 +00:00
{
2002-10-12 11:37:38 +00:00
// 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?
2012-03-28 05:03:24 +00:00
if (!FindCamera(cam)) {
2002-10-12 11:37:38 +00:00
AddCamera(cam);
if (cam) std::cout << "Added cam " << cam->GetName() << std::endl;
}
m_active_camera = cam;
}
void KX_Scene::SetCameraOnTop(KX_Camera* cam)
{
2012-03-28 05:03:24 +00:00
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);
double mvmat[16] = {0};
cam->GetModelviewMatrix().getValue(mvmat);
double pmat[16] = {0};
cam->GetProjectionMatrix().getValue(pmat);
dbvt_culling = m_physicsEnvironment->cullingTest(PhysicsCullingCallback,&info,planes,5,m_dbvt_occlusion_res,
KX_GetActiveEngine()->GetCanvas()->GetViewPort(),
mvmat, pmat);
}
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::AddAnimatedObject(CValue* gameobj)
{
gameobj->AddRef();
m_animatedlist->Add(gameobj);
}
2002-10-12 11:37:38 +00:00
void KX_Scene::RemoveAnimatedObject(CValue* gameobj)
{
m_animatedlist->RemoveValue(gameobj);
}
void KX_Scene::UpdateAnimations(double curtime)
2002-10-12 11:37:38 +00:00
{
// Update any animations
for (int i=0; i<m_animatedlist->GetCount(); ++i)
((KX_GameObject*)m_animatedlist->GetValue(i))->UpdateActionManager(curtime);
}
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;
KX_GameObject* obj;
while ((numobj = m_euthanasyobjects->GetCount()) > 0)
{
// 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);
}
//prepare obstacle simulation for new frame
if (m_obstacleSimulation)
m_obstacleSimulation->UpdateObstacles();
2002-10-12 11:37:38 +00:00
}
/**
2012-03-09 18:28:30 +00:00
* UpdateParents: SceneGraph transformation update.
*/
2002-10-12 11:37:38 +00:00
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();
2012-09-16 04:58:18 +00:00
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) )
{
2002-10-12 11:37:38 +00:00
ob->Suspend();
2012-09-16 04:58:18 +00:00
}
else {
2002-10-12 11:37:38 +00:00
ob->Resume();
}
}
2012-09-16 04:58:18 +00:00
}
2002-10-12 11:37:38 +00:00
}
}
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::SetSceneConverter(class KX_BlenderSceneConverter* sceneConverter)
{
m_sceneConverter = sceneConverter;
}
void KX_Scene::SetPhysicsEnvironment(class PHY_IPhysicsEnvironment* physEnv)
{
m_physicsEnvironment = physEnv;
if (m_physicsEnvironment) {
KX_TouchEventManager* touchmgr = new KX_TouchEventManager(m_logicmgr, physEnv);
m_logicmgr->RegisterEventManager(touchmgr);
}
}
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
short KX_Scene::GetAnimationFPS()
{
return m_blenderScene->r.frs_sec;
}
#ifdef USE_BULLET
#include "KX_BulletPhysicsController.h"
#endif
static void MergeScene_LogicBrick(SCA_ILogicBrick* brick, KX_Scene *to)
{
SCA_LogicManager *logicmgr= to->GetLogicManager();
brick->Replace_IScene(to);
brick->Replace_NetworkScene(to->GetNetworkScene());
/* near sensors have physics controllers */
#ifdef USE_BULLET
KX_TouchSensor *touch_sensor = dynamic_cast<class KX_TouchSensor *>(brick);
if (touch_sensor) {
touch_sensor->GetPhysicsController()->SetPhysicsEnvironment(to->GetPhysicsEnvironment());
}
#endif
// If we end up replacing a KX_TouchEventManager, we need to make sure
// physics controllers are properly in place. In other words, do this
// after merging physics controllers!
SCA_ISensor *sensor= dynamic_cast<class SCA_ISensor *>(brick);
if (sensor) {
sensor->Replace_EventManager(logicmgr);
}
}
#ifdef USE_BULLET
#include "CcdGraphicController.h" // XXX ctrl->SetPhysicsEnvironment(to->GetPhysicsEnvironment());
#include "CcdPhysicsEnvironment.h" // XXX ctrl->SetPhysicsEnvironment(to->GetPhysicsEnvironment());
#include "KX_BulletPhysicsController.h"
#endif
static void MergeScene_GameObject(KX_GameObject* gameobj, KX_Scene *to, KX_Scene *from)
{
{
SCA_ActuatorList& actuators= gameobj->GetActuators();
SCA_ActuatorList::iterator ita;
for (ita = actuators.begin(); !(ita==actuators.end()); ++ita)
{
MergeScene_LogicBrick(*ita, to);
}
}
{
SCA_SensorList& sensors= gameobj->GetSensors();
SCA_SensorList::iterator its;
for (its = sensors.begin(); !(its==sensors.end()); ++its)
{
MergeScene_LogicBrick(*its, to);
}
}
{
SCA_ControllerList& controllers= gameobj->GetControllers();
SCA_ControllerList::iterator itc;
for (itc = controllers.begin(); !(itc==controllers.end()); ++itc)
{
SCA_IController *cont= *itc;
MergeScene_LogicBrick(cont, to);
vector<SCA_ISensor*> linkedsensors = cont->GetLinkedSensors();
vector<SCA_IActuator*> linkedactuators = cont->GetLinkedActuators();
for (vector<SCA_IActuator*>::iterator ita = linkedactuators.begin();!(ita==linkedactuators.end());++ita) {
MergeScene_LogicBrick(*ita, to);
}
for (vector<SCA_ISensor*>::iterator its = linkedsensors.begin();!(its==linkedsensors.end());++its) {
MergeScene_LogicBrick(*its, to);
}
}
}
/* graphics controller */
PHY_IGraphicController *ctrl = gameobj->GetGraphicController();
if (ctrl) {
/* SHOULD update the m_cullingTree */
ctrl->SetPhysicsEnvironment(to->GetPhysicsEnvironment());
}
/* SG_Node can hold a scene reference */
SG_Node *sg= gameobj->GetSGNode();
if (sg) {
if (sg->GetSGClientInfo() == from) {
sg->SetSGClientInfo(to);
/* Make sure to grab the children too since they might not be tied to a game object */
NodeList children = sg->GetSGChildren();
for (int i=0; i<children.size(); i++)
children[i]->SetSGClientInfo(to);
}
#ifdef USE_BULLET
SGControllerList::iterator contit;
SGControllerList& controllers = sg->GetSGControllerList();
for (contit = controllers.begin();contit!=controllers.end();++contit)
{
KX_BulletPhysicsController *phys_ctrl= dynamic_cast<KX_BulletPhysicsController *>(*contit);
if (phys_ctrl)
phys_ctrl->SetPhysicsEnvironment(to->GetPhysicsEnvironment());
}
#endif // USE_BULLET
}
/* If the object is a light, update it's scene */
if (gameobj->GetGameObjectType() == SCA_IObject::OBJ_LIGHT)
((KX_LightObject*)gameobj)->UpdateScene(to);
if (gameobj->GetGameObjectType() == SCA_IObject::OBJ_CAMERA)
to->AddCamera((KX_Camera*)gameobj);
/* Add the object to the scene's logic manager */
to->GetLogicManager()->RegisterGameObjectName(gameobj->GetName(), gameobj);
to->GetLogicManager()->RegisterGameObj(gameobj->GetBlenderObject(), gameobj);
for (int i=0; i<gameobj->GetMeshCount(); ++i)
to->GetLogicManager()->RegisterGameMeshName(gameobj->GetMesh(i)->GetName(), gameobj->GetBlenderObject());
}
bool KX_Scene::MergeScene(KX_Scene *other)
{
#ifdef USE_BULLET
CcdPhysicsEnvironment *env= dynamic_cast<CcdPhysicsEnvironment *>(this->GetPhysicsEnvironment());
CcdPhysicsEnvironment *env_other= dynamic_cast<CcdPhysicsEnvironment *>(other->GetPhysicsEnvironment());
if ((env==NULL) != (env_other==NULL)) /* TODO - even when both scenes have NONE physics, the other is loaded with bullet enabled, ??? */
{
printf("KX_Scene::MergeScene: physics scenes type differ, aborting\n");
printf("\tsource %d, terget %d\n", (int)(env!=NULL), (int)(env_other!=NULL));
return false;
}
#endif // USE_BULLET
if (GetSceneConverter() != other->GetSceneConverter()) {
printf("KX_Scene::MergeScene: converters differ, aborting\n");
return false;
}
GetBucketManager()->MergeBucketManager(other->GetBucketManager(), this);
/* move materials across, assume they both use the same scene-converters */
GetSceneConverter()->MergeScene(this, other);
/* active + inactive == all ??? - lets hope so */
for (int i = 0; i < other->GetObjectList()->GetCount(); i++)
{
KX_GameObject* gameobj = (KX_GameObject*)other->GetObjectList()->GetValue(i);
MergeScene_GameObject(gameobj, this, other);
gameobj->UpdateBuckets(false); /* only for active objects */
}
for (int i = 0; i < other->GetInactiveList()->GetCount(); i++)
{
KX_GameObject* gameobj = (KX_GameObject*)other->GetInactiveList()->GetValue(i);
MergeScene_GameObject(gameobj, this, other);
}
GetTempObjectList()->MergeList(other->GetTempObjectList());
other->GetTempObjectList()->ReleaseAndRemoveAll();
GetObjectList()->MergeList(other->GetObjectList());
other->GetObjectList()->ReleaseAndRemoveAll();
GetInactiveList()->MergeList(other->GetInactiveList());
other->GetInactiveList()->ReleaseAndRemoveAll();
GetRootParentList()->MergeList(other->GetRootParentList());
other->GetRootParentList()->ReleaseAndRemoveAll();
GetLightList()->MergeList(other->GetLightList());
other->GetLightList()->ReleaseAndRemoveAll();
#ifdef USE_BULLET
if (env) /* bullet scene? - dummy scenes don't need touching */
env->MergeEnvironment(env_other);
#endif
/* merge logic */
{
SCA_LogicManager *logicmgr= GetLogicManager();
SCA_LogicManager *logicmgr_other= other->GetLogicManager();
vector<class SCA_EventManager*>evtmgrs= logicmgr->GetEventManagers();
//vector<class SCA_EventManager*>evtmgrs_others= logicmgr_other->GetEventManagers();
//SCA_EventManager *evtmgr;
SCA_EventManager *evtmgr_other;
for (unsigned int i= 0; i < evtmgrs.size(); i++) {
evtmgr_other= logicmgr_other->FindEventManager(evtmgrs[i]->GetType());
if (evtmgr_other) /* unlikely but possible one scene has a joystick and not the other */
evtmgr_other->Replace_LogicManager(logicmgr);
2012-03-18 07:38:51 +00:00
/* when merging objects sensors are moved across into the new manager, don't need to do this here */
}
/* grab any timer properties from the other scene */
SCA_TimeEventManager *timemgr= GetTimeEventManager();
SCA_TimeEventManager *timemgr_other= other->GetTimeEventManager();
vector<CValue*> times = timemgr_other->GetTimeValues();
for (unsigned int i= 0; i < times.size(); i++) {
timemgr->AddTimeProperty(times[i]);
}
}
return true;
}
void KX_Scene::Update2DFilter(vector<STR_String>& propNames, void* gameObj, RAS_2DFilterManager::RAS_2DFILTER_MODE filtermode, int pass, STR_String& text)
{
m_filtermanager.EnableFilter(propNames, gameObj, filtermode, pass, text);
}
void KX_Scene::Render2DFilters(RAS_ICanvas* canvas)
{
m_filtermanager.RenderFilters(canvas);
}
#ifdef WITH_PYTHON
2010-03-23 21:37:02 +00:00
2012-09-16 04:58:18 +00:00
void KX_Scene::RunDrawingCallbacks(PyObject *cb_list)
2010-03-23 21:37:02 +00:00
{
Py_ssize_t len;
2010-03-23 21:37:02 +00:00
if (cb_list && (len=PyList_GET_SIZE(cb_list)))
{
2012-09-16 04:58:18 +00:00
PyObject *args = PyTuple_New(0); // save python creating each call
PyObject *func;
PyObject *ret;
2010-03-23 21:37:02 +00:00
// Iterate the list and run the callbacks
for (Py_ssize_t pos=0; pos < len; pos++)
2010-03-23 21:37:02 +00:00
{
func= PyList_GET_ITEM(cb_list, pos);
ret= PyObject_Call(func, args, NULL);
if (ret==NULL) {
PyErr_Print();
PyErr_Clear();
}
else {
Py_DECREF(ret);
}
}
Py_DECREF(args);
}
}
2004-06-07 11:03:12 +00:00
//----------------------------------------------------------------------------
//Python
PyTypeObject KX_Scene::Type = {
PyVarObject_HEAD_INIT(NULL, 0)
2009-08-10 00:07:34 +00:00
"KX_Scene",
sizeof(PyObjectPlus_Proxy),
0,
py_base_dealloc,
0,
0,
0,
0,
py_base_repr,
0,
&Sequence,
&Mapping,
0,0,0,0,0,0,
2009-08-10 00:07:34 +00:00
Py_TPFLAGS_DEFAULT | Py_TPFLAGS_BASETYPE,
0,0,0,0,0,0,0,
Methods,
0,
0,
&CValue::Type,
0,0,0,0,0,0,
py_base_new
2004-06-07 11:03:12 +00:00
};
PyMethodDef KX_Scene::Methods[] = {
KX_PYMETHODTABLE(KX_Scene, addObject),
KX_PYMETHODTABLE(KX_Scene, end),
KX_PYMETHODTABLE(KX_Scene, restart),
KX_PYMETHODTABLE(KX_Scene, replace),
KX_PYMETHODTABLE(KX_Scene, suspend),
KX_PYMETHODTABLE(KX_Scene, resume),
KX_PYMETHODTABLE(KX_Scene, drawObstacleSimulation),
2011-02-16 17:07:18 +00:00
/* dict style access */
KX_PYMETHODTABLE(KX_Scene, get),
{NULL,NULL} //Sentinel
};
static PyObject *Map_GetItem(PyObject *self_v, PyObject *item)
{
KX_Scene* self= static_cast<KX_Scene*>BGE_PROXY_REF(self_v);
const char *attr_str= _PyUnicode_AsString(item);
2012-09-16 04:58:18 +00:00
PyObject *pyconvert;
if (self==NULL) {
PyErr_SetString(PyExc_SystemError, "val = scene[key]: KX_Scene, "BGE_PROXY_ERROR_MSG);
return NULL;
}
if (self->m_attr_dict && (pyconvert=PyDict_GetItem(self->m_attr_dict, item))) {
if (attr_str)
PyErr_Clear();
Py_INCREF(pyconvert);
return pyconvert;
}
else {
if (attr_str) PyErr_Format(PyExc_KeyError, "value = scene[key]: KX_Scene, key \"%s\" does not exist", attr_str);
else PyErr_SetString(PyExc_KeyError, "value = scene[key]: KX_Scene, key does not exist");
return NULL;
}
}
static int Map_SetItem(PyObject *self_v, PyObject *key, PyObject *val)
{
KX_Scene* self= static_cast<KX_Scene*>BGE_PROXY_REF(self_v);
const char *attr_str= _PyUnicode_AsString(key);
if (attr_str==NULL)
PyErr_Clear();
if (self==NULL) {
PyErr_SetString(PyExc_SystemError, "scene[key] = value: KX_Scene, "BGE_PROXY_ERROR_MSG);
return -1;
}
if (val==NULL) { /* del ob["key"] */
int del= 0;
if (self->m_attr_dict)
del |= (PyDict_DelItem(self->m_attr_dict, key)==0) ? 1:0;
if (del==0) {
if (attr_str) PyErr_Format(PyExc_KeyError, "scene[key] = value: KX_Scene, key \"%s\" could not be set", attr_str);
else PyErr_SetString(PyExc_KeyError, "del scene[key]: KX_Scene, key could not be deleted");
return -1;
}
else if (self->m_attr_dict) {
PyErr_Clear(); /* PyDict_DelItem sets an error when it fails */
}
}
else { /* ob["key"] = value */
int set = 0;
if (self->m_attr_dict==NULL) /* lazy init */
self->m_attr_dict= PyDict_New();
if (PyDict_SetItem(self->m_attr_dict, key, val)==0)
set= 1;
else
PyErr_SetString(PyExc_KeyError, "scene[key] = value: KX_Scene, key not be added to internal dictionary");
if (set==0)
return -1; /* pythons error value */
}
return 0; /* success */
}
static int Seq_Contains(PyObject *self_v, PyObject *value)
{
KX_Scene* self= static_cast<KX_Scene*>BGE_PROXY_REF(self_v);
if (self==NULL) {
PyErr_SetString(PyExc_SystemError, "val in scene: KX_Scene, "BGE_PROXY_ERROR_MSG);
return -1;
}
if (self->m_attr_dict && PyDict_GetItem(self->m_attr_dict, value))
return 1;
return 0;
}
PyMappingMethods KX_Scene::Mapping = {
(lenfunc)NULL , /*inquiry mp_length */
(binaryfunc)Map_GetItem, /*binaryfunc mp_subscript */
(objobjargproc)Map_SetItem, /*objobjargproc mp_ass_subscript */
};
PySequenceMethods KX_Scene::Sequence = {
NULL, /* Cant set the len otherwise it can evaluate as false */
NULL, /* sq_concat */
NULL, /* sq_repeat */
NULL, /* sq_item */
NULL, /* sq_slice */
NULL, /* sq_ass_item */
NULL, /* sq_ass_slice */
(objobjproc)Seq_Contains, /* sq_contains */
(binaryfunc) NULL, /* sq_inplace_concat */
(ssizeargfunc) NULL, /* sq_inplace_repeat */
};
2012-09-16 04:58:18 +00:00
PyObject *KX_Scene::pyattr_get_name(void *self_v, const KX_PYATTRIBUTE_DEF *attrdef)
{
KX_Scene* self= static_cast<KX_Scene*>(self_v);
return PyUnicode_From_STR_String(self->GetName());
}
2012-09-16 04:58:18 +00:00
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();
}
2012-09-16 04:58:18 +00:00
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();
}
2012-09-16 04:58:18 +00:00
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();
}
2012-09-16 04:58:18 +00:00
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);
}
2012-09-16 04:58:18 +00:00
PyObject *KX_Scene::pyattr_get_active_camera(void *self_v, const KX_PYATTRIBUTE_DEF *attrdef)
{
KX_Scene* self= static_cast<KX_Scene*>(self_v);
KX_Camera* cam= self->GetActiveCamera();
if (cam)
return self->GetActiveCamera()->GetProxy();
else
Py_RETURN_NONE;
}
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;
}
2012-09-16 04:58:18 +00:00
PyObject *KX_Scene::pyattr_get_drawing_callback_pre(void *self_v, const KX_PYATTRIBUTE_DEF *attrdef)
{
KX_Scene* self = static_cast<KX_Scene*>(self_v);
if (self->m_draw_call_pre==NULL)
self->m_draw_call_pre= PyList_New(0);
Py_INCREF(self->m_draw_call_pre);
return self->m_draw_call_pre;
}
2012-09-16 04:58:18 +00:00
PyObject *KX_Scene::pyattr_get_drawing_callback_post(void *self_v, const KX_PYATTRIBUTE_DEF *attrdef)
{
KX_Scene* self = static_cast<KX_Scene*>(self_v);
if (self->m_draw_call_post==NULL)
self->m_draw_call_post= PyList_New(0);
Py_INCREF(self->m_draw_call_post);
return self->m_draw_call_post;
}
int KX_Scene::pyattr_set_drawing_callback_pre(void *self_v, const KX_PYATTRIBUTE_DEF *attrdef, PyObject *value)
{
KX_Scene* self = static_cast<KX_Scene*>(self_v);
if (!PyList_CheckExact(value))
{
PyErr_SetString(PyExc_ValueError, "Expected a list");
return PY_SET_ATTR_FAIL;
}
Py_XDECREF(self->m_draw_call_pre);
Py_INCREF(value);
self->m_draw_call_pre = value;
return PY_SET_ATTR_SUCCESS;
}
int KX_Scene::pyattr_set_drawing_callback_post(void *self_v, const KX_PYATTRIBUTE_DEF *attrdef, PyObject *value)
{
KX_Scene* self = static_cast<KX_Scene*>(self_v);
if (!PyList_CheckExact(value))
{
PyErr_SetString(PyExc_ValueError, "Expected a list");
return PY_SET_ATTR_FAIL;
}
Py_XDECREF(self->m_draw_call_post);
Py_INCREF(value);
self->m_draw_call_post = value;
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),
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_RW_FUNCTION("pre_draw", KX_Scene, pyattr_get_drawing_callback_pre, pyattr_set_drawing_callback_pre),
KX_PYATTRIBUTE_RW_FUNCTION("post_draw", KX_Scene, pyattr_get_drawing_callback_post, pyattr_set_drawing_callback_post),
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
};
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;
2012-06-04 20:11:09 +00:00
if (!m_inactivelist->SearchValue(ob)) {
PyErr_Format(PyExc_ValueError, "scene.addObject(object, other, time): KX_Scene (first argument): object must be in an inactive layer");
2012-06-04 20:11:09 +00:00
return NULL;
}
SCA_IObject* replica = AddReplicaObject((SCA_IObject*)ob, other, time);
// release here because AddReplicaObject AddRef's
2012-03-18 07:38:51 +00:00
// the object is added to the scene so we don't want python to own a reference
replica->Release();
return replica->GetProxy();
}
KX_PYMETHODDEF_DOC(KX_Scene, end,
"end()\n"
"Removes this scene from the game.\n")
{
KX_GetActiveEngine()->RemoveScene(m_sceneName);
Py_RETURN_NONE;
}
KX_PYMETHODDEF_DOC(KX_Scene, restart,
"restart()\n"
"Restarts this scene.\n")
{
KX_GetActiveEngine()->ReplaceScene(m_sceneName, m_sceneName);
Py_RETURN_NONE;
}
KX_PYMETHODDEF_DOC(KX_Scene, replace,
"replace(newScene)\n"
"Replaces this scene with another one.\n")
{
char* name;
if (!PyArg_ParseTuple(args, "s:replace", &name))
return NULL;
KX_GetActiveEngine()->ReplaceScene(m_sceneName, name);
Py_RETURN_NONE;
}
KX_PYMETHODDEF_DOC(KX_Scene, suspend,
"suspend()\n"
"Suspends this scene.\n")
{
Suspend();
Py_RETURN_NONE;
}
KX_PYMETHODDEF_DOC(KX_Scene, resume,
"resume()\n"
"Resumes this scene.\n")
{
Resume();
Py_RETURN_NONE;
}
KX_PYMETHODDEF_DOC(KX_Scene, drawObstacleSimulation,
"drawObstacleSimulation()\n"
"Draw debug visualization of obstacle simulation.\n")
{
if (GetObstacleSimulation())
GetObstacleSimulation()->DrawObstacles();
Py_RETURN_NONE;
}
/* Matches python dict.get(key, [default]) */
KX_PYMETHODDEF_DOC(KX_Scene, get, "")
{
PyObject *key;
2012-09-16 04:58:18 +00:00
PyObject *def = Py_None;
PyObject *ret;
if (!PyArg_ParseTuple(args, "O|O:get", &key, &def))
return NULL;
if (m_attr_dict && (ret=PyDict_GetItem(m_attr_dict, key))) {
Py_INCREF(ret);
return ret;
}
Py_INCREF(def);
return def;
}
#endif // WITH_PYTHON