Blender Git Loki

Merge branch 'master' into asset-engine

Cycles: Remove unused flag

Cycles: Transform undisplaced coordinates into world space for bump shader eval

Forgot to do this, shading should be correct now for transformed objects.

Merge branch 'master' into temp-cycles-microdisplacement

made particle radius factor field accessible

Merge branch 'master' into soc-2016-multiview

First (totally experimental and useless) version of a future 'BlenderCloud' asset engine.

For now it's nothing but an empty shell - but a working proof of concept of how to 'embed'
that ugly asyncio-based stuff into a background working thread for asset engines.

Hopefully more funny stuff to come soon(ish).

Merge branch 'master' into asset-enginea, and update for new 'checkdir' behavior/expectations.

Conflicts:
source/blender/editors/space_file/filelist.c

Grr, forgot that fix in previous commit...

Add/use BKE_object_boundbox_to_worldspace

Merge branch 'master' into soc-2016-multiview

Merge branch 'master' into viewport_bvh_select

Avoid allocating bounding boxes

Support selecting empties using new BVH selection

Adding support for all empty draw types was a bit more involved, but things work now ;)

Stats Editor:
* Add new notifier for the stats space type
* Add logging_type DNA/RNA, which will be used to toggle between the different log types. We certainly will have more types here, this needs to be discussed further. For now we have
Operators, Rendering and Depsgraph.
* Add basic space stats notifier listener.

Support selecting speakers using new BVH selection

Support selecting lamps using new BVH selection

Add experimental 'asyncio-based' version of Amber.

This was done to both test asyncio usage in an 'asset engine' context, and wet my feet with this lib.

All in all, am really not convinced by asyncio in this use-case. async and coroutines are much more
complex to grasp and get working correctly (and efficiently!) than mere threading.
Further more, most python lib callbacks (os.listdir, os.ls_stat, etc.) are not async-ready,
so you have to call them through asyncio's executor (aka threads or processes),
which means using asyncio in this context is only adding overhead.

I think asyncio is only really relevant when you have to handle tens (and much more) concurrent I/O tasks,
otherwise threading (or multi-processing if compute-intensive) are much, much simpler to get working,
and also probably lighter in terms of overload?

Further more, asyncio paradigm is not so easy to adapt to the 'AssetEngine' paradigm, i.e. a
python interface that gets called to start, query and finalize jobs that are supposed to keep running
in-between (think event loop should run in a background thread actually...).

small fix for obstacle flag

Merge branch 'master' into asset-engine