Instead of allocating scheduler and starting threads
on every object_update call make it so scheduler is
global and threads are always ready to run.
This was we could avoid quite hacky thing which is
counting how much objects need to be updated before
starting threaded update.
It'll also allow using the same scheduler to do all
sorts of tasks, not only objects update in the same
scheduler. This is nice from load balancing point of
view.
Couple of changes were needed to be done in task
scheduler itself:
- Free tas before sending notifier.
- Free TaskThread structures outside from thread.
This is needed to make it possible use begin/end
threaded malloc from the main thread before/after
running the pool. Without this change it was possible
that allocation will switch to non-thread mode while
thread is freeing the task.
This required storing TaskThread array in Scheduler,
but it's not so much bad actually, since it also
reduces memory overhead caused by per-thread allocation.
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).
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.
* Added a Ray Depth output to the Light Path node, which gives the user access to the current bounce.
This can be used to limit the maximum ray bounce on a per shader basis. Another use case is to restrict light influence with this, to have a lamp only contribute to the direct lighting.
http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/More#Light_Path
This is part of my GSoC 2013 project. SVN merge of r58091 and r58772 from soc-2013-dingto.
Clean up inconsistencies in the libmv C API:
- All type identifiers are libmv_TypeName
- All function identifiers libmv_functionName
- Prefer libmv_nounVerb function names (e.g. libmv_featuresDestroy)
- Match Blender code formatting rather than Google
- Spelling corrections
Code review: https://codereview.appspot.com/11494044/
actually just point to existing defined stack values. To make the link check work, set the socket->link pointer if internal node connections exist, this works for both muted and reroute nodes.
necessary.
Problem was/is that the nodes can set the 'type' property, but in order to actually change the data type they would also need to update the typeinfo pointer (and idname), which is strongly discouraged.
Solution is to just replace the input/output sockets of the reroute node with new sockets of the desired type and port all links over.
This significantly lowers the position of outliner_draw_tree_element in profiler
and partially fixes [#36260] (2,300 Objects Makes Blender Unresponsive)
- memset() was argument was truncated.
- outliner had redundant NULL check.
- node texture was allocating memory to make a unique name which isnt needed for a fixed size string.
