- when an fcurve had no selected keyframes, a default fallback value was used which caused view-selected to include frame 1, even when no selected frames were there.
- the vertical axis was always reset, ideally we would center vertically too but the way this operator currently works we only know about the frame range,
now don't change the vertical scroll when viewing selected since it would always jump to the top of the screen (view-all still acts this way).
Code around draw objects became safe for threading
and no special workaround is needed in scene update
anymore.
Unused buffers will be freed next time window is
drawing. Some further tweaks maybe needed to how
buffers are freeing, but things shall work for now
nice and stable.
This commit adds per-thread statics for object
update threads which would give you information
about:
- How much objects each thread handled
- How much overall time thread spend on running
object_handle_update.
- How long each of object_handle_update took.
Enabled by ./blender -d
The code is surrounded by ifdef, so shall be
not a problem to drop the code when we don't
need it anymore.
Also added special value for rt (debug_value)
of 13666 which switches scene update to a
single thread. Useful for benchmarking.
This new macros could be used to benchmark overall
execution time of some chunk of code, running in cycle.
The usage is:
void foo(void) {
TIMEIT_BLOCK_INIT(overall_bar);
for (...) {
...
TIMEIT_BLOCK_BEGIN(over_bar);
bar();
TIMEIT_BLOCK_END(oberall_bar);
...
}
TIMEIT_BLOCK_STATS(overall_bar)
}
This would print total time which was spent on
running function bar().
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.
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.
This was in fact really nasty bug, caused by multitex_nodes
function using global variable R (which is a copy of current
renderer). this variable is not initialized to anything
meaningful for until first rendering (preview or final)
happened.
Since multitex_nodes might be used outside of render pipeline,
made it so whether CM is on or off as an argument to functions
multitex_ext_safe and multitex_ext. Now multitex_nodes() is
only shall be used for stuff happening from render pipeline!
Also needed to make some changes to other places, so all the
usages of texture sampling knows for the fact whether CM is
on or off.
And one more change is related on behavior of dispalcement,
wave, warp, weightvg modifiers and smoke. They'll be always
using CM off since texture is used for influence, not for
color.
It's rather bigger patch, but it's mostly straightforward
changes, which we really need to be done.
Reviewed by Brecht, thanks!
- BLI_strncpy_wchar_from_utf8 wasn't NULL terminating the destination string, caused uninitialized memory use in BPY_python_start().
- BLI_strncpy_wchar_as_utf8 could write one byte past the buffer bounds.
With deformations and on a simple cube you could get axis flipping with normal-particle alignment.
now use the normal & tangent to create the orientation to give a stable matrix that wont flip.
This matrix was used to store the space the object is in,
which then was accessed by snapping code. No reason to
keep it as a global variable (which isn't safe for threading,
unlikely it'll give issues now, but it's easy to avoid
issues early here).
Now made it so BKE_object_where_is_calc_ex will get an
optional parameter originmat and set this matrix in
solve_parent.
Original patch by self, minor changes by Campbell, thanks!
