This commit adds:
* A new bpy.app.translations module giving some info about locales/translation stuff (current active locale, all locales currently known by blender, all translation contexts currently defined, etc.).
* The ability for addons to feature translations, using the (un)register functions of above module.
* Also cleans up "translate py string when storing into RNA prop" by removing "PROP_TRANSLATE" string's subtype, and adding a PROP_STRING_PY_TRANSLATE flag instead (this way it is no more exposed to python...).
Addon translations work with py dictionaries: each addon features a dict {lang: {(context, message): translation, ...}, ...}, which is registered when the addon is enabled (and unregistered when disabled).
Then, when a key (context, message) is not found in regular mo catalog, a cache dict for current locale is built from all registered addon translations, and key is searched in it.
Note: currently addons writers have to do all the work by hand, will add something (probably extend "edit translation" addon) to automate messages extraction from addons soon(ish)! To get a look to expected behavior from addons, have a look at render_copy_settings/__init__.py and render_copy_settings/translations.py (rather stupid example currently, but...). Once we have a complete process, I'll also update relevant wiki pages.
- bpy.path.extensions_image
- bpy.path.extensions_movie
- bpy.path.extensions_audio
eg:
if os.path.splitext(filename)[1].lower() in bpy.path.extensions_image:
... we have an image ...
- move object_iterators.c --> view3d_iterators. (ED_object.h had to include ED_view3d.h which isn't so nice)
- move projection functions from view3d_view.c --> view3d_project.c (view3d_view was becoming a mishmash of utility functions and operators).
- some some cmake includes as system-includes.
The rendering device is now set in User Preferences > System, where you can
choose between OpenCL/CUDA and devices. Per scene you can then still choose
to use CPU or GPU rendering.
Load balancing still needs to be improved, now it just splits the entire
render in two, that will be done in a separate commit.
Merging the node changes required a lot of conflict resolution, fixed the
issues I could find but if you want stability you might want to wait a bit
before updating.
shader = gpu.export_shader(scene,material)
Returns the GLSL shader that blender generates to produce the visual effect
of material in scene for the purpose of reusing the shader in an external engine.
This function is meant to be used in a material exporter so that the GLSL
shader can be exported entirely. The return value is a dictionary containing the
shader source code and all associated data.
The full documentation is under sphinx.
Warning: there has been an API between the patch and this commit:
uniform['lamp'] and uniform['image'] now return python reference to
ID block instead of ID name as before. The X3D exporter that uses this
function must be adapted.
* add some (disabled) test code for using OpenImageIO in imbuf
* link cycles, openimageio and boost into blender instead of a shared library
* some cmakefile changes to simplify the code and follow conventions better
* this may solve running cycles problems on windows XP, or give a different
and hopefully more useful error message
Python:
* adds bpy.app.handlers which contains lists, each for an event type:
render_pre, render_post, load_pre, load_post, save_pre, save_post
* each list item needs to be a callable object which takes 1 argument (the ID).
* callbacks are cleared on file load.
Example:
def MyFunc(scene): print("Callback:", data)
bpy.app.handlers.render_post.append(MyFunc)
C:
* This patch adds a generic C callback api which is currently only used by python.
* Unlike python callbacks these are not cleared on file load.
blender_add_lib now takes a separate include argument to suppress warnings in system includes (mostly ffmpeg & python).
also only build wm_apple.c on apple+carbon configuration.
this is not well suited to RNA so this is a native python api.
This uses:
bpy.data.libraries.load(filepath, link=False, relative=False)
however the return value needs to use pythons context manager, this means the library loading is confined to a block of code and python cant leave a half loaded library state.
eg, load a single scene we know the name of:
with bpy.data.libraries.load(filepath) as (data_from, data_to):
data_to.scenes = ["Scene"]
eg, load all scenes:
with bpy.data.libraries.load(filepath) as (data_from, data_to):
data_to.scenes = data_from.scenes
eg, load all objects starting with 'A'
with bpy.data.libraries.load(filepath) as (data_from, data_to):
data_to.objects = [name for name in data_from.objects if name.startswith("A")]
As you can see gives 2 objects like 'bpy.data', but containing lists of strings which can be moved from one into another.
CMake build option WITH_PYTHON_MODULE, will build ./bin/bpy.so
This allows 'bpy' to be imported from python or other applications/IDE's which embed python, eg:
python -c "import bpy ; bpy.ops.render.render(write_still=True)"
This runs in background mode and has similar restrictions to running a script:
blender --background --python test.py
TODO:
- install to site-packages with blender scripts
- add support for imp.reload()
