Summary:
Old idea with changes since previous release tag
didn't work good enough. In most of the cases tag
was done in a branch hence not actually reachable
from the master branch.
Now change since release is gone, and date of
the latest commit is used instead.
The date is displayed in format YYYY-MM-DD HH:mm
in the splash.
New bpy.app fields:
- build_commit_timestamp is an unix timestamp of
the commit blender was build from.
- build_commit_date is a date of that commit.
- build_commit_time is a time of that commit.
Reviewers: campbellbarton
Differential Revision: http://developer.blender.org/D5
- Use commit number since last annotated tag as a
revision number replacement. It'll eb followed
by 'M' symbol if there're local modification in
the source tree.
- Commit short SHA1 is included. Helps getting
information about commit used to build blender
with much faster.
- If build is not done from master branch, this also
will be noticed in the splash screen.
This commit also replaces revision stored in the
files with git-specific fields (change and hash).
This is kind of breaks compatibility, meaning
files which were saved before this change wouldn't
display any information about which revision they
were saved with. When we'll finally switch to git,
we'll see proper hash and change number since
previous release in the files, for until then
svn version will be used as a change number and
hash will be empty.
Not a huge deal, since this field was only used
by developers to help torubleshooting things and
isn't needed for blender itself.
Some additional tweaks are probably needed :)
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.
* '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.
- script execution is off by default
- if a blend file attempts to execute a script
this shows a message in the header with the action
that was suppressed (script/driver/game-autostart) and 2 buttons to either reload the file trusted, or to ignore the message.
- the file selector will always default to use the trust setting in the user preferences,
but reloading an open file will keep using the current setting (whatever was set before or set on the command-line).
- added SCons setting WITH_BF_PYTHON_SECURITY, this sets the default state for the user prefereces not to trust blend files on load.
... this option was in CMake before, but always off, now its enabled by default for SCons and CMake, and forced on in CMake for now.
down, this time by the operator properties getting converted to a string for
display in the info window.
With 1000+ stroke points this can get slow, and takes up too much space anyway,
so now it's (somewhat arbitrarily) limited to printing only 10 points.
- enable site-packages for bundled python distrobution, py3.2 had a problem where it would try to parse headers we didnt include, but its resolved now.
- workaround for glitch I was having on arch-linux where lib64 would be be used for the bundled python directory when it was just a symlink.
Most of the places which relied on RNA_path_resolve() did so believing that if
it returned true, that it had found a valid property, and that the returned
pointer+property combination would be what the path referred to. However, it
turns out that if the property at the end of the path turns out to be a
"pointer" property (e.g. "data" for Object.data), this would automatically
become the pointer part, while the prop part would be set to null. Hence, if a
user accidentally (or otherwise) specifies a path for the single-property driver
variable type like this, then Blender would crash.
This commit introduces two convenience functions - RNA_path_resolve_property()
and RNA_path_resolve_property_full() - which mirror/wrap the existing
RNA_path_resolve() functions. The only difference though is that these include a
check to ensure that what was found from resolving the path was in fact a
property (they only return true iff this is the case), and make it explicitly
clear in the name that this is what they will do so that there's no further
confusion. It is possible to do without these wrapper functions by doing these
checks inline, but the few cases that had been patched already were pretty
hideous looking specimens. Using these just make it clearer and simpler for all.
I've also beefed up the docs on these a bit, and changed these to using bools.
