Blender Git Commits

BGE Rasterizer Cleanup: Removing RAS_IRenderTools and moving the functionality to RAS_IRasterizer. RAS_OpenGLRasterizer is a bit of a mess now with references to Ketsji and other modules it shouldn't be accessing.

UI messages fixes...

Missing convert button on particle modifier panel. Cache pathcache check
should be only on path display mode.

Update i18n tools for new build_hash...

bullet: Remove patch applied upstream

Made buildinfo aware of builds from GIT

- 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 :)

add CDDM_lower_num_loops(), for completeness (currently unused).

code cleanup: typo in function name

Bugfix [#36950] Restrict Frame Range not being obeyed on Driver F-Curves

By default, drivers (used to) automatically map the driver result (i.e.
"evaltime" or the x-coordinates in the driver graphs) to results. This evaltime
=> cvalue mapping is necessary when there are absolutely no keyframes or
modifiers on a driver F-Curve, or else nothing would happen.

However, when there are modifiers on these driver F-Curves, and these modifiers
only work within certain ranges, there would be confusing and unwanted
situations where even if you clamped the modifiers to only generating a curve
within certain frame ranges, the final driver output would still ignore the
results of the curve due to the underlying 1-1 mapping.

This commit introduces a check to ensure that this automatic mapping won't
happen during such invalid ranges.

Fix for uninitialised var

code cleanup: remove unused operator (select all handles this case now)

Fix [#37297] Crash when Adding and Removing Fluid Particlesystem.

Using freed mem...

Fix [#37275] can't import 2.68a keymap

Now exported keymaps will still be usable accross versions, even if some operator properties disappear (write a warning in console in this case, instead of "crashing").

Also factorized a bit of code here!

Minor code improvements: avoid unnecessary Python object allocations in Freestyle color blending.

Fix for missing calls of BaseMath_ReadCallback() when accessing vector/color elements.
This bug was causing wrong color blending results in Freestyle color modifiers.
Problem report from Light BWK through personal communications, thanks!

OSX: Fix an error in own 61065

Motion tracking: use is_keyed to match naming in other areas of RNA

code cleanup: warnings

OSX: give application bundles an own icon to better differentiate vs. folders

Bugfix [#36687] Animation channels can't be grouped in action editor

Internal filtering flags used to obtain AnimData blocks as result were not
working correctly in Action and ShapeKey modes. Instead, in these modes, they
were often returning F-Curves instead, which lead to the grouping operating
failing (and perhaps other unidentified bugs)