Blender Git Commits

Remove unused argument from utility curve functions

So far it was harmless, but with upcoming changes
having this argument could be confusing from logic
point of view.

Wrap runtime curve members into own structure

This allows easier assignment on file loading,
keeps curve-specific runtime data grouped and
saves couple of bytes in Object for non-curve
types.

Get rid of crazy DAG nodes coloring when doing threaded update

DAG node already has got type field, so we could just check whether
type is ID_OB to distinguish whether object_handle_update need to
be called for node->ob.

This saves iterating via scene's bases when preparing threaded
update. This also will very much likely update objects which are
not in the scene base are used in dupli groups.

So now objects form dupli_groups are likely already properly updated
white traversing the DAG with threaded update and special hacks
are needed from main thread to update objects from dupli_groups
which was added in previous commit.

However, kept this hack for a while, need some more thoughts
and investigation.

Fix #35974: smoke flow force field icon missing in add menu.

fix [#35975] "Select Linked" = "Select All" in Weight Paint mode?
looks like this was broken since bmesh merge.

Merging r57934 through r57953 from trunk into soc-2013-depsgraph_mt

update doxygen congfig and tweaks to warnings when running doxygen.

reduce imports on startup

fix for own error in 57226, broke subsurf-uv

Fix cycles world ray visibility not working correct with multiple importance
sampling.

style cleanup

Fix for dupli-groups update going wrong

Dupli-groups used to have special case for updating
which is BKE_group_handle_recalc_and_update. This
function calls BKE_object_handle_update for every
object in the group.

This isn't thread-safe, because object could be
updating in separate thread already. And what's
worse dependencies are not known for objects inside
the group, which makes it impossible to schedule
objects from the group in a safe way.

It's even impossible to schedule groups as different
tasks, because groups could share the same objects.

For now used simple but robust solution which is
updating dupli-groups in main thread, handling
groups one-by-one and updating objects from the
group one-by-one as well.

Will work on a proper solution for this later.

Move bevel list and path from Curve to Object datablock

I know this is not so much nice to have this guys hanging
around in a general Object datablock and ideally they better
be wrapped around into a structure like DerivedMesh or
something like this. But this is pure runtime only stuff and
we could re-wrap them around later.

Main purpose of this is making curves more thread safe,
so no separate threads will ever start freeing the same path
or the same bevel list.

It also makes sense because path and bevel shall include
deformation coming from modifiers which are applying on
pre-tesselation point and different objects could have
different set of modifiers. This used to be really confusing
in the past and now dtaa which depends on object is stored
in an object, making things clear for understanding even.

This doesn't make curve code fully thread-safe due to
pre-tesselation modifiers still modifies actual nurbs and
lock is still needed in makeDispListsCurveTypes, but this
change makes usage of paths safe for threading.

Once modifiers will stop modifying actual nurbs, curves
will be fully safe for threading.

Fix issue when the same task gets added twice to the queue

Issue was caused by worker threads updating nodes valency
at the same time while we're filling the queue with "root"
nodes (leaf nodes which don't depend on others).

Added missing mutex lock around do_exit assignment in task scheduler

Without this lock it's possible that thread_wait_pop will stuck
at the point where it await for new task in the queue but in
fact exit was requested already.

This ended up in deadlock in some circumstances. Really random
because it totally depends on timings.

Initial idea of running post-modifiers out of lock wasn't correct

The tihng here is: curve is getting modified by modifier stack
and then it's coordinates are restored. To be really safe we
need to do all this locked.

Add workaroud to make threaded object update stable

Added threading lock around unsafe part of do_makeDispListCurveTypes
(parts which touches Curve->bev and Curve->path). Namely it means
pre-tesselation modifiers, bevel, path and non-modified display
list will be calculated inside a locked thread.

Post-tessellation modifiers will eb calculated outside of locked
thread, which means heavy constructive or deformation modifiers
applying on tesselated spline will be nicely threaded.

This makes it possible to use threaded object update by default
in the branch, so everyone could start testing it.

Get rid of a display list stored in Curve datablock

This display list was only used for texture space calculation,
and even there this display list was only used for bounding
box calulation.

Since we alreayd do have boundgind box in a curve datablock
there's no reason to duplicate non-modified display list
just to calculate bounding box later, let's just calculate
boundding box at the first point.

This makes code a little be more thread-safe but curves are
still not safe for threads at all because of bevel list and
path. That would be solved later.

Always use ob->bb when drawing the curve types

It used to be a check for ob->bb ? ob->bb : cu->bb but
in fact it doesn't make sense and only makes code more
crappy.

Making displist for mballs and curves/surfaces/fonts
already ensures object has walid bounding box.

Replace mutex lock with spinlock in threaded object update

It's not so much happening inside the lock and using spin
lock instead of mutex lock will give some speedup due to
smaller latency of resuming the thread when mutex was locked.