Summary:
Crash was happening because of fcurve modifier stack
used modifier's DNA to store temporary data.
Now made it so storage for such a thing is being
allocated locally per object update so multiple objects
which shares the same animation wouldn't run into
threading conflict anymore.
This storage might be a part of EvaluationContext,
but that'd mean passing this context all over in
object_where_is which will clutter API for now without
actual benefit for this.
Optimization notes: storage is only being allocated
if there're Cycles modifier in the stack, so there're
no extra allocations happening in all other cases.
To make code a bit less cluttered with this storage
passing all over the place added extra callbacks to
the FModifier storage which runs evaluation with the
given storage.
Reviewers: brecht, campbellbarton, aligorith
CC: plasmasolutions
Differential Revision: https://developer.blender.org/D147
File tracking.c became rather huge and annoying to
maintain and it really contains several independent
areas of motrack pipeline.
Now we've got:
* tracking.c: general-purpose functions which are used
by blender, clip editor, RNA and so.
* tracking_detect.c: feature detection functions
(blender-side, logic is still in libmv).
* tracking_plane_tracker.c: blender-side 2D tracking logic.
* tracking_plane_tracker.c: plane track tracker.
* tracking_solver.c: functions for camera solving.
* tracking_stabilize.c: 2D stabilization functions.
* tracking_util.c: utility functions for all those files
and which shouldn't be public.
Summary:
Issue was caused by the same tile being written twice to
the EXR file. This was happening because of partial update
of work-in-progress tiles was merging result to the final
render result in order to make color management pipeline
happy.
We need to avoid such a merges and keep memory usage as
low as possible when Save Buffers is enabled.
Now render pipeline will allocate special display buffer
in render layer which will contain combined pass in the
display space. This keeps memory usage as low as we can
do at this moment.
There's one weak thing which is changing color management
settings during rendering would lead to lossy conversion.
This is because render result's display buffer uses color
space from the time when rendering was invoked.
This is actually what was happening in previous release
already actually so not a big issue.
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D162
key->elemsize is set to 16 for ID_CU (i.e. Curves and NURBS surfaces). However,
this value is only correct for NURBS (which use BPoints). When trying to keyframe
the nth vertex of a particular shape key's data (where the shape keys are being
used on Bezier curves), the RNA Paths for that are generated with the wrong
data index. From empirical testing, it appears that this should be 12 instead.
of the drawstr and replaces the middle by '...'
Rationnal:
It's usually easier to figure out what a troncated string means if you have both its start and end parts.
Details:
It currently affects all UI items (text fields, buttons, labels...).
Only exceptions are buttons inside menus, text fields & co being edited, and numbuttons/sliders.
Note that some static texts (like panels' titles or items in outliner) do not use usual UI items,
and just draw the whole text, using OpenGL to clip it. Will make another patch to fix this.
Reviewers: campbellbarton, brecht, carter2422, #user_interface
Reviewed by: brecht, carter2422
CC: billrey
Differential Revision: https://developer.blender.org/D114
is used. When numerical input was active confirmation events were not
getting handled.
Code here seems a bit duplicated, it may be possible to simplify it, but
leaving it slightly bloated for now.
Solved by adding RW lock to BKE_vfont_to_curve.
So now all the threads are allowed to read chars from ghash,
but they'll be locked as soon as one thread would need to load
more chars from font to the ghash.
This is the simplest possible volume rendering case, constant density inside
the volume and no scattering or emission. My plan is to tweak, verify and commit
more volume rendering effects one by one, doing it all at once makes it
difficult to verify correctness and track down bugs.
Documentation is here:
http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Materials/Volume
Currently this hooks into path tracing in 3 ways, which should get us pretty
far until we add more advanced light sampling. These 3 hooks are repeated in
the path tracing, branched path tracing and transparent shadow code:
* Determine active volume shader at start of the path
* Change active volume shader on transmission through a surface
* Light attenuation over line segments between camera, surfaces and background
This is work by "storm", Stuart Broadfoot, Thomas Dinges and myself.
* Henyey-Greenstein scattering closure implementation.
* Rename transparent to absorption node and isotropic to scatter node.
* Volume density is folded into the closure weights.
* OSL support for volume closures and nodes.
* This commit has no user visible changes, there is no volume render code yet.
This is work by "storm", Stuart Broadfoot, Thomas Dinges and myself.
Summary:
Original issue was caused by wring detection of whether
SS modifier is being applied for render/viewport. After
recent dependency graph commit this was no longer an
issue.
But it still might have happen conflict between viewport
draw and scene_update_for_newframe() invoked from render
thread when using external engines like Cycles.
Solved by adding viewport lock while scene is being
updated and objects being exported to the render engine.
Same lock was already used for Blender Internal.
Reviewers: brecht
Reviewed By: brecht
Maniphest Tasks: T36474
Differential Revision: https://developer.blender.org/D138
Issue was caused by missing objects update for temporary
freestyle objects. This happened because of the fact that
such objects doesn't have any relations, as in they're
corresponding to root nodes in the DAG.
This situation wasn't handled by DAG_threaded_update_begin()
which considered there's only one root node in the DAG.
