I have no idea why this hasn't been implemented before (the DEFINES were even there already). But since the Ipo (Fcurve) Actuator supports it I don't see why Action and ShapeKey shouldn't.
More than a new feature or a bugfix this is actually a step forward into unifying them.
Support for physics is done by skiping the modifiers that
don't support mapping to original mesh. This mapping is
required to report the hit polygon to the application
by the rayCast() function.
Support for graphics is done by using the same render
function that blender uses for the 3D view. This guantees
equal result.
Limitation: there is still a known bug if all these conditions are met:
- Display list enabled
- Old tex face with a several textures mapped to the same material
- no armature or shape keys
- active modifiers
In this case, only a part of the mesh will be rendered
with the wrong texture. To avoid this bug, use the GLSL
materials or make sure to have 1 material=1 texture in
your old tex face objects.
Since rev.2 (hans ftw) we have a strange situation where horizon color was being used at Convert time for the WorldInfo background color (and for the fog). However through the Python API only the Rasterizer background color was being updated. On top of that the KX_KetsjiEngine.cpp::SetBackGround was using the WorldInfo bgcolor when render mode was the potato one (TEXTURED). Bottomline, when in potato mode the glClearColor used was the original one in worldinfo, not the API updated one in Rasterized.
Problem/Bug:
------------
There were no way to have proper unicode characters (e.g. Japanese) in Blender Game Engine. Now we can :)
You can see a sample here: http://blog.mikepan.com/multi-language-support-in-blender/
Functionality Explanation:
--------------------------
This patch converts the Blender Font Objects to a new BGE type: KX_FontObject
This object inherits KX_GameObject.cpp and has the following properties:
- text (the text of the object)
- size (taken from the Blender object, usually is 1.0)
- resolution (1.0 by default, maybe not really needed, but at least for debugging/the time being it's nice to have)
The way we deal with linked objects is different than Blender. In Blender the text and size are a property of the Text databock. Therefore linked objects necessarily share the same text (and size, although the size of the object datablock affects that too). In BGE they are stored and accessed per object. Without that it would be problematic to have addObject adding texts that don't share the same data.
Known problems/limitations/ToDo:
--------------------------------
1) support for packed font and the <builtin>
2) figure why some fonts are displayed in a different size in 3DView/BGE (BLF)
3) investigate some glitches I see some times
4) support for multiline
5) support for more Blender Font Object options (text aligment, text boxes, ...)
[1] Diego (bdiego) evantually will help on that. For the time being we are using the "default" (ui) font to replace the <builtin>.
[2] but not all of them. I need to cross check who is calculating the size/dpi in/correctly - Blender or BLF. (e.g. fonts that work well - MS Gothic)
[3] I think this may be related to the resolution we are drawing the font
[4] It can't/will not be handled inside BFL. So the way I see it is to implement a mini text library/api that works as a middlelayer between the drawing step and BLF.
So instead of:
BLF_draw(fontid, (char *)text, strlen(text));
We would do:
MAGIC_ROUTINE_IM_NOT_BLF_draw(fontir, (char *)text, styleflag, width, height);
[5] don't hold your breath ... but if someone wants to have fun in the holidays the (4) and (5) are part of the same problem.
Code Explanation:
-----------------
The patch should be simple to read. They are three may parts:
1) BL_BlenderDataConversion.cpp:: converts the OB_FONT object into a KX_FontObject.cpp and store it in the KX_Scene->m_fonts
2) KetsjiEngine.cpp::RenderFonts:: loop through the texts and call their internal drawing routine.
3) KX_FontObject.cpp::
a) constructor: load the font of the object, and store other values.
b) DrawText: calculate the aspect for the given size (sounds hacky but this is how blf works) and call the render routine in RenderTools
4) KX_BlenderGL.cpp (called from rendertools) ::BL_print_game_line:: Draws the text. Using the BLF API
*) In order to handle visibility of the object added with AddObject I'm adding to the m_scene.m_fonts list only the Fonts in a visible layer - unlike Cameras and Lamps where all the objects are added.
Acknowledgements:
----------------
Thanks Benoit for the review and adjustment suggestions.
Thanks Diego for the BFL expertise, patches and support (Latin community ftw)
Thanks my boss for letting me do part of this patch during work time. Good thing we are starting a project in a partnership with a Japanese Foundation and eventual will need unicode in BGE :) for more details on that - www.nereusprogram.org - let's call it the main sponsor of this "bug feature" ;)
- Object actuator rotation was being scaled by: (1/0.02)*2*PI/360 == 0.872, since revision 2.
- Remove scaling and use do_versions to adjust existing files.
- incorrect range check broke ZYX euler rotations, use MIN/MAX constants so this doesn't happen again.
- BGE Armature PyAPI also wasn't using correct min/max with rotation modes.
- clamp on file read rather then when calling the rotation functions, so developers don't use invalid args without realizing it.
- added assert() checks for debug builds so invalid axis constants don't slip through.
Simple python benchmark shows this to be about 3x faster in the case where an update isn't needed.
This also speeds up rna function argument parsing, since each arg in a function call did 2 string lookups on the context which were never needed.
running a shape actuator on a softbody would crash because it assumed the deformer was a BL_MeshDeformer.
Added TODO note, since it would be nice if softbody would work with shape keys too.
globbing vs explicit is discussed here.
http://www.cmake.org/pipermail/cmake/2008-December/025694.html
Practical implications are:
- developers need to keep CMakeLists.txt files up to date.
- Users wont get strange linking errors if they build after a file is added, since CMake detects CMakeLists.txt is modified and automatically reconfigure.
- ignore MSVC warnings when FREE_WINDOWS is defined to quiet warnings.
- the CMake flags were not being set correctly making blender have weirdo colors (no -funsigned-char).
This patch allows a user to pass binary data to LibLoad() to load a blend file from memory instead of a file path. I don't know how useful this will be for others, but I've used it so far for:
* Decrypting .blend files and loading them without having to store the .blend on the hard drive
* Pulling .blend data out of an archive and loading it (again skipping the hard drive)
So, it seems the biggest use for this is skipping a bit of file IO (and possibly some security problems).
Example usage:
import bge
with f as open('myfile.blend', 'rb'):
data = f.read()
bge.logic.LibLoad('Name', 'Scene', data)