2002-10-12 11:37:38 +00:00
|
|
|
/**
|
|
|
|
|
* $Id$
|
|
|
|
|
*
|
2008-04-16 22:40:48 +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
|
2008-04-16 22:40:48 +00:00
|
|
|
* of the License, or (at your option) any later version.
|
2002-10-12 11:37:38 +00:00
|
|
|
*
|
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
|
* along with this program; if not, write to the Free Software Foundation,
|
|
|
|
|
* Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
|
|
|
|
|
*
|
|
|
|
|
* The Original Code is Copyright (C) 2001-2002 by NaN Holding BV.
|
|
|
|
|
* All rights reserved.
|
|
|
|
|
*
|
|
|
|
|
* The Original Code is: all of this file.
|
|
|
|
|
*
|
|
|
|
|
* Contributor(s): none yet.
|
|
|
|
|
*
|
2008-04-16 22:40:48 +00:00
|
|
|
* ***** END GPL LICENSE BLOCK *****
|
2002-10-12 11:37:38 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef BL_SKINDEFORMER
|
|
|
|
|
#define BL_SKINDEFORMER
|
|
|
|
|
|
|
|
|
|
#ifdef WIN32
|
|
|
|
|
#pragma warning (disable:4786) // get rid of stupid stl-visual compiler debug warning
|
|
|
|
|
#endif //WIN32
|
|
|
|
|
|
2005-03-22 13:34:31 +00:00
|
|
|
#include "GEN_HashedPtr.h"
|
2002-10-12 11:37:38 +00:00
|
|
|
#include "BL_MeshDeformer.h"
|
|
|
|
|
#include "BL_ArmatureObject.h"
|
|
|
|
|
|
|
|
|
|
#include "DNA_mesh_types.h"
|
2004-03-20 22:55:42 +00:00
|
|
|
#include "DNA_meshdata_types.h"
|
2002-10-12 11:37:38 +00:00
|
|
|
#include "DNA_object_types.h"
|
|
|
|
|
#include "BKE_armature.h"
|
|
|
|
|
|
|
|
|
|
#include "RAS_Deformer.h"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
class BL_SkinDeformer : public BL_MeshDeformer
|
|
|
|
|
{
|
|
|
|
|
public:
|
|
|
|
|
// void SetArmatureController (BL_ArmatureController *cont);
|
Merge of first part of changes from the apricot branch, especially
the features that are needed to run the game. Compile tested with
scons, make, but not cmake, that seems to have an issue not related
to these changes. The changes include:
* GLSL support in the viewport and game engine, enable in the game
menu in textured draw mode.
* Synced and merged part of the duplicated blender and gameengine/
gameplayer drawing code.
* Further refactoring of game engine drawing code, especially mesh
storage changed a lot.
* Optimizations in game engine armatures to avoid recomputations.
* A python function to get the framerate estimate in game.
* An option take object color into account in materials.
* An option to restrict shadow casters to a lamp's layers.
* Increase from 10 to 18 texture slots for materials, lamps, word.
An extra texture slot shows up once the last slot is used.
* Memory limit for undo, not enabled by default yet because it
needs the .B.blend to be changed.
* Multiple undo for image painting.
* An offset for dupligroups, so not all objects in a group have to
be at the origin.
2008-09-04 20:51:28 +00:00
|
|
|
virtual void Relink(GEN_Map<class GEN_HashedPtr, void*>*map);
|
2002-10-12 11:37:38 +00:00
|
|
|
void SetArmature (class BL_ArmatureObject *armobj);
|
2005-12-31 07:20:08 +00:00
|
|
|
|
2008-07-10 12:47:20 +00:00
|
|
|
BL_SkinDeformer(BL_DeformableGameObject *gameobj,
|
|
|
|
|
struct Object *bmeshobj,
|
2006-01-06 03:46:54 +00:00
|
|
|
class BL_SkinMeshObject *mesh,
|
2008-06-18 06:46:49 +00:00
|
|
|
BL_ArmatureObject* arma = 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
|
|
|
|
|
|
|
|
/* this second constructor is needed for making a mesh deformable on the fly. */
|
2008-07-10 12:47:20 +00:00
|
|
|
BL_SkinDeformer(BL_DeformableGameObject *gameobj,
|
|
|
|
|
struct Object *bmeshobj_old,
|
2006-01-06 03:46:54 +00:00
|
|
|
struct Object *bmeshobj_new,
|
|
|
|
|
class BL_SkinMeshObject *mesh,
|
|
|
|
|
bool release_object,
|
BGE: Support mesh modifiers in the game engine.
Realtime modifiers applied on mesh objects will be supported in
the game engine with the following limitations:
- Only real time modifiers are supported (basically all of them!)
- Virtual modifiers resulting from parenting are not supported:
armature, curve, lattice. You can still use these modifiers
(armature is really not recommended) but in non parent mode.
The BGE has it's own parenting capability for armature.
- Modifiers are computed on the host (using blender modifier
stack).
- Modifiers are statically evaluated: any possible time dependency
in the modifiers is not supported (don't know enough about
modifiers to be more specific).
- Modifiers are reevaluated if the underlying mesh is deformed
due to shape action or armature action. Beware that this is
very CPU intensive; modifiers should really be used for static
objects only.
- Physics is still based on the original mesh: if you have a
mirror modifier, the physic shape will be limited to one half
of the resulting object. Therefore, the modifiers should
preferably be used on graphic objects.
- Scripts have no access to the modified mesh.
- Modifiers that are based on objects interaction (boolean,..)
will not be dependent on the objects position in the GE.
What you see in the 3D view is what you get in the GE regardless
on the object position, velocity, etc.
Besides that, the feature is compatible with all the BGE features
that affect meshes: armature action, shape action, relace mesh,
VideoTexture, add object, dupligroup.
Known problems:
- This feature is a bit hacky: the BGE uses the derived mesh draw
functions to display the object. This drawing method is a
bit slow and is not 100% compatible with the BGE. There may
be some problems in multi-texture mode: the multi-texture
coordinates are not sent to the GPU.
Texface and GLSL on the other hand should be fully supported.
- Culling is still based on the extend of the original mesh.
If you have a modifer that extends the size of the mesh,
the object may disappear while still in the view frustrum.
- Derived mesh is not shared between replicas.
The derived mesh is allocated and computed for each object
with modifiers, regardless if they are static replicas.
- Display list are not created on objects with modifiers.
I should be able to fix the above problems before release.
However, the feature is already useful for game development.
Once you are ready to release the game, you can apply the modifiers
to get back display list support and mesh sharing capability.
MSVC, scons, Cmake, makefile updated.
Enjoy
/benoit
2009-04-21 11:01:09 +00:00
|
|
|
bool recalc_normal,
|
2008-04-05 13:33:08 +00:00
|
|
|
BL_ArmatureObject* arma = NULL);
|
2002-10-12 11:37:38 +00:00
|
|
|
|
|
|
|
|
virtual void ProcessReplica();
|
2008-09-26 02:27:59 +00:00
|
|
|
virtual RAS_Deformer *GetReplica(class KX_GameObject* replica);
|
2002-10-12 11:37:38 +00:00
|
|
|
virtual ~BL_SkinDeformer();
|
2008-06-18 06:46:49 +00:00
|
|
|
bool Update (void);
|
2002-10-12 11:37:38 +00:00
|
|
|
bool Apply (class RAS_IPolyMaterial *polymat);
|
2008-06-24 22:19:00 +00:00
|
|
|
bool PoseUpdated(void)
|
|
|
|
|
{
|
|
|
|
|
if (m_armobj && m_lastArmaUpdate!=m_armobj->GetLastFrame()) {
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
return false;
|
|
|
|
|
}
|
2002-10-12 11:37:38 +00:00
|
|
|
|
2008-06-18 06:46:49 +00:00
|
|
|
void ForceUpdate()
|
|
|
|
|
{
|
|
|
|
|
m_lastArmaUpdate = -1.0;
|
|
|
|
|
};
|
|
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
protected:
|
2006-01-06 03:46:54 +00:00
|
|
|
BL_ArmatureObject* m_armobj; // Our parent object
|
2002-10-12 11:37:38 +00:00
|
|
|
float m_time;
|
2008-06-18 06:46:49 +00:00
|
|
|
double m_lastArmaUpdate;
|
BGE: Support mesh modifiers in the game engine.
Realtime modifiers applied on mesh objects will be supported in
the game engine with the following limitations:
- Only real time modifiers are supported (basically all of them!)
- Virtual modifiers resulting from parenting are not supported:
armature, curve, lattice. You can still use these modifiers
(armature is really not recommended) but in non parent mode.
The BGE has it's own parenting capability for armature.
- Modifiers are computed on the host (using blender modifier
stack).
- Modifiers are statically evaluated: any possible time dependency
in the modifiers is not supported (don't know enough about
modifiers to be more specific).
- Modifiers are reevaluated if the underlying mesh is deformed
due to shape action or armature action. Beware that this is
very CPU intensive; modifiers should really be used for static
objects only.
- Physics is still based on the original mesh: if you have a
mirror modifier, the physic shape will be limited to one half
of the resulting object. Therefore, the modifiers should
preferably be used on graphic objects.
- Scripts have no access to the modified mesh.
- Modifiers that are based on objects interaction (boolean,..)
will not be dependent on the objects position in the GE.
What you see in the 3D view is what you get in the GE regardless
on the object position, velocity, etc.
Besides that, the feature is compatible with all the BGE features
that affect meshes: armature action, shape action, relace mesh,
VideoTexture, add object, dupligroup.
Known problems:
- This feature is a bit hacky: the BGE uses the derived mesh draw
functions to display the object. This drawing method is a
bit slow and is not 100% compatible with the BGE. There may
be some problems in multi-texture mode: the multi-texture
coordinates are not sent to the GPU.
Texface and GLSL on the other hand should be fully supported.
- Culling is still based on the extend of the original mesh.
If you have a modifer that extends the size of the mesh,
the object may disappear while still in the view frustrum.
- Derived mesh is not shared between replicas.
The derived mesh is allocated and computed for each object
with modifiers, regardless if they are static replicas.
- Display list are not created on objects with modifiers.
I should be able to fix the above problems before release.
However, the feature is already useful for game development.
Once you are ready to release the game, you can apply the modifiers
to get back display list support and mesh sharing capability.
MSVC, scons, Cmake, makefile updated.
Enjoy
/benoit
2009-04-21 11:01:09 +00:00
|
|
|
//ListBase* m_defbase;
|
2008-06-18 06:46:49 +00:00
|
|
|
float m_obmat[4][4]; // the reference matrix for skeleton deform
|
2006-01-06 03:46:54 +00:00
|
|
|
bool m_releaseobject;
|
2008-07-16 21:24:54 +00:00
|
|
|
bool m_poseApplied;
|
BGE: Support mesh modifiers in the game engine.
Realtime modifiers applied on mesh objects will be supported in
the game engine with the following limitations:
- Only real time modifiers are supported (basically all of them!)
- Virtual modifiers resulting from parenting are not supported:
armature, curve, lattice. You can still use these modifiers
(armature is really not recommended) but in non parent mode.
The BGE has it's own parenting capability for armature.
- Modifiers are computed on the host (using blender modifier
stack).
- Modifiers are statically evaluated: any possible time dependency
in the modifiers is not supported (don't know enough about
modifiers to be more specific).
- Modifiers are reevaluated if the underlying mesh is deformed
due to shape action or armature action. Beware that this is
very CPU intensive; modifiers should really be used for static
objects only.
- Physics is still based on the original mesh: if you have a
mirror modifier, the physic shape will be limited to one half
of the resulting object. Therefore, the modifiers should
preferably be used on graphic objects.
- Scripts have no access to the modified mesh.
- Modifiers that are based on objects interaction (boolean,..)
will not be dependent on the objects position in the GE.
What you see in the 3D view is what you get in the GE regardless
on the object position, velocity, etc.
Besides that, the feature is compatible with all the BGE features
that affect meshes: armature action, shape action, relace mesh,
VideoTexture, add object, dupligroup.
Known problems:
- This feature is a bit hacky: the BGE uses the derived mesh draw
functions to display the object. This drawing method is a
bit slow and is not 100% compatible with the BGE. There may
be some problems in multi-texture mode: the multi-texture
coordinates are not sent to the GPU.
Texface and GLSL on the other hand should be fully supported.
- Culling is still based on the extend of the original mesh.
If you have a modifer that extends the size of the mesh,
the object may disappear while still in the view frustrum.
- Derived mesh is not shared between replicas.
The derived mesh is allocated and computed for each object
with modifiers, regardless if they are static replicas.
- Display list are not created on objects with modifiers.
I should be able to fix the above problems before release.
However, the feature is already useful for game development.
Once you are ready to release the game, you can apply the modifiers
to get back display list support and mesh sharing capability.
MSVC, scons, Cmake, makefile updated.
Enjoy
/benoit
2009-04-21 11:01:09 +00:00
|
|
|
bool m_recalcNormal;
|
2006-01-06 03:46:54 +00:00
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#endif
|
|
|
|
|
|
