Thanks to Brecht for the reviews. :)
This commit adds a show/hide extension below each uiList, containing by default an option to filter and/or reorder items by name (and to reverse those filtering and reordering).
Each derived uiList class in Python can define more specific filtering by implementing callbacks: the draw_filter() function to draw options in UI, and the filter_items() function to effectively filter/reorder items.
Note: the advanced options for vgroups shown as "proof od concept" in patches do not go in trunk for now, we have to find a better way to get those vgroups info for UI code, we can't afford to loop over each vertex here!
And doc (release notes and uiList example) is still to be updated, will do this in next days.
Many thanks to Brecht for the review!
* You can now drag-resize uiLists (in default or grid layouts).
** Note about "default" size: when you drag below minimal size of the uiList, it will automatically reset to automatic sizing (i.e. size between rows and maxrows, depending on the number of items to show). This often means (e.g. in Materials list with many mat slots) that the list will grow again to maxrows!
* Grid uiLists now have a customizable number of columns (previously it was a fixed value of 9), and they will respect the rows/maxrows settings as well (i.e. show a scrollbar when needed), instead of growing indefinitly!
- any error in cloth_build_springs wasn't freeing the edge-hash.
- was checking BLI_edgehash_haskey on matching vertices.
- was looping over setting NULL for all elements of a calloc'd array.
In previous optimization in outliner I assumed that order in treehash was not important.
But testing outliner in datablocks mode revealed a problem: when user expands multiple recursive levels and then closes any element, it always closed the top level of recursion.
Now it should work fine with recursive trees.
Now treehash contains groups of elements indexed by (id,nr,type). Adding an element with the same (id,nr,type) results in appending it to existing group. No duplicates are possible in treehash.
This commit should also make lookups a little bit faster, because searching in small arrays by "used" is faster than searching in hashtable with duplicates by "id,nr,type,used".
calloc. Since we copy the first 1/1.3 part of the new array from the
existing nodes, only the rest 0.3/1.3 should be initialized to zero.
This should in theory cut down the times of occasional hangs with
dyntopo, since my guess is that it is caused by dynamic reallocations.
Maybe a linked list structure would help here? This is a bigger change
though, leaving as is for now.
Also, minor cleanup, delete duplicate ghash deletion and remove unneeded
commented code.
That ended up in tricky code trying to mimic depsgraph
branch behavior API-wise preserving texspace and bound
box calculation compatible with previous releases.
So for now bring cu->disp back to the trunk but keep
texpsace and boundbox APIs the same as in the branch.
This keeps texpsapce and boundbox behavior fully compatible
with previous releases and still makes API the same as
for meshes.
Simply recalc sequence len for audio (and meta!) strips when modifying fps value. Note start, startofs and endofs are also updated, to try to keep final pos and length as consistent as possible.
initialization. In sculpt mode, when using shift-click to switch to the
smooth brush it was possible to ommit initialization of curvemapping for
that brush.
* Actually check if normal recalculation flags exists and set it when
splitting nodes in dyntopo. Right now, nodes that need GPU buffer update
will always get in the list to get their normals generated, but to avoid
a possible future breakage better do it right now.
* Avoid keeping deleted/removed vertices in vertex-to-node and unique
vertex hashes, since some checks rely on those and may go awry if these
still exist. Also they pollute the hashes, and may hurt performance
somewhat.
It's a bit dumb to store render-time bevel list in
object's curve_cache, but that's how blender already
used to work for ages.
Proper fix is suspended for tomorrow :)
Turn off pbvh normal update flag after recalculation, saves
recalculating normals every frame when not stroking the mesh.
For this to work reliably with undo we need to support original normals
in the bm_log (was marked as a TODO already in the code), so that
undoing avoids having invalid normals in the mesh (since we don't update
every frame anymore). This was added in this commit as well.
Also added some (disabled) quite paranoid checks in the bmesh valication
code for dyntopo hoping to catch the real normal update issue. No luck
there yet.
Particle system code used global variable to sort hair by orig index,
which is not safe for threading at all.
Replaced this with usage of reentrant version of qsort, which is
now implemented in BLI. It was moved from recast navigation code
to BLI, so more areas could use it (if needed).
--
svn merge -r59086:59087 ^/branches/soc-2013-depsgraph_mt
This commit fixes two different issues, which were caused by
how weights are being calculated for relative shapekeys.
Weights for key block used to saved in KeyBlock DNA structure,
which lead to situations when different objects could start
writing to the same weights array if they're sharing the same
key datablock.
Solved this in a way so weights are never stored in KeyBlock
and being passed to shapekeys routines as an array of pointers.
This way weights are still computed run-time (meaning they're
calculated before shapekey evaluation and freed afterwards).
This required some changes to GameEngine as well, to make it
never cache weights in the key blocks.
Another aspect of this commit makes it so weight for a given
vertex group is only computed once. So if multiple key blocks
are using the same influence vertex group, they'll share the
same exact weights array. This gave around 1.7x speedup in
test chinchilla file which is close enough to if we've been
caching weights permanently in DNA (test machine is dual-code
4 threads laptop, speedup measured in depsgraph_mt branch,
trunk might be not so much high speedup).
Some further speed is optimization possible, but it could be
done later as well.
Thanks Brecht for idea of how the things might be solved in
really clear way.
--
svn merge -r58786:58787 ^/branches/soc-2013-depsgraph_mt
Apparently, some routines in armature deformation code
were using static arrays. This is probably just an
optimization thing, but it's very bad for threading.
Now made it so bbone matrices array is allocating in
callee function stack. This required exposing
MAX_BBONE_SUBDIV to an external API, This is not so
much crappy from code side, and it shall be the same
fast as before.
--
svn merge -r58278:58279 ^/branches/soc-2013-depsgraph_mt
Lattice deformation used to store some runtime data
inside of lattice datablock itself. It's something
which is REALLY bad. Ideally DNA shouldn't contain
and runtime data.
For now solved it in a way that initialization of
lattice deform will create a structure which contains
lattice object for which deformation is calculating
and that runtime data which used to be stored in
lattice datablock itself.
It works really fine for mesh deform modifier, but
there's still runtime data stored in particle system
DNA, It didn't look something easy to be solved, so
leaving this as-is for now.
--
svn merge -r58277:58278 -r58795:58796 ^/branches/soc-2013-depsgraph_mt
Getting vfont data wasn't safe for threading, because it
was modifying font data which is in bmain and could be
shared by multiple objects.
For now made it so getting vfont uses critical section,
meaning vfont->data is initializing from inside a locked
mutex.
--
svn merge -r58168:58169 ^/branches/soc-2013-depsgraph_mt
