Previous patch was not sorting the state actuators. This was causing
some problems with YoFrankie that relies on the order of actuators
when multiple state actuators are activated at once.
Active state actuators will now be sorted per object. This doesn't
change the fact that state actuators are executed before all other
actuators as before.
Incidently, made the logic loop faster.
A new type of "Sensor" physics object is available in the GE for advanced
collision management. It's called Sensor for its similarities with the
physics objects that underlie the Near and Radar sensors.
Like the Near and Radar object it is:
- static and ghost
- invisible by default
- always active to ensure correct collision detection
- capable of detecting both static and dynamic objects
- ignoring collision with their parent
- capable of broadphase filtering based on:
* Actor option: the collisioning object must have the Actor flag set to be detected
* property/material: as specified in the collision sensors attached to it
Broadphase filtering is important for performance reason: the collision points
will be computed only for the objects that pass the broahphase filter.
- automatically removed from the simulation when no collision sensor is active on it
Unlike the Near and Radar object it can:
- take any shape, including triangle mesh
- be made visible for debugging (just use the Visible actuator)
- have multiple collision sensors using it
Other than that, the sensor objects are ordinary objects. You can move them
freely or parent them. When parented to a dynamic object, they can provide
advanced collision control to this object.
The type of collision capability depends on the shape:
- box, sphere, cylinder, cone, convex hull provide volume detection.
- triangle mesh provides surface detection but you can give some volume
to the suface by increasing the margin in the Advanced Settings panel.
The margin applies on both sides of the surface.
Performance tip:
- Sensor objects perform better than Near and Radar: they do less synchronizations
because of the Scenegraph optimizations and they can have multiple collision sensors
on them (with different property filtering for example).
- Always prefer simple shape (box, sphere) to complex shape whenever possible.
- Always use broadphase filtering (avoid collision sensor with empty propery/material)
- Use collision sensor only when you need them. When no collision sensor is active
on the sensor object, it is removed from the simulation and consume no CPU.
Known limitations:
- When running Blender in debug mode, you will see one warning line of the console:
"warning btCollisionDispatcher::needsCollision: static-static collision!"
In release mode this message is not printed.
- Collision margin has no effect on sphere, cone and cylinder shape.
Other performance improvements:
- Remove unnecessary interpolation for Near and Radar objects and by extension
sensor objects.
- Use direct matrix copy instead of quaternion to synchronize orientation.
Other bug fix:
- Fix Near/Radar position error on newly activated objects. This was causing
several detection problems in YoFrankie
- Fix margin not passed correctly to gImpact shape.
- Disable force/velocity actions on static objects
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
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...
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.
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.
* Where possible use vec.setValue(x,y,z) to assign values to a vector instead of vec= MT_Vector3(x,y,z), for MT_Point and MT_Matrix types too.
* Comparing TexVerts was creating 10 MT_Vector types - instead compare as floats.
* Added SG_Spatial::SetWorldFromLocalTransform() since the local transform is use for world transform in some cases.
* removed some unneeded vars from UpdateChildCoordinates functions
* Py API - Mouse, Ray, Radar sensors - use PyObjectFrom(vec) rather then filling the lists in each function. Use METH_NOARGS for get*() functions.
* giving compileflags, cc_compileflags and cxx_compileflags to BlenderLib() now actually overrides any other setting (so there's no unclarity when ie. conflicting options are being specified in REL_CFLAGS et al). These are set after either release or debug flags, but before any *_WARN flags (so those stay maintained).
* add cxx_compileflags for GE parts on win32-vc to have better performance.
* NOTE: if platform maintainers (OSX and Linux) could check and do the same for their systems. Not vital, but probably very, very much welcomed by GE users.
This situation corresponds to a group containing only a portion
of a parent hierarchy (the Apricot team needed that to avoid
logic duplication). The BGE will instantiate only the
children that are in the group so that it follows the 3D view
more closely.
As a result, the logic links to the objects in the portion of the
hierarchy that was not replicated will point to inactive objects
(if the groups are stored in inactive layers as they should be).
To keep the logic system consistent, these links are automatically
removed.
This last part of the patch is a general fix that could go in
2.47 but as this situation does not normally occurs in pre-2.47
games, it is not needed.
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.
+ 'scons blenderplayer' builds blender AND blenderplayer now (tested on Linux
only, but was only linking issue, so should work on other platforms too).
NOTE: I noticed some compileflags for GE specific libs that were left out -
I re-enabled them in the SConscripts, but I'm going to do a test build my-
self now, so if there are problems with them on win32, I probably already
know about them :)
* This commit is all of the rewrite work done on the SCons system. For
documentation see doc/blender-scons.txt and doc/blender-scons-dev.txt.
Also http://mediawiki.blender.org/index.php/BlenderDev/SconsRefactoring
contains valuable information, along with what still needs to be done.
- linux, os x and windows compile now.
- files are compiled to BF_INSTALLDIR (see config/(platform)-config.py)
- NOTE: Jean-Luc P will commit sometime during the weekend proper
appit() for OS X. For now, copy the resulting binary to an
existing .app bundle.
- features:
- cleaner structure for better maintenance
- cleaner output during compile
- better handling of build options
- general overall speed increase
- see the wiki for more info
Cygwin, FreeBSD and Solaris systems still need work. For these systems:
1) copy a config/(platform)-config.py to ie. config/cygwin-config.py
2) set the proper defaults for your platform
3) mail me at jesterking at letwory dot net with you configuration. if
you need any modifications to the system, do send a patch, too.
I'll be giving first-aid today and tomorrow, after that it'll be all
regular development work :)
/Nathan
Keyboard sensors can now hook escape key. Ctrl-Break can be used from within blender if you've forgotten an end game actuator.
Fixed a stupid bug preventing some actuators working (like TrackTo).
Profiling revealed that the SceneGraph updated every physics object, whether it moved or not, even though the physics object was at the right place. This would cause SOLID to go and update its bounding boxes, overlap tests etc.
This callback handles the special case (parented objects) where the physics scene needs to be informed of changes to the scenegraph.
Added Python attributes (mass, parent, visible, position, orientation, scaling) to the KX_GameObject module.
Make KX_GameObject use the KX_PyMath Python <-> Moto conversion.
[SCons] Build with Solid as default when enabling the gameengine in the build process
[SCons] Build solid and qhull from the extern directory and link statically against them
That was about it.
There are a few things that needs double checking:
* Makefiles
* Projectfiles
* All the other systems than Linux and Windows on which the build (with scons) has been successfully tested.
* Blender static now links. By default this option is disabled on all
platforms. Simply set the option in config.opts to 'true'.
* Added the following flags to config.opts:
- HOST_CC. This is the C compiler for the host platform. This value is the
same as TARGET_CC when not cross compiling.
- HOST_CXX. This is the C++ compiler for the host platform. This value is
the same as TARGET_CXX when not cross compiling.
- TARGET_CC. This is the C compiler for the target platform.
- TARGET_CXX. This is the C++ compiler for the target platform.
- TARGET_AR. This is the linker command for linking libraries.
- PATH This is the standard search path
All SConscript files have been updated to reflect these changes. Now it's
possible to change only the root SConstruct file, and all compiler specific
variables are passed automatically to all SConscript files. Of course, this
does not apply to makesdna because there the host and target platform is
different from all other libraries.
To pass a variable that applies to all platforms, all we now have to do is
set the correct value in library_env
Note: as usual, to get the latest options in the config.opts file, first
remove your version.
* libraries are now generated in [BUILD_DIR]/lib
* passed the user_options to all libraries now.
This means I could remove a couple of Export/Import lines.
* Changed the order in source/blender/src/SConscript and
source/gameengine/SConscript.
All libraries are now sorted alphabetically. This has no impact on the build
process.
* Windows .exe file now includes the blender icon.
* Builds with game engine on Windows only.
I tried building the game engine on Linux, but I get weird errors when
building with ode. There's a dirty #include path in
Physics/BlOde/OdePhysicsEnvironment.cpp (../ode/src/joint.h). gcc doesn't
like this somehow.
* Other platforms need to add a couple of flags to the SConstruct:
use_sumo, use_ode, solid_include and ode_include
Materials are exported the best we can do by now. It will look almost as in
blender except for the missing procedural textures and some minor issues.
You have to tweak normal modulation amount to get the desired result cause
is not the same in yafray.
We added a panel in render space to adjust some yafray settings (GI and so)
Also we export transparency and reflection using new raytracing settings,
but that will be changed and improved soon.
Remember that you have to set YFexport path in user defaults and yafray must
be on path (version 0.0.6)
We added the "yafray" button to activate all this stuff in the render window.
Panel and settings are only shown when checked.
So now when activated the code calls yafray export instead of the internal
renderer and finally the resulting image is loaded back into render window's
buffer. So animation is also possible and results can be saved using blender
usual scheme.
(adding)
#ifdef HAVE_CONFIG_H
#include <config.h>
#endif
also the Makefile.in's were from previous patch adding
the system depend stuff to configure.ac
Kent
--
mein@cs.umn.edu
