bge.logic.setRender(flag) to enable/disable render.
The render pass is enabled by default but it can be disabled with
bge.logic.setRender(False).
Once disabled, the render pass is skipped and a new logic frame starts
immediately. Note that VSync no longer limits the fps when render is off
but the 'Use Frame Rate' option in the Render Properties still does.
To run as many frames as possible, untick the option
This function is useful when you don't need the default render, e.g.
when doing offscreen render to an alternate device than the monitor.
Note that without VSync, you must limit the frame rate by other means.
fbo = bge.render.offScreenCreate(width,height,[,samples=0][,target=bge.render.RAS_OFS_RENDER_BUFFER])
Use this method to create an offscreen buffer of given size, with given MSAA
samples and targetting either a render buffer (bge.render.RAS_OFS_RENDER_BUFFER)
or a texture (bge.render.RAS_OFS_RENDER_TEXTURE). Use the former if you want to
retrieve the frame buffer on the host and the latter if you want to pass the render
to another context (texture are proper OGL object, render buffers aren't)
The object created by this function can only be used as a parameter of the
bge.texture.ImageRender() constructor to send the the render to the FBO rather
than to the frame buffer. This is best suited when you want to create a render
of specific size, or if you need an image with an alpha channel.
bge.texture.<imagetype>.refresh(buffer=None, format="RGBA", ts=-1.0)
Without arg, the refresh method of the image objects is pretty much a no-op, it
simply invalidates the image so that on next texture refresh, the image will
be recalculated.
It is now possible to pass an optional buffer object to transfer the image (and
recalculate it if it was invalid) to an external object. The object must implement
the 'buffer protocol'. The image will be transfered as "RGBA" or "BGRA" pixels
depending on format argument (only those 2 formats are supported) and ts is an
optional timestamp in the image depends on it (e.g. VideoFFmpeg playing a video file).
With this function you don't need anymore to link the image object to a Texture
object to use: the image object is self-sufficient.
bge.texture.ImageRender(scene, camera, fbo=None)
Render to buffer is possible by passing a FBO object (see offScreenCreate).
bge.texture.ImageRender.render()
Allows asynchronous render: call this method to render the scene but without
extracting the pixels yet. The function returns as soon as the render commands
have been send to the GPU. The render will proceed asynchronously in the GPU
while the host can perform other tasks.
To complete the render, you can either call refresh() directly of refresh the texture
to which this object is the source. Asynchronous render is useful to achieve optimal
performance: call render() on frame N and refresh() on frame N+1 to give as much as
time as possible to the GPU to render the frame while the game engine can perform other tasks.
Support negative scale on camera.
Camera scale was previously ignored in the BGE.
It is now injected in the modelview matrix as a vertical or horizontal flip
of the scene (respectively if scaleY<0 and scaleX<0).
Note that the actual value of the scale is not used, only the sign.
This allows to flip the image produced by ImageRender() without any performance
degradation: the flip is integrated in the render itself.
Optimized image transfer from ImageRender to buffer.
Previously, images that were transferred to the host were always going through
buffers in VideoTexture. It is now possible to transfer ImageRender
images to external buffer without intermediate copy (i.e. directly from OGL to buffer)
if the attributes of the ImageRender objects are set as follow:
flip=False, alpha=True, scale=False, depth=False, zbuff=False.
(if you need to flip the image, use camera negative scale)
This patch improves clock management in BGE, to be able to accelerate /
slow the time, and also to finely synchronize clock with external
engines. Several new python functions have been added and existence ones
have been improved for that purpose. Now we have:
- getClockTime(): Get the current BGE render time, in seconds. The BGE
render time is the simulation time corresponding to the next scene that
will be rendered.
- getFrameTime(): Get the current BGE frame time, in seconds. The BGE
frame time is the simulation time corresponding to the current call of
the logic system. Generally speaking, it is what the user is interested
in.
- getRealTime(): Get the number of real (system-clock) seconds elapsed
since the beginning of the simulation.
- getTimeScale(): Get the time multiplier between real-time and
simulation time. The default value is 1.0. A value greater than 1.0
means that the simulation is going faster than real-time, a value lower
than 1.0 means that the simulation is going slower than real-time.
- setTimeScale(time_scale): Set the time multiplier between real-time
and simulation time. A value greater than 1.0 means that the simulation
is going faster than real-time, a value lower than 1.0 means that the
simulation is going slower than real-time. Note that a too large value
may lead to some physics instabilities.
- getUseExternalClock(): Get if the BGE use the inner BGE clock, or rely
or on an external clock. The default is to use the inner BGE clock.
- setUseExternalClock(use_external_clock): Set if the BGE use the inner
BGE clock, or rely or on an external clock. If the user selects the use
of an external clock, he should call regularly the setClockTime method.
- setClockTime(new_time): Set the next value of the simulation clock. It
is preferable to use this method from a custom main function in python,
as calling it in the logic block can easily lead to a blocked system (if
the time does not advance enough to run at least the next logic step).
Rationale are described more precisely in the thread
http://lists.blender.org/pipermail/bf-gamedev/2013-November/000165.html.
See also T37640
Reviewers: sybren, panzergame, #game_engine, lordloki, moguri
Reviewed By: sybren, panzergame, #game_engine, lordloki, moguri
Subscribers: moguri, hg1, sybren, panzergame, dfelinto, lordloki
Projects: #game_engine
Maniphest Tasks: T37640
Differential Revision: https://developer.blender.org/D728
Mostly added missing :arg: clauses -- these caused the :type:-clauses
that were already in the RST files to be hidden from the output HTML.
I also fixed some argument types from 'list' to 'Vector' where applicable
and corrected some obvious mistakes.
By using getAnimRecordFrame(), game developers have access to the frame
number used by the "Record animation" feature. This enables them to
record additional information in Blender's F-Curves and ensuring perfect
synchronization with the information already recorded by Blender.
The setAnimRecordFrame() can be used to change the frame number at which
animations are recorded, for example to introduce delays the recording that
do not require delays in the actual game/simulation run.
The getter/setter functions in KX_KetsjiEngine are not directly named after
property they access (m_currentFrame). I found "current frame" to be too
vague for a public interface, hence chose a more descriptive name.
Reviewers: moguri, hg1, campbellbarton, panzergame, aligorith
Reviewed By: panzergame, aligorith
Differential Revision: https://developer.blender.org/D1449
This is related to Task T34861 to increase up & track axis options for TrackTo actuator. I've just added it to differential to facilitate an easier review.
With the patch applied you can select X, Y and Z axis for the Up axis, and X, Y, Z, -X, -Y and -Z for the track axis.
Related to the implementation I have used the algorithm from Trackto constrain placed in constrain.c but adapted to be used with MOTO library.
The wiki docs are here (http://wiki.blender.org/index.php/User:Lordloki/Doc:2.6/Manual/Game_Engine/Logic/Actuators/Edit_Object#Trackto_Actuator).
Test file is here: {F97623}
I have also uploaded 2 screenshots showing the UI modifications to the TrackTo actuator:
{F91992} {F91990}
Reviewers: moguri, dfelinto
Reviewed By: moguri
CC: Genome36
Differential Revision: https://developer.blender.org/D565
Disclaimer: The author of this patch is Geoffrey Gollmer (gomer). I only updated the patch to the current git master status, reworked several parts to fit well with current coding style and applied several fixes.
This actuator allows users to show/hide the mouse cursor using logic bricks, as well as control object rotation with a mouse in the BGE.
The mouse rotation is flexible enough to allow any type of mouse look, as well as banking for flight controls.
{F94520}
{F91859}
Blend file for testing Mouse actuator (with default parameters and crosshair): {F94920}
Reviewers: moguri
Reviewed By: moguri
CC: gomer, lordodin
Differential Revision: https://developer.blender.org/D559
(so one can find more about the joystick class without having to search joystick)
code untested by the way. Sorry but I can no longer build sphinx docs here. I will try to fix that later.
# Print a message when an async LibLoad is done
import bge
def finished_cb(status):
print("Library (%s) loaded in %.2fms." % (status.libraryName, status.timeTaken))
bge.logic.LibLoad('myblend.blend', 'Scene', async=True).onFinish = finished_cb
LibLoad() now returns a KX_LibLoadStatus object for information on the library loading. LibNew() and LibFree() are unaffected by this commit. In other words, the async option only works for LibLoad(). Furthermore it only works for Scenes, not Actions or Meshes.
if bge.logic.joysticks[0]:
activate_player_one()
if bge.logic.joysticks[1]:
activate_player_two()
etc..
The interface exposed by SCA_PythonJoystick is very similar to the joystick logic brick except for one key difference: axis values are normalized to a -1.0 to 1.0 range instead of -32767 to 32767, which is what the logic brick exposed.
- added API examples for mathutils.Color/Euler/Quaternion/Matrix.
- corrected own bad spelling matricies --> matrices.
- minor pep8 edits.
- update CMake ignore file list.
I named all the BGE modules with their actual names (e.g. Rasterizer, Video Texture, ...). so in the API index.html page they look more like the other Blender modules.
I did the same for the bgl module.
For bge.constraints this patch exposes the constants values for debug mode and createConstraints (they were hardcoded innts before).
+ making all the "todo" and #comments into rst comments (.. comments)
Thanks Solano, it's great to get help to those tasks :)
... and I can't test rst in windows so for now let's pretend it builds. If someone can generate the docs and see how it goes please let me know.
(plus a small fix for bge.logic rst)
First commit to make some structure in doc/ directory.
- moved source/blender/python/doc -> doc/python_api
- moved source/gameengine/PyDoc/*.rst -> doc/python_api/rst
- modified accordingly sphinx_doc_gen.py and sphinx_doc_gen.sh
(later on I'll try alternative/ scripts by neXyon as promised :)
- source/gameengine/PyDoc/ is still there because contains epydoc stuff for the bge, will ask more and look into it later
