Cycles:
* Fix 16 byte alignment for constant hair kernel data. 

git-svn-id: https://svn.blender.org/svnroot/bf-blender/trunk/blender@59249 954f8c5b-7b00-dc11-b283-0030488c597c
Fix #34485 sculpt strength weirdly inverted with some mesh part.

The view vector was not being calculated correctly. Shamelessly rip off
correct transform to object space from projective texture painting code.

git-svn-id: https://svn.blender.org/svnroot/bf-blender/trunk/blender@59250 954f8c5b-7b00-dc11-b283-0030488c597c
correct uninitialized var, worked by accident.


git-svn-id: https://svn.blender.org/svnroot/bf-blender/trunk/blender@59252 954f8c5b-7b00-dc11-b283-0030488c597c
style cleanup: indent/whitespace


git-svn-id: https://svn.blender.org/svnroot/bf-blender/trunk/blender@59254 954f8c5b-7b00-dc11-b283-0030488c597c
add support for snapping to empty centers during transform.


git-svn-id: https://svn.blender.org/svnroot/bf-blender/trunk/blender@59255 954f8c5b-7b00-dc11-b283-0030488c597c
edit to object center snapping, exit early if unsupported.


git-svn-id: https://svn.blender.org/svnroot/bf-blender/trunk/blender@59256 954f8c5b-7b00-dc11-b283-0030488c597c
Fix warnings reported by cavity checker

git-svn-id: https://svn.blender.org/svnroot/bf-blender/trunk/blender@59257 954f8c5b-7b00-dc11-b283-0030488c597c
Fix issue with EWA filtering in compositor which disabled alpha

It was caused by wrong copy-paste thing, which replaced check
"whether alpha channel is enabled" with "whether alpha channel
is not zero" (which is always zero in accumulator).

Compositor always works with RGBA, so no need to do any special
checks here.

TODO: Maybe MapUV ode shall ignore alpha channel?

git-svn-id: https://svn.blender.org/svnroot/bf-blender/trunk/blender@59261 954f8c5b-7b00-dc11-b283-0030488c597c
Made modifiers_getVirtualModifierList safe for threading

Move static variables to context filling in by this fcuntion
and owned by a callee function. This ensures no conflicts
between threads happens because of static variables used in
this function.

Also moved modifier types and virtual modifiers data to a
function called from creator. This is needed to be sure all
the information is properly initialied to the time when
threads starts to use this data.

--
svn merge -r57899:57900 ^/branches/soc-2013-depsgraph_mt



git-svn-id: https://svn.blender.org/svnroot/bf-blender/trunk/blender@59262 954f8c5b-7b00-dc11-b283-0030488c597c
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.

--
svn merge -r57938:57939 ^/branches/soc-2013-depsgraph_mt



git-svn-id: https://svn.blender.org/svnroot/bf-blender/trunk/blender@59263 954f8c5b-7b00-dc11-b283-0030488c597c
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 calculation.

Since we already do have bounding 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
bounding 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.

--
svn merge -r57939:57940 ^/branches/soc-2013-depsgraph_mt


git-svn-id: https://svn.blender.org/svnroot/bf-blender/trunk/blender@59264 954f8c5b-7b00-dc11-b283-0030488c597c
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 data 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.

Actually, this commit also contains wrapping 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.

--
svn merge -r57938:57939 ^/branches/soc-2013-depsgraph_mt
svn merge -r57957:57958^/branches/soc-2013-depsgraph_mt



git-svn-id: https://svn.blender.org/svnroot/bf-blender/trunk/blender@59265 954f8c5b-7b00-dc11-b283-0030488c597c
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

--
svn merge -r57958:57959 ^/branches/soc-2013-depsgraph_mt



git-svn-id: https://svn.blender.org/svnroot/bf-blender/trunk/blender@59266 954f8c5b-7b00-dc11-b283-0030488c597c
Made curves almost thread-safe

Now modifier stack wouldn't modify original curve's nurbs
and will operate on a copy of nurbs.

This makes it possible to process curve object update with
shared curve datablocks from multiple threads. There's no
big overhead for creating a copy of nurbs comparing to old
behavior which was allocating original vertex array and
apply coordinates on curve after all modifier are applied.

The only remained issue with curves is curve's bounding box
and texture space. It's not thread-safe, but it wouldn't
lead to crashes -- it just could lead to either memory
leak or wrong texture coordinates due to difference in
modifiers stacks of objects which shares the same curve.

--
svn merge -r57959:57961 ^/branches/soc-2013-depsgraph_mt



git-svn-id: https://svn.blender.org/svnroot/bf-blender/trunk/blender@59267 954f8c5b-7b00-dc11-b283-0030488c597c
Remove unused bounding box from MetaBall

--
svn merge -r58150:58151 ^/branches/soc-2013-depsgraph_mt



git-svn-id: https://svn.blender.org/svnroot/bf-blender/trunk/blender@59268 954f8c5b-7b00-dc11-b283-0030488c597c
Tag object-data level boundbox as invalid rather than freeing it

Object update used to free object-data level bounding box to trigger
it's re-calculation in the future. Such a freeing performed from
object update isn't thread-safe because mesh could be shared between
multiple objects.

Rather than freeing bounding box, tag it's as invalid, this is safe
from threading point of view and also prevents unnecessary memory
re-allocation.

Object-level bounding box is still reallocating, but think we could
change this easily in the future as well.

--
svn merge -r58154:58156 -r59258:59259 ^/branches/soc-2013-depsgraph_mt



git-svn-id: https://svn.blender.org/svnroot/bf-blender/trunk/blender@59269 954f8c5b-7b00-dc11-b283-0030488c597c
fix [#36481] When "Rip Edge" cannot be completed, Blender crashes weirdly


git-svn-id: https://svn.blender.org/svnroot/bf-blender/trunk/blender@59270 954f8c5b-7b00-dc11-b283-0030488c597c
Make fonts safe(r) for threading

Getting vfont data wasn't safe for threading, because it
was modifying font data which is in bmain and could be
shared by multiple objects.

For now made it so getting vfont uses critical section,
meaning vfont->data is initializing from inside a locked
mutex.

--
svn merge -r58168:58169 ^/branches/soc-2013-depsgraph_mt



git-svn-id: https://svn.blender.org/svnroot/bf-blender/trunk/blender@59271 954f8c5b-7b00-dc11-b283-0030488c597c
Make GPU buffers allocation/freeing safe for threading

Code in GPU_buffers_free was already trying to be safe
for threading, by skipping OGL calls there, but in fact
it was still buggy.

Namely, freeing was doing buffers shift in a cycle, and
if two threads will call this function shifting will go
crazy.

Now made it so GPU_buffers_alloc and GPU_buffers_free
are using mutex lock, so they're completely safe for
threading. Same goes to gpu_buffer_setup function.

It required minor functions reshuffle, so there're no
locks happening from locked thread, but it's all very
straightforward change

--
svn merge -r58276:58277 ^/branches/soc-2013-depsgraph_mt



git-svn-id: https://svn.blender.org/svnroot/bf-blender/trunk/blender@59272 954f8c5b-7b00-dc11-b283-0030488c597c
Make lattice deform safe for threading

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.

--
svn merge -r58277:58278 -r58795:58796 ^/branches/soc-2013-depsgraph_mt



git-svn-id: https://svn.blender.org/svnroot/bf-blender/trunk/blender@59273 954f8c5b-7b00-dc11-b283-0030488c597c