We now have openimageio building when cycles builds or when it's
manually set to build.
(I reverted the _IMAGE_ in the define name because I think the closer
the cmake flags match the defines in the software the better, and there
is no reason to rename all the existent WITH_OPENIMAGEIO references in
CMakeLists.txt - which would be the alternative)
We now support the combined layer of Photoshop files (stored as layer 0
in the file). This way users can keep their files as multilayer PSD and
Blender always handle them as flat images.
For perfect alpha this requires an OpenImageIO update:
342cc2633f
Photoshop sample files:
https://github.com/OpenImageIO/oiio-images
Brecht has some pending fixes to push for OIIO as well, so we may as
well wait to update our libraries.
What works:
===========
* 8bit images (with or without alpha)
* 16bits images (alpha discarded)
* Photoshop files saved with 'Maximum Compatibility'
* Cycles, Blender internal, BGE (and player)
Known limitations
(due to OIIO dependency):
=========================
* Images with less than 4 channels show a wrong thumbnail (bug may be in OIIO)
* Packed images are not supported
* We do not write PSD files.
Note: old Blenders have support for PSD via Quicktime library. But due
to license issues this was discontinued.
Many thanks for Brecht van Lommel for reviewing the patch, suggesting
multiple improvements and to help solving the alpha issue.
When printing operator reports, ommit unset properties.
This is needed because in some cases operators check if a value is set or not, so filling in default arguments may change behavior.
- make cmake osx use of -ftemplate-depth match scons.
- use array size within sizeof(), more compact.
- replace AT with __func__ where the function is unique enough.
- BLI_box_pack_2D -> 2d to match other functions.
- rename new mesh normal calculation to mesh.calc_normals_split()
* 'Show Debug' now enabled for all newly created drivers. For most users, it is
useful to be able to see this to help figure out what's going on
* Removed failed experiment of creating new drivers with Generator FModifiers. I
had hoped that this would make it easier to create drivers that doubled or
halved the input values, but that has proved to not be the case, and instead
made harder for most users to set things up (as they'd have to remove these
first).
Now, when adding drivers from the UI, these get created with two keyframes (at
(0,0) and (1,1) for a 1-1 mapping), which can be easily tweaked normally.
However, for backwards compatability of scripts (notably rigify, and perhaps
some others out there), when creating drivers from scripts, they will still get
created with Generator FModifiers for now. We can review this situation again
for 2.7, but for now it seems ok.
This means calling invoke operators from python in states that dont support will give a meaningful error message.
also reduce context lookups when polling.
Any parameter after the first flagged with PROP_PYFUNC_OPTIONAL will be considered as optional, hence the python code does not have to define/use it. This will ease API evolutions by avoiding to break existing code when adding non-essential new parameters.
Note: this will need some update to API doc generation, patch is ready, will have it reviewed by Campbell asap.
now, instead of making hidden copies of faces, the faces are copied into a temp bmesh.
also remove a hash that was being created and not used (old code).
- calc normals only check flag when needed.
- keymap, dont get name unless its needed.
- keymap, avoid property lookup.
- idprop debug print, include pointer, helpful for troubleshooting.
