corrently allows to create and loop over verts/edges/faces, access selection and selection modes.
this is still WIP, access to face, edge verts is still missing, no access to UV's, no access to editing operations yet.
When the api is ready it will be documented by sphinx like mathutils, blf, aud.
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.
- rename 'bcycles' --> '_cycles', since this is the python convention when a py module uses a C module internally.
- use macros for returning None
- make with_osl an attribute rather then a function.
- changes methods METH_VARARGS --> METH_O when single args are used.
from Andrew Hale (trumanblending)
Tracker description
*******************
The current python noise module included with Blender has yet to be updated to the new Py API. This patch does so, with the following major points:
- The noise module has now been moved to a submodule of mathutils, it can be accessed by mathutils.noise. It was moved from it's own module as it will now return mathutils types and also have greater visibility to the user.
- All functions which return vectors will now return mathutils.Vector types to be consistent with the rest of the API. Previously (x, y, z) tuples were returned.
- A different implementation of random_unit_vector is now used, this allows 2D, 3D and 4D vectors to be returned. Previously only 3D was possible.
- Some function names have been changed to remove ambiguities and make naming consistent within the module. noise.vector is now noise.noise_vector and noise.vl_vector is now noise.variable_lacunarity
- Doc strings have been updated to be compatible with auto docs.
- Code style and internal naming has been changed to match the conventions in other mathutils code.
Thanks,
Andrew
without this printing a unicode string may raise an error which is a real pain especially since script authors often forget this and print the path of a file for example on export which can make a script fail outright when writing to paths with certain encodings.
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
* Windows installer not working for non-admin users and multiple users
* Addon scripts not installing next to user configuration
* Portable install not being taken into account in all places
The main problem was the windows installer was installing system scripts in
AppData next to the user configuration directory, which is not shared between
users. Now these are installed in ProgramFiles, and only addon scripts added
by the users go to AppData.
On all platforms, addon scripts were sometimes getting installed between
system scripts, because the scripts folder in the executable directory was
given precedence over the user configuration folder, that is no longer done
now. So addons now behave like user configuration, they are preserved even
if you download a newer build of the same blender version.
If you have an installation of 2.57 on windows, the addon install location
will not change until we do the version bump to 2.58, to avoid conflicts with
the existing the installed 2.57 version.
The old behavior of giving precedence to the local folder was done to support
portable install, where all configuration is written to the local folder. This
is now implemented differently: if and only if a "config" folder exists in the
local folder, portable install will be assumed, and files will only be written
to that local folder.
