= Hide 3D Cursor in Paint Modes (with exceptions)
In paint modes, the 3D Cursor mostly is rather useless so it's more annoying than useful. This patch aims to hide the cursor in cases it's not used.
Included exceptions (cases where cursor is drawn in paint modes):
* Active object is in weight paint mode and a selected bone in pose mode can be found
* Clone brush (only if //Clone from paint slot// is disabled)
There might be more exceptions where the cursor should be shown in paint modes, but those are all I could find for now. Feel free to hint me for more.
Note: After D1110 was rejected, Campbell and me discussed this a bit more on IRC and agreed that this behaviour might be a good solution.
Reviewers: psy-fi, campbellbarton
Reviewed By: psy-fi, campbellbarton
Projects: #user_interface
Differential Revision: https://developer.blender.org/D1113
This reverts commit 4ca4f04c75.
Was running an fs-stat on redraw, on every file! (every mouse motion!).
Could become very slow on network-fs
also caused crash (T43631)
Our new guarded allocator implementation has much smaller memory
block size overhead and doesn't have any locks now. So in order
to make fuller track of what's happening in blender and avoid
confusion why certain circumstances reports much less memory than
others we'll now switch to guarded allocator.
This was actually one of the biggest reasons of the confusion in
the recent memory usage investigation. There's still some overhead
is happening due to non-freeing nature of arena allocator but the
things are not nearly as bad as they looked before: memory overhead
is measured in tens of megabytes, not hundreds as it looked before.
Plus with some smarter allocation policy we can almost eliminate this
overhead.
Did not had any issue on linux, but looks like on some windows can slow things as Hell.
Or maybe just the presence of some network FS?
Anyway, not a good idea, so now fsmenu entries' valid status is stored and only evaluated
on startup (reading of bookmarks & co) and when opening file browser (refresh, like
for system bookmarks).
background.
For SSAO supporting this is no problem, for DOF we would ideally do
blurred alpha, but alpha channel in blurred buffers is occupied by coc
field, so use original color alpha instead. It's not entirely correct
but it's better than nothing.
Support for user-defined customdata layers (named int, float, string
layers) was limited to polygon customdata. This is not accessible in
cycles because only tessfaces are used there. Furthermore the polygon
attributes were simply described as MeshFloatProperty, MeshIntProperty,
MeshStringProperty, omitting the distinction by element type.
The patch only adds vertex attributes so far. However, the code now
explicitly defines polygon and vertex attributes, so adding edges, loops
and tessfaces is much easier should the need arise.
Problem is that the RNA definition, which is already much more
complicated than the basic DNA/BKE definition of custom properties, now
becomes extremely bloated and cumbersome. A simpler solution would be
preferable but may not be possible within the constraints of RNA.
Could connect a pair of verts previously,
now connect all vertices along the path, running a second time closes the loop.
Can also be used for without faces to connect edges between selected points.
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.
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?
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".
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.
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.
- 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
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
This reverts the change made in 8872cba7e9
which was contributing to actions being lost in some cases [1], even when
they were assigned to those actuaters, which needed them to be able to
function. Now there's one less case where users are needed but were missing :)
Note that this still doesn't solve the core issue where nothing is responsible
for associating actions created for a particular datablock (and not currently
being used in its active action slot, or in the NLA stack) with that datablock.
That issue is the cause of most action disappearances as well as for other problems
(such as renaming bones being unable to fix unreferenced/unused actions) where there
are diifferences between users' mental models and the data model. Proper fixes are
coming soon (restoring fake users here isn't a proper fix, as it only masks the
fundamental mismatch/problem here).
[1] http://blenderartists.org/forum/showthread.php?357021-BGE-loses-actions
This way both BLI_assert() and abort() called directly shouldn't
leave any files in the temp folder.
Previously it was really possible to have gadzillions of files
left over because of assert failures and debug aborts during the
development process.
