Commit Graph

23 Commits

Author SHA1 Message Date
Benoit Bolsee
d95a109990 BGE modifier: generate correct physic shape, share static derived mesh, share display list.
This commit completes the support for modifiers in the BGE.
- The physic shape is generated according to the derived mesh. 
  This is true for all types of shapes and all types of 
  objects except soft body.
- Optimization for static derived mesh (mesh with modifiers
  but no armature and no shape keys). Replicas will share
  the derived mesh and the display list: less memory and
  faster rendering. With this optimization, the static 
  derived mesh will render as fast as if the modifiers were
  applied.

Known Limits:
- Sharing of mesh and display list is only possible between
  in-game replicas or dupligroup. If you want to instantiate
  multiple objects with modifiers, use dupligroup to ensure
  best memory and GPU utilization.
- rayCast() will interact with the derived mesh as follow:
  Hit position and hit normal are the real values according
  to the derived mesh but the KX_PolyProxy object refers to
  the original mesh. You should use it only to retrieve the
  material.
- Dynamic derived mesh have very poor performance:
  They use direct openGL calls for rendering (no support
  for display list and vertex array) and they dont't share
  the derived mesh memory. Always apply modifiers on dynamic
  mesh for best performance.
- Time dependent modifiers are not supported.
- Modifiers are not supported for Bullet soft body.
2009-05-14 13:47:08 +00:00
Benoit Bolsee
ee1c29028d BGE: Add MT_Vector3 support for Py attribute macro system. See KX_PYATTRIBUTE_VECTOR_... 2009-05-11 12:41:48 +00:00
Benoit Bolsee
386122ada6 BGE performance, 4th round: logic
This commit extends the technique of dynamic linked list to the logic
system to eliminate as much as possible temporaries, map lookup or 
full scan. The logic engine is now free of memory allocation, which is
an important stability factor. 

The overhead of the logic system is reduced by a factor between 3 and 6
depending on the logic setup. This is the speed-up you can expect on 
a logic setup using simple bricks. Heavy bricks like python controllers
and ray sensors will still take about the same time to execute so the
speed up will be less important.

The core of the logic engine has been much reworked but the functionality
is still the same except for one thing: the priority system on the 
execution of controllers. The exact same remark applies to actuators but
I'll explain for controllers only:

Previously, it was possible, with the "executePriority" attribute to set
a controller to run before any other controllers in the game. Other than
that, the sequential execution of controllers, as defined in Blender was
guaranteed by default.

With the new system, the sequential execution of controllers is still 
guaranteed but only within the controllers of one object. the user can
no longer set a controller to run before any other controllers in the
game. The "executePriority" attribute controls the execution of controllers
within one object. The priority is a small number starting from 0 for the
first controller and incrementing for each controller.

If this missing feature is a must, a special method can be implemented
to set a controller to run before all other controllers.

Other improvements:
- Systematic use of reference in parameter passing to avoid unnecessary data copy
- Use pre increment in iterator instead of post increment to avoid temporary allocation
- Use const char* instead of STR_String whenever possible to avoid temporary allocation
- Fix reference counting bugs (memory leak)
- Fix a crash in certain cases of state switching and object deletion
- Minor speed up in property sensor
- Removal of objects during the game is a lot faster
2009-05-10 20:53:58 +00:00
Benoit Bolsee
42557f90bd BGE performance, 3rd round: culling and rasterizer.
This commit extend the technique of dynamic linked list to the mesh
slots so as to eliminate dumb scan or map lookup. It provides massive 
performance improvement in the culling and in the rasterizer when 
the majority of objects are static.

Other improvements:
- Compute the opengl matrix only for objects that are visible.
- Simplify hash function for GEN_HasedPtr
- Scan light list instead of general object list to render shadows
- Remove redundant opengl calls to set specularity, shinyness and diffuse
  between each mesh slots.
- Cache GPU material to avoid frequent call to GPU_material_from_blender
- Only set once the fixed elements of mesh slot
- Use more inline function

The following table shows the performance increase between 2.48, 1st round
and this round of improvement. The test was done with a scene containing 
40000 objects, of which 1000 are in the view frustrum approximately. The
object are simple textured cube to make sure the GPU is not the bottleneck.
As some of the rasterizer processing time has moved under culling, I present
the sum of scenegraph(includes culling)+rasterizer time

Scenegraph+rasterizer(ms)       2.48      1st round       3rd round

All objects static,            323.0           86.0             7.2
all visible, 1000 in 
the view frustrum

All objects static,            219.0           49.7             N/A(*)
all invisible.

All objects moving,            323.0          105.6            34.7
all visible, 1000 in 
the view frustrum

Scene destruction              40min          40min              4s

(*) : this time is not representative because the frame rate was at 60fps.
      In that case, the GPU holds down the GE by frame sync. By design, the
      overhead of the rasterizer is 0 when the the objects are invisible. 

This table shows a global speed up between 9x and 45x compared to 2.48a
for scenegraph, culling and rasterizer overhead. The speed up goes much
higher when objects are invisible.

An additional 2-4x speed up is possible in the scenegraph by upgrading
the Moto library to use Eigen2 BLAS library instead of C++ classes but
the scenegraph is already so fast that it is not a priority right now.

Next speed up in logic: many things to do there...
2009-05-07 09:13:01 +00:00
Benoit Bolsee
3abb8e8e68 BGE performance: second round of scenegraph improvement.
Use dynamic linked list to handle scenegraph rather than dumb scan
of the whole tree. The performance improvement depends on the fraction
of moving objects. If most objects are static, the speed up is 
considerable. The following table compares the time spent on 
scenegraph before and after this commit on a scene with 10000 objects
in various configuratons:

