Welcome to mirror list, hosted at ThFree Co, Russian Federation.

git.blender.org/blender.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorBenoit Bolsee <benoit.bolsee@online.be>2009-04-21 15:01:09 +0400
committerBenoit Bolsee <benoit.bolsee@online.be>2009-04-21 15:01:09 +0400
commitd11a5bbef2750c9e95c0657eb9d965de375b2982 (patch)
treea81482dbc11cdac8be2748ada47b4f59ff204ea2 /source/gameengine/Rasterizer/RAS_MaterialBucket.cpp
parent3e7cbd5388426a612b4066fbe7f2964c976fb23e (diff)
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
Diffstat (limited to 'source/gameengine/Rasterizer/RAS_MaterialBucket.cpp')
-rw-r--r--source/gameengine/Rasterizer/RAS_MaterialBucket.cpp39
1 files changed, 39 insertions, 0 deletions
diff --git a/source/gameengine/Rasterizer/RAS_MaterialBucket.cpp b/source/gameengine/Rasterizer/RAS_MaterialBucket.cpp
index 6beab28d61f..d63e9c98415 100644
--- a/source/gameengine/Rasterizer/RAS_MaterialBucket.cpp
+++ b/source/gameengine/Rasterizer/RAS_MaterialBucket.cpp
@@ -56,6 +56,7 @@ RAS_MeshSlot::RAS_MeshSlot()
m_DisplayList = NULL;
m_bDisplayList = true;
m_joinSlot = NULL;
+ m_pDerivedMesh = NULL;
}
RAS_MeshSlot::~RAS_MeshSlot()
@@ -87,6 +88,7 @@ RAS_MeshSlot::RAS_MeshSlot(const RAS_MeshSlot& slot)
m_clientObj = NULL;
m_pDeformer = NULL;
+ m_pDerivedMesh = NULL;
m_OpenGLMatrix = NULL;
m_mesh = slot.m_mesh;
m_bucket = slot.m_bucket;
@@ -279,6 +281,43 @@ void RAS_MeshSlot::AddPolygonVertex(int offset)
m_endindex++;
}
+void RAS_MeshSlot::SetDeformer(RAS_Deformer* deformer)
+{
+ if (deformer && m_pDeformer != deformer) {
+ // we create local copy of RAS_DisplayArray when we have a deformer:
+ // this way we can avoid conflict between the vertex cache of duplicates
+ RAS_DisplayArrayList::iterator it;
+ for(it=m_displayArrays.begin(); it!=m_displayArrays.end(); it++) {
+ if (deformer->UseVertexArray()) {
+ // the deformer makes use of vertex array, make sure we have our local copy
+ if ((*it)->m_users > 1) {
+ // only need to copy if there are other users
+ // note that this is the usual case as vertex arrays are held by the material base slot
+ RAS_DisplayArray *newarray = new RAS_DisplayArray(*(*it));
+ newarray->m_users = 1;
+ (*it)->m_users--;
+ *it = newarray;
+ }
+ } else {
+ // the deformer is not using vertex array (Modifier), release them
+ (*it)->m_users--;
+ if((*it)->m_users == 0)
+ delete *it;
+ }
+ }
+ if (!deformer->UseVertexArray()) {
+ m_displayArrays.clear();
+ m_startarray = 0;
+ m_startvertex = 0;
+ m_startindex = 0;
+ m_endarray = 0;
+ m_endvertex = 0;
+ m_endindex = 0;
+ }
+ }
+ m_pDeformer = deformer;
+}
+
bool RAS_MeshSlot::Equals(RAS_MeshSlot *target)
{
if(!m_OpenGLMatrix || !target->m_OpenGLMatrix)