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
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
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
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
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
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
This commit includes all the changes made for plane tracker
in tomato branch.
Movie clip editor changes:
- Artist might create a plane track out of multiple point
tracks which belongs to the same track (minimum amount of
point tracks is 4, maximum is not actually limited).
When new plane track is added, it's getting "tracked"
across all point tracks, which makes it stick to the same
plane point tracks belong to.
- After plane track was added, it need to be manually adjusted
in a way it covers feature one might to mask/replace.
General transform tools (G, R, S) or sliding corners with
a mouse could be sued for this. Plane corner which
corresponds to left bottom image corner has got X/Y axis
on it (red is for X axis, green for Y).
- Re-adjusting plane corners makes plane to be "re-tracked"
for the frames sequence between current frame and next
and previous keyframes.
- Kayframes might be removed from the plane, using Shit-X
(Marker Delete) operator. However, currently manual
re-adjustment or "re-track" trigger is needed.
Compositor changes:
- Added new node called Plane Track Deform.
- User selects which plane track to use (for this he need
to select movie clip datablock, object and track names).
- Node gets an image input, which need to be warped into
the plane.
- Node outputs:
* Input image warped into the plane.
* Plane, rasterized to a mask.
Masking changes:
- Mask points might be parented to a plane track, which
makes this point deforming in a way as if it belongs
to the tracked plane.
Some video tutorials are available:
- Coder video: http://www.youtube.com/watch?v=vISEwqNHqe4
- Artist video: https://vimeo.com/71727578
This is mine and Keir's holiday code project :)
This is getting confused, why bevel is handled different
for 2D and 3D curves?
Anyway, made bevel work for 2D case nice again, but it's
probably nice to unify 2D and 3D cases.
- allow negative index values.
- error when invalid index value are passed in.
- remove last item if no index argument is given.
also change behavior to remove the material slot, it was only clearning by default but the list length remained the same.
Some places like proxy rebuild didn't increent
custom shape user counter which lead to user
decrement errors later when freeing pose channels.
Try to keep custom object counter relevent, but
some corner cases might still be missing.
Issue was caused by reload caused by input colorspace change.
For generated images generated alpha flags weren't saved to
DNA, which lead to fallback from 32 bit depth to 24 when
doing any kind reload of generated image.
The same alpha loss happens when you save .blend file with
generated images.
Now added generated depth to DNA, so reload image and .blend
file wouldn't loss alpha.
They were caused by not having a free_windowmanager_cb set and by not having registered SpaceTypes, which meant data allocated for thosse SpaceTypes could not be freed. These were solved by defining a free_windowmanager_cb for the player that just frees wmWindows, and by making sure we only allocate memory for registered SpaceTypes.
Made first/last tessellated curve have proper
direction and tilt. Before direction/tilt
from second/previous to last tessellated curve
segments.
Thanks Brecht for review and tests!
decrement the object user count when removing the armature. This could cause
the object to stick when it shouldn't, in particular when that object is part
of a group.
* Render Passes are now available for Subsurface Scattering (Direct, Indirect and Color pass).
This is part of my GSoC project, SVN merge of r58587, r58828 and r58835.
- performance of outliner was low because of unoptimal data structures.
- now it uses BLI_mempool instead of custom mempool and GHash to make searches for duplicates faster.
- also fix undesired behaviour of BLI_mempool_as_arrayN
thanks to Campbell Barton and Lukas Tönne for helping me get a better fix put together.
It greatly helps getting rid of that "noise" that occurs if you use really steep objects (like cubes) as a brush. New default value is 1.0 which is just high enough to only get rid of the sharpest spikes, so if you want really smooth waves it's better use higher values.
This also seems to "fix" bug [#35413].
* Change overlay alphas to 33 if not initialized. This should have been
done for 2.67 but better do it now to avoid frustration with overly
transparent overlays. For users that have set this low manually this
will reset the setting to 33 but I think it's less irritating than users
who unwillingly had the setting to 1 and saw nothing when activating the
overlay.
* Allow overlay alpha to be zero as well
* Reset old, now obsolete BRUSH_FIXED flag for brushes that still use
this. I am doing this here to avoid patching hell when the paint brush
is merged, since it's not possible to know the merged version
beforehand, and this flag will be used.