Scenegraph time (ms)              Before         After
(includes culling)

All objects static,               8.8            1.7  
all visible but small fraction          
in the view frustrum

All objects static,               7,5            0.01
all invisible.

All objects moving,               14.1           8.4
all visible but small fraction
in the view frustrum

This tables shows that static and invisible objects take no CPU at all
for scenegraph and culling. In the general case, this commit will 
speed up the scenegraph between 2x and 5x. Compared to 2.48a, it should
be between 4x and 10x faster. Further speed up is possible by making
the scenegraph cache-friendly.

Next round of performance improvement will be on the rasterizer: use
the same dynamic linked list technique for the mesh slots.
2009-05-03 22:29:00 +00:00
Benoit Bolsee
ba563216e9 BGE: Fix Orthographic mode and viewport scaling
- the BGE now uses correct glOrtho projection whe camera is in orthographic mode
-
2009-04-26 12:23:30 +00:00
Benoit Bolsee
d11a5bbef2 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
Benoit Bolsee
0b8661ab4d BGE: Occlusion culling and other performance improvements.
Added occlusion culling capability in the BGE. 
More info: http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.49/Game_Engine#BGE_Scenegraph_improvement
MSVC, scons, cmake, Makefile updated.

Other minor performance improvements:
- The rasterizer was computing the openGL model matrix of the objects too many times
- DBVT view frustrum culling was not properly culling behind the near plane:
  Large objects behind the camera were sent to the GPU
- Remove all references to mesh split/join feature as it is not yet functional
2009-04-13 20:08:33 +00:00
Benoit Bolsee
2074128fad Patch #18462: Fisheye (Dome) and Spherical Panoramic mode in BGE.
User guide:
http://wiki.blender.org/index.php/Dev:Source/GameEngine/Fisheye_Dome_Camera

Fixed two bugs from original patch:
- deleting a text will clear the warp field from Game framing settings
- removed spurious black dots along the edge of the cube map in the gameplayer 

Known limitation:
- resizing of the screen doesn't work in the gameplayer

Known bugs:
- Texture with reflexion are not rendered correctly
- Spurious problems with light
2009-04-08 15:06:20 +00:00
Benoit Bolsee
51b4145841 BGE Scenegraph and View frustrum culling improvement.
This commit contains a number of performance improvements for the
BGE in the Scenegraph (parent relation between objects in the
scene) and view frustrum culling.

The scenegraph improvement consists in avoiding position update
if the object has not moved since last update and the removal
of redundant updates and synchronization with the physics engine.

The view frustrum culling improvement consists in using the DBVT
broadphase facility of Bullet to build a tree of graphical objects
in the scene. The elements of the tree are Aabb boxes (Aligned 
Axis Bounding Boxes) enclosing the objects. This provides good
precision in closed and opened scenes. This new culling system
is enabled by default but just in case, it can be disabled with
a button in the World settings. There is no do_version in this
commit but it will be added before the 2.49 release. For now you
must manually enable the DBVT culling option in World settings
when you open an old file.

The above improvements speed up scenegraph and culling up to 5x.
However, this performance improvement is only visible when
you have hundreds or thousands of objects.

The main interest of the DBVT tree is to allow easy occlusion
culling and automatic LOD system. This will be the object of further
improvements.
2009-04-07 22:14:06 +00:00
Benoit Bolsee
14e3b041ba MSVC9 project file update 2009-04-07 19:57:30 +00:00
Benoit Bolsee
29f5c7dd5d MSVC9 project file. 2009-04-03 19:19:02 +00:00
Benoit Bolsee
bd13f30224 MSVC project files updated for ffmpeg 0.5 and armature. You must also update lib/windows. 2009-03-22 23:39:36 +00:00
Benoit Bolsee
51b3bba1c0 Update MSVC9 project file for VideoTexture 2009-03-05 15:35:15 +00:00
Benoit Bolsee
9265150942 MSVC9 project file: add ffmpeg avdevice lib to linker for the blenderplayer. 2009-02-28 21:37:49 +00:00
Benoit Bolsee
95f91f2a46 MSVC9 project files: reactivate VideoTexture module in BGE; it that was disabled for some reason. 2009-02-19 23:15:27 +00:00
Benoit Bolsee
4f3768af49 Update MSVC9 project files 2009-02-07 20:47:23 +00:00
Benoit Bolsee
d91daaa5f6 MSVC project file update for ffmpeg device lib, release build 2008-12-29 14:26:36 +00:00
Benoit Bolsee
e988a9276c MSVC9 project file update for TEX nodes 2008-11-26 17:34:10 +00:00
Benoit Bolsee
c508db5659 MSVC9 project file update for blenderplayer 2008-11-26 17:23:22 +00:00
Andrea Weikert
8449f0d776 == MSVC projectfiles ==
update for texture nodes
2008-11-12 21:03:42 +00:00
Benoit Bolsee
6b86f835f8 MSVC90 project files: Tune projects build order to allow error-free build from clean state. 2008-11-11 16:48:34 +00:00
Benoit Bolsee
61a83d2fba Add MSVC90 project files - part 3. Extern and Intern projects are merged in projectfiles_vc9\blender\blender.sln solution, you just need to open that solution to compile everything with VS2008. 2008-11-10 21:22:22 +00:00