* Added Shading and Performance panels in the scene buttons,
containing the options previously in the 2.4x game menu.
* Added show framerate/debug/physics/warnings back in game menu.
* Moved these settings from G.fileflags to scene GameData.
* Enabled Display Lists by default.
* Some other small game scene button tweaks.
* Mathutils, Geometry, BGL, Mostly working, some //XXX comments for things to fix with py3
python import override (bpy_internal_import.c) so you can import python internal scripts from the BGE and running blender normally.
* Removed modules Expression and CValue, neither were ever available.
* Added GameLogic.EvalExpression(exp) from the Expression module, evaluates an expression like the expression controller (not sure if this is really that useful since python is far more advanced).
* resetting the original blend file path didint work (own fault == -> =)
* Py3.x PyModule_Create didnt allow importing since it didn't add to sys.modules,
Looks like they want us to use init-tab array, but this doesn't suit us since
it needs to be setup before python is initialized.
* Documented GameLogic.globalDict
* pressing P starts the BGE in the 3D view
* redraw window clipping isnt right
* BGE python api works in py3k (without __import__ override or Mathutils, BGL, Geometry)
* no events yet (so there is no way to exit)
svn merge https://svn.blender.org/svnroot/bf-blender/trunk/blender -r19820:HEAD
Notes:
* Game and sequencer RNA, and sequencer header are now out of date
a bit after changes in trunk.
* I didn't know how to port these bugfixes, most likely they are
not needed anymore.
* Fix "duplicate strip" always increase the user count for ipo.
* IPO pinning on sequencer strips was lost during Undo.
the original blendfile path wasn't reset when loading new blendfiles.
blenderplayer was ok, but running the BGE from blender would set the blendfile original path and never reset it on loading other blend files.
GameEngine sys.path creation was broken because of a pesky slash at the end of each path name.
Win32 sys.paths were also failing when running a game that switched between blend files in different directories
On win32 for some reason making absolute paths from lib->name failed, work around this by using lib->filename.
STR_String.h, cast to float to quiet compiler warnings.
importing "pygame" failed when running the BGE for the second time.
Rather then clearing modules, backup and restore them (as its doing with sys.path)
This way the BGE will never remember any modules imported during game play (which can cause bugs/crashes), but it also wont break pythons state by possibly removing modules that are being used internally.
For this actuator to be useful it needs to use the first opened blendfile as the base name for the configuration file.
A recent fix that made the gp_GamePythonPath always match the current loaded blend file made this actuator work differently.
keep the original filename to use for making the config name so you can load the config between loading blendfiles.
Four new buttons in World settings to control frame rate:
fps: Nominal frame rate in frame per second.
Also sets the physics timestep = 1/fps
phys: Maximum number of physics timestep per game frame in case
the actual fps is less than nominal. This allows the
physics to keep up with real time even if the graphics slows
down the game.
sub: Fixed number of simulation substeps per physic timestep.
Improves the precision of the physics simulation. Useful for
fast moving objects for example.
log: Maximum number of logic steps per game frame in case the
actual fps is less than nominal. This allows the logic
system to follow the physics simulation.
Upper bound = phys
(setting the value higher than phys has no effect).
On games with heavy logic system, it is useful to set this
value to 1, to keep logic time under control.
All these values were already accessible from Python except phys:
GameLogic.getMaxPhysicsFrame():
Gets the maximum number of physics frame per render frame.
GameLogic.setMaxPhysicsFrame(phys):
Sets the maximum number of physics timestep that are executed per render frame.
Higher value allows physics to keep up with realtime even if graphics slows down the game.
Physics timestep is fixed and equal to 1/tickrate (see setLogicTicRate)
maxphysics/ticrate is the maximum delay of the renderer that physics can compensate.
phys: integer
The modules were moved in order to access the camera internal matrixes. It will make then compatible with multiple viewports in a near future.
So far the problem I found was:
1) KX_Camera doesn't store the canvas viewport
2) RAS_ICanvas methods: GetDisplayArea and GetWindowArea are affected by multiple viewports (and they shouldn't).
Test file is here: http://www.pasteall.org/blend/68
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...
patch from Alex Fraser (z0r)
eg.
- vec.xyz = vec.zyx
- vec.xy = vec.zw
- vec.xxy = vec.wzz
- vec.yzyz = vec.yxyx
See http://en.wikipedia.org/wiki/Swizzling_(computer_graphics)
made some minor modifications to this patch.
tested access times and adding 336 attributes to vectors doesn't make a noticeable differences to speed of existing axis attributes (x,y,z,w) - thanks to python dict lookups.
- when the attribute check function failed it didnt set an error raising a SystemError instead
- Rasterizer.getMaterialMode would never return KX_BLENDER_MULTITEX_MATERIAL
- PropertySensor value attribute checking function was always returning a fail.
- Vertex Self Shadow python script didnt update for meshes with modifiers.
This function sets the maximum number of logic frame executed per render frame.
Valid values: 1..5
This function is useful to control the amount of processing consumed by logic.
By default, up to 5 logic frames can be executed per render frame. This is fine
as long as the time spent on logic is negligible compared to the render time.
If it's not the case, the default value will drag the performance of the game
down by executing unnecessary logic frames that take up most of the CPU time.
You can avoid that by lowering the value with this function.
The drawback is less precision in the logic system to physics and I/O activity.
Note that it does not affect the physics system: physics will still run
at full frame rate (actually up to 5 times the ticrate).
You can further control the render frame rate with GameLogic.setLogicTicRate().
