Blender Git Loki

This piece of code was also a part of experiment

Merging r59825 through r59873 from trunk into soc-2013-depsgraph_mt

Remove piece of code which shouldn't have been sent to SVN

It was left from some experiments.

Disable render constraints evaluation for now

This is needed to prevent possible regressions caused
by viewport/render conflict which are using the same
ob->obmat and be able to commit current work to SVN.

Initial support of render mode for constraints

Rendering now works rather fine, but because of object matrix
is shared between viewport and render, objects might be placed
on the wrong locations in viewport after rendering.

Shrintwrap modifier will use proper derived mesh in render mode

Still to come: constraints are still using viewport derived mesh,
need to pass EvaluationContext there.

Mark some TODOs as solved.

Some of them were actually out-of-date, some other didn't
need any code changes (code was good after double-check).

Objects will now restore their derived caches nicely after rendering in locked UI

Before this it was possible some objects didn't update properly because of lack
of dependency handling.

Added check for last datamask used for derivedRender calculation

That's perhaps not too much difference for now, because it seems
all places are using the same data mask for derived render, but
better be safe and robust here than sorry.

Alternative would be to remove dataMask from API here and always
use hard-coded mask in DerivedMesh.c for derivedRender.

Merging r59797 through r59824 from trunk into soc-2013-depsgraph_mt

Merging r59766 through r59796 from trunk into soc-2013-depsgraph_mt

Merging r59745 through r59765 from trunk into soc-2013-depsgraph_mt

DerivedRender cleanup and improvements

- Use special flags in DagNode for tags and scheduled
instead of trying to use color for this. This way
it's possible to have both tag and scheduler working
at the same time.

- Simplified DAG threaded traversal code, moved comments
to depsgaph instead of documenting what functions does
when using them.

- Switch from recursive tag flush to iterative one.

- Set scenes shall be handled properly in convertblender.

- Removed derivedRender construction from handle object
update function. It doesn't make much sense to have it
in both there and convertblender.

- Creating new task pool now ensures malloc is switched
to thread-safe one.

- Create derivedRender in threads using the same way as
it's done for object update. In really quick tests
gave around 2x speedup of database_init_objects when
having 130 suzannes with subsurf level of 3.

Merging r59735 through r59744 from trunk into soc-2013-depsgraph_mt

Merging r59657 through r59734 from trunk into soc-2013-depsgraph_mt

Quick followup for the previous commit to prevent crashes when having dependency cycles.

Pass EvaluationContext to object update routines

Main purpose of this change is to get rid of legacy
G.is_rendering check to distinguish whether update
happens for viewport or for render purposes.

Currently EvaluationContext structure only contains
single field, which indicates whether update happens
for viewport or render, but in the future it might
be extended by all the stuff needed for duplis and
friends.

This commit also gets rid of derived mesh creation
fro modifier stack for operand objects (like second
operand for boolean). This was only confusing and
violated threaded update actually. Now modifier stack
assumes all the dependencies are met and derived
meshes for operand objects might be just used.

This requires some changes to renderer as well,
so now there's also a derivedRender stored in object
structure. It also solves old TODO when boolean
will use preview setting for it's operand subsurf
level.

There's still the whole bunch of TODOs:
- Duplis might have some regressions when rendering.

- External render engines are to be take care about
(there might be some regressions for them as well,
because they're for sure not aware of derivedRender).

- Viewport required DAG_on_visible_update when changing
current screen to keep all DMs up-to-date. The same
happens when changing the scene, so perhaps this is
correct thing to have anyway.

- Render database is doing some tricks to make sure
derivedRender for invisible objects but which are
needed for other objects are properly calculated.

It uses some recursion and might end up with some
crashes if having dependency cycles.

This is to be changed to non-recursive algorithm
which would be aware of cycles as well. API might
have some cleanup as well.

- Ideally, derivedRender shall be calculated in threads
(same as what's happening in scene evaluation).

- Currently only meshes are being changed. Other types
of objects are not expected to change any behavior.

Merging r59654 through r59656 from trunk into soc-2013-depsgraph_mt

Merging r59633 through r59653 from trunk into soc-2013-depsgraph_mt

Merging r59551 through r59632 from trunk into soc-2013-depsgraph_mt