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 is mostly the same fix as before, but now code depending on culling
checks is executed after KX_Scene->CalculateVisibleMeshes(). As a
side-effect, LoD checks and animation culling now use the current
frame's culling information rather than the previous frame's.
Due to skinning changes for multi-threaded animations, the LOD check was
being done after skinning. Now the LOD check is run before animations.
This means the culling information is a frame old, but this should be
fine.
Levels of detail can be added and modified in the object panel. The object
panel also contains new tools for generating levels of detail, setting up
levels of detail based on object names (useful for importing), and
clearing an object's level of detail settings. This is meant as a game
engine feature, though the level of details settings can be previewed in
the viewport.
Reviewed By: moguri, nexyon, brecht
Differential Revision: http://developer.blender.org/D109
Fix: to swap the drawing order for the warp mesh polygon
The code was drawing CW instead of CCW.
It would work in some cases where the drawing flags would allow for the
back faces to be visible.
More specifically the alternative fix were:
glDisable ( GL_CULL_FACE );
glFrontFace( GL_CW );
Bug originally reported in the small_planetarium mailing list.
This bug fix was a comissioned job by a group who prefer not to be
credited. Thanks regardless.
viewport. This helps to eliminate OpenGL calls in weird places like the physics
code and to reduce glGet calls, which are expensive.
There should be no functional changes (except maybe a very slight speed improvement).
note: this was never correct and not a single soul bothered noticing that.
not really a surprise, this mode is more for debug than for anything else.
to test go to (game engine) Render -> Dome Mode -> Spherical Panorama
thanks to Aldo Zang to help me spotting the problem.
The funny thing is: I only spotted this bug in March of this year. Almost one year after the original release. I think I don't parent objects to the camera often.
In terms of code I think that I can even think in a more elegant solution. I don't really need to rotate the camera, but simply to calculate its Modelview Matrix.
"""
m_rasterizer->SetViewMatrix(viewmat, cam->NodeGetWorldOrientation(), cam->NodeGetWorldPosition(), 1.0);
cam->SetModelviewMatrix(viewmat);
"""
The reason why I originally was rotating the camera was to make sure the frustum calculation was using the right camera frustum. For the frustum it takes the camera modelviewmatrix so the rotation really shouldn't be necessary. Leaving as it's for the time being.
* Note: the bug was never officially reported
* Convert all code to use new functions.
* Branch maintainers may want to skip this commit, and run this
conversion script instead, if they use a lot of math functions
in new code:
http://www.pasteall.org/9052/python
- Size adjustments can be accomplished with warp mesh data now. So we get a free spot in the GUI for a tilt option.
- Tilt option to tilt the camera (for planetarium domes).
Angle is in degree from -180 to +180. It's needed for planetarium domes (as this one http://domejunky.blogspot.com/2009/05/dome-corrected-bge.html ).
- This is the last commit regarding dome code I expected to 2.49. I consider this feature full implemented now. (working on docs now)
Commit 20099 started using a FBO way too big.
According to Paul Bourke this is how it's done in other Engines:
Projectors HD:
1920x1050 - buffersize = 1024; FBO size = 2048
1400x1050 - buffersize = 1024; FBO size = 2048
Projectors XGA:
1024x768 - buffersize = 512; FBO size = 1024
Now in Blender Game Engine we are using:
Projectors HD:
1920x1050 - buffersize = 1050; FBO size = 2048
1400x1050 - buffersize = 1050; FBO size = 2048
Projectors XGA:
1024x768 - buffersize = 768; FBO size = 1024
(I guess I should be committing code to the ge_dome branch instead of the trunk. I feel bad doing all those adjustments in a hurry to 2.49 final release in the trunk. That is ok, right?)
*) a small note:
In the end it turned out that we have upright and downright domes out there.
So I may rearrange the order of the gui later:
(1 = fisheye, 2 = truncated up, 3 = truncated down, 4 = envmap, 5 = spherical panoramic)
I don't plan to do a doVersion() for that, so if you are using it already keep in mind that the modes may change before 249 final release.
After last commit (20099) warping meshes got slower (more quality == less performance). Since we don't need an extra warping for truncated domes, It's better to handle them directly in openGL without the need of warping it.
I'll talk with some Dome owners to see if we need both Upright and Downright modes. I may remove one of them by 2.49 them.
*) also: a proper GLEW_EXT_framebuffer_object check before generating FBO (for warping meshes).
**) next in line (maybe after RC2): tilt option to tilt the camera up to 90º upward.
