Blender Git Commits

Fix T43671: Playing with Mix Factor of Data Transfer Modifier Is Overwritting Data of Base Mesh

The issue was actually affecting all data types that are not regular CDLayer ones, since by default
DerivedMesh references mesh data (verts, edges, etc. - modifying custom normals often implies
modifying edges' sarpness too).
Modfying edge/face sharpness etc. could directly affect the mesh in this case, **bad**!

So we detect whether we are copying data types that may affect non-CDlayers data, and whether
verts array of org dm is same as mesh one - in which case we copy the DM. This avoids
useless copying in most cases.

Note Edit Normals was quite obviously suffering the same issue.

Cleanup of SpaceFile, from asset-experiments branch mostly.

Helps keeping diff with branch relevant and clean...

Fix for previous commit, sorry for the noise.

Cleanup: BLI_listdir (direntry): get rid of usage of raw malloc/free here.

No reason at all not to use MEM_xxx as everywhere else, especially confusing
when members of direntry **are** MEM_-allocated (relname, etc.)!

Possible todo notes for more polished UI?

Outliner: "Purge All" function for Outliner in "Orphaned Datablocks" mode

Many users have been requesting a way to remove unused datablocks from the file/session
"without closing and reopening" Blender (or at least that's the impression I'm getting).

This commit adds a new operator (exposed as the "Purge All" button in the header of
the "Orphaned Datablocks" mode in the Outliner, which seems to be the logical
place for this) for doing so. It does so by wrapping up the save and "revert"
(i.e. reload the saved file from disk, without needing to quit Blender) operators
along with a confirmation prompt for good measure.

Caveats:
* Ultimately, we still cannot really cleanly delete any datablocks from the current
session outright without reloading the file/data at some point. Thus, we do need
to reload the file again before it can be used.
* This does mean that this operation is irreversible. Notably, Undo history is lost
is doing this operation. Hence the warnings... (Then again, undo/redo actually
reloads the entire scene DB from memory, so it's not anything uncommon ;)

Other Notes:
* The addition of this operator brings this mode more into line with being a kind of
"Trashcan" place, with this new operator being the manual "Empty Trash" button.
If the "Orphaned Datablocks" name is too obscure, maybe we could rename this
mode to "Trash" or something similar?

Code Cleanup: Reshuffle libraries and orphaned datablocks views to a more appropriate place in the file

Outliner: Do not show RMB menu for "ID Base" entries

Outliner: Use restriction columns in "Orphaned Datablocks" view to manage usercounts

When in "Orphaned Datablocks" mode, the restriction columns are used to display
usercount indicators and toggles to manage whether datablocks get saved or not.

* The first column shows an icon to indicate whether that datablock is going to get
saved. A tick indicates the datablock will be saved, while a cross indicates the
opposite. Clicking on this changes whether the datablock will get saved.

* The second column shows the usercount.

* The third column shows whether the datablock has a fake user.


Notes:
* The second and third columns are pretty much redundant (functionally speaking).
While it is possible to also toggle fake users by clicking in the third column,
its role here is more as information for power users (and hopefully to allow others
to connect the relationship between the saved/not saved status and fake users)

* I'm not sure whether the use of the X here for the "not saved" state stands out enough
to draw user's attention to items which are "in the danger zone".

Outliner: Added new mode for displaying "orphaned" datablocks

Orphaned datablocks are those which have either:
* 0 users
* A "fake" user only

In the case of the former, they will be quietly discarded from the file on the next
save + reload. Hence, it is helpful to have a view where you can confirm which ones
fall into this category and might be worth saving.

We also include datablocks with a fake user only so that datablocks given a user
above can have that easily turned off again (in case the user makes a mistake).
Another benefit of showing these is that it become easier to remove fake users from
datablocks you no longer want retained without having to hunt for them.

Revert/Remove "Auto View" Feature

Turned out that I misinterpreted the feature request, plus there are some
minor issues with the commit that would need to be corrected.
After all, I decided to just remove it again as it seems to not be really
useful for the users.

missed this second last commit

mathutils: Implement __hash__() functions

- all mathutils types
- only works on frozen data (so vectors can be used in sets/dict keys)
- uses same method as CPython, (matches hashing a tuple)

D1104 by @juicyfruit with own modifications

mathutils: add freeze() method, is_frozen attr

This allows you to make any mathutils object immutable.

mathutils: remove redundant read callback

mathutils: avoid extra alloc for Vector.lerp

Fix crash setting Euler.order to a non-string

Fix T42919 & T42218: BGE: Python-driven armature animation got buggy

Due to changes in the way animation updates were handled,
BL_ArmatureObjects were no longer registering to KX_Scene as animated.

Moguri says: It might have been relying on the deformer update which
moved rom being called on every object in the render step. Now
armature deformers are only updated if they need to be.

Fix T42919 & Fix T42218

Cycles: Fix wrong attribute count calculation in prevous commit

The workaround for generated texture coordinates is to be done before
calculating number of elements for attribute, otherwise counter wouldn't
include those attributes.

Cycles: Optimize memory usage when creating mesh attributes

The idea behind the change is to pre-allocate attribute arrays in advance,
which avoids re-allocation of arrays later for each of meshes being handled.

This reduces peak memory used by Cycles database from 1.3G to 0.9G for
victor.blend from Gooseberry.

It doesn't mean every file will benefit from this change since peak memory
usage is happening in the different places of the rendering code.

Also, unfortunately, attributes export might not cause the peak of render
preparation stage. That said, it's actually object_to_mesh() which causes
the memory to peak in the same test file. So we really need to optimize that
part first in order to get visible results for artists. But in any case it's
now quite easy to track hotspots in Cycles itself which is good.