This time issue was caused by static variables used in
BKE_scene_base_iter_next function.
Change is not so much ultimate actually, but didn't
find more clear solution for now. So the changes are:
- Wrap almost all the static variables into own context-
like structure, which is owned by the callee function
and getting passed to the iteration function.
- Recursion detection wasn't possible with such approach,
so recursion detection still uses static in_next_object
variable, but which is now stored in thread local
storage (TLS, or thread variable if this names are more
clear for you).
This makes code thread-safe, but for sure final solution
shall be completely different. Ideally, dependency graph
shall be possible to answer on question "which object is
a motherball for this metaball". This will avoid iterating
via all the bases, objects and duplis just to get needed
motherball.
Further, metaball evaluation ideally will use the same
kind of depsgraph filtering, which will get result for
question like "which objects belongs to this group of
metaballs".
But this ideal things are to be solved in Joshua's and
mind GSoC projects.
Tested on linux (gcc and clang) and windows (msvc2008),
hopefully no compilation error will happen.
Thanks to Brecht for reviewing the change and getting
feedback for other possible ways we've dicussed!
the way Curve.len is used at the moment is really stupid, calculate string size on save for now, but should really store the length in bytes and total number of characters.
- calc normals only check flag when needed.
- keymap, dont get name unless its needed.
- keymap, avoid property lookup.
- idprop debug print, include pointer, helpful for troubleshooting.
internal viewport rendering. Lots of tweaks here, mainly:
* Stop 3D viewport render and free database before undo.
* Accumulate update flags rather than replace them each time it rerenders, to
avoid previous updates getting lost.
* Don't check against Render struct view parameters for changes, those are set
in the job thread which might not run before the next update call.
Now the viewport rendering thread will lock the main thread while it is exporting
objects to render data. This is not ideal if you have big scenes that might block
the UI, but Cycles does the same, and it's fairly quick because the same evaluated
mesh can be used as for viewport drawing. It's the only way to get things stable
until the thread safe dependency graph is here.
This adds a mechanism to the job system for jobs to lock the main thread, using a
new 'ticket mutex lock' which is a mutex lock that gives priority to the first
thread that tries to lock the mutex.
Still to solve: undo/redo crashes.
becomes too small. Typically this would happen if the number of buckets
is clipped to the maximum value. This avoids thread overhead.
A better fix might be to do bucket-brush intersection on main thread and
dispatch threads to process bucket hits as they become available. This
way only one thread at most would end up being used in such cases
anyway. A better task scheduler is needed for that though, leaving for
after GSOC.
Some objects from scene could have dupligroup with objects
which are not in the scene. This case wasn't checked by
workaround for threaded display object free routines.
We really need to have threading issues with display
objects solved.
- normals depended on the meshes rotation, so you could rotate Suzzane and in some cases one of the eye normals would be flipped.
- normals depended on the meshes placement in relation to the meshes center, now find the outer most face by each face-island center.
The bugs were about not respecting edge smoothness and
not respecting edge crease. This change copies the
edge attributes from a beveled edge to the two outside
edges of the bevel.
custom pynodes tree edited directly as library data would get a 0 user count on reload and subsequently not be saved. Now the node space follows the same pattern as the image space: the node tree(s) user
count gets incremented on file load and opening in the editor ensures a real user. This leads to 1 "unreal" user for the editor (dropped on reload), but seems to be the only viable solution atm.
Issue goes back to 2.4x days at least (but very much likely the
issue is even older). It's caused by subdivision code was starting
to iterate points from previous one, which shifted all the points
by one.
Reshuffled code so now iteration starts from first spline point.
Thanks to Campbell for review and tests! :)
The crash was caused by a reference of freed memory in add_halo_flare() that relied
on the global variable R to retrieve a list of objects. The value of this variable
is invalidated by a nested execution of the Blender Internal renderer for Freestyle
stroke rendering, leading to the documented memory reference issue.
keys in menus (or tooltips) for properties they are used to toggle/cycle through
Some properties can be toggled using hotkeys via WM_OT_context_* operators, but
these hotkeys aren't really shown anywhere obvious like other hotkeys (i.e.
they're not shown in tooltips or menus). Although it is possible to look these
up in the userprefs/keymaps editor, it is quite tricky doing so, and most users
would just assume that since no shortcut is displayed, there simply isn't one at
all.
This commit introduces a slightly hacky fix which basically amounts to checking
if a property can be set by any of the few operators which are used for this
purpose. In order to keep this from being too sluggish, I've currently limited
this to only working on Editor (e.g. "Show Seconds" in Anim Editors) and
ToolSettings (e.g. "Use Proportional Edit") properties.
There are still some corner cases that would be nice to solve too (i.e. the
Pivot Type enum menu/dropdown should really be able to show the hotkeys which
have been assigned for each of those items, since they're by-and-large quite
hidden and obscure), though being able to show some of these is perhaps better
than not showing any!
- Use the active group of the active (target) object (not the active group of the other, unselected object)
- Ensure the active group doesnt change from the one that was set originally.
- defgroup_find_name was doing redundant lookup on its self.
