Blender Git Commits

patch [#31925] Add a BMElemSeq.sort() method
from Antonio Ospite (ao2)


wrap bmesh sort function for python api, eg:

bm.faces.sort(key=lambda f: f.material_index)

code cleanup: replace cos(M_PI / 4) and sin(M_PI / 4) with M_SQRT1_2 define

also some minor style cleanup.

code cleanup: simplify view orbit operator

code cleanup: remove unused math functions (where already noted as deprecated)

code cleanup: use cosf and sinf when both args and results are float values.

also remove local math functions in KX_Camera

Bugfix [#32017] Infinite recursion in depsgraph material/node driver handling

When initially coding this functionality, I was aware of the potential for
infinite recursion here, just not how frequently such setups are actually
used/created out in the wild (nodetree.ma_node -> ma -> ma.nodetree is all too
common, and often even with several levels of indirection!).

However, the best fix for these problems was not immediately clear. Alternatives
considered included...
1) checking for common recursive cases. This was the solution employed for one
of the early patches committed to try and get around this. However, it's all too
easy to defeat these measures (with all the possible combinations of indirection
node groups bring).
2) arbitrarily restricting recursion to only go down 2/3 levels? Has the risk
of missing some deeply chained/nested drivers, but at least we're guaranteed to
not get too bad. (Plus, who creates such setups anyway ;)
*3) using the generic LIB_DOIT flag (check for tagged items and not recurse down
there). Not as future-proof if some new code suddenly decides to start adding
these tags to materials along the way, but is easiest to add, and should be
flexible enough to catch most cases, since we only care that at some point those
drivers will be evaluated if they're attached to stuff we're interested in.
4) introducing a separate flag for Materials indicating they've been checked
already. Similar to 3) and solves the future-proofing, but this leads to...
5) why bother with remembering to clear flags before traversing for drivers to
evaluate, when they should be tagged for evaluation like everything else?
Downside - requires depsgraph refactor so that we can actually track the fact
that there are dependencies to/from the material datablock, and not just to the
object using said material. (i.e. Currently infeasible)

svn merge ^/trunk/blender -r49107:49118

fix for own error using uninitialized memory for scale compo node.

fix for more new[]/delete[] mismatches

fix for compositor new[]/delete[] mismatch.

Fix #32156: Blender crashes on linking armature with custom shape

Crash was caused by using NULL pointer as a wire color for drawing
object selection when drawing flag is set to DRAW_CONSTCOLOR.

Solved by not calling drawObjectSelect when DRAW_CONSTCOLOR flag
is set, which seems reasonable -- rather than adding checks deeper
in all possible functions which are being called there easier to
just not call that functions using a single check.

Add property to stitch operator to clear seam flag of stitched edges (on
by default, since people usually want the layout to be updated).
Motivation has been confused user that tried to use live unwrap
afterwards and found that it would not work as it should.

fix for node editor re-rendering when the background image was moved in the view.

Increase maximal video bitrate to 64K

Aimed to #32153: H.264 Output Bitrate Max of 14000 kb/s is Too Low

Removed nested comment, which causes compiler errors.

style cleanup

Merging r49105 through r49107 from trunk into soc-2011-tomato

Boolean modifier: prevent crashes when carve returns bad topology

For sure actual issue is in carve's triangulation system which need
to be investigated and fixed. For now only fixed by re-shuffling a
bit existing degenerative faces check and added extra checks there.

Would look into actual fix a bit later.

style cleanup

svn merge ^/trunk/blender -r49082:49104