| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Material linking might and does change the way how drawObject is calculated
but does not tag drawObject for recalculation in any way.
Now use dependency graph to tag draw object for reclaculation. Currently do
this using OB_RECALC_DATA taq since tagging is not very granular yet. In the
future we can introduce ore granular tagging in the new dependency graph
easily.
Simple and safe for 2.78a.
|
|
Typo, spoted by Coverity scan.
To be backported to 2.78a.
|
|
When ED_screen_animation_play is called from wm_event_do_handlers,ScrArea *sa = CTX_wm_area(C); is NULL in ED_screen_animation_timer.
Informing the audio system in CTX_data_main_set, that a new Main has been set.
|
|
|
|
descriptors
This was causing memory leaks in Cycles.
Some more detailed information in the comment in the code.
Seems to be safe and nice enough for 2.78a.
|
|
|
|
clearing of linked data-blocks.
This is not a simple fix, but imho still needs to be backported to 2.78a...
|
|
One day we'll have to reconsider why some many 'real' ID usages are not
refcounting... :(
To be backported to 2.78a.
|
|
the issue was caused by wrong default value for brush particle count
which was clamped on display from 0 to 1. This is technically a regression
but how to port this to 2.78a?
|
|
|
|
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D2304
|
|
Needed for outliner "Sequence" display mode.
|
|
|
|
Regression from rB69b66d549bcc8, was supposed to be non-functionnal
change, so not sure why search menu was reduced here? For now, restore
to 2.77 width.
|
|
zoom distance.
Allow for zooming in at max zoom distance.
Reviewed By: Severin
Differential Revision: https://developer.blender.org/D2291
|
|
Seems to be a bug in original implementation of a830280: code was always
using tangent space instead of UV map because it had the same name. Now
prefer UVMap over tangent because this is how Cycles works. At least it's
closer to.
Not sure it the save+reload issue is still relevant after this fix, that
needs to be double-checked.
Thanks @dfelinto for looking into the report and simplifying the case.
Should be included into 2.78a.
|
|
Column flow layout was abuse ui_item_fit in a weird way, which was
broken for last column items.
Now rather use own code, which basically spread available width as
equally as possible between all columns.
|
|
Things are complicated enough like that, no need to add useless noise on
top of it!
|
|
|
|
This code is confusing, such dirty details should not sneak out of
particles' own private code. :(
|
|
|
|
input node.
|
|
|
|
|
|
constant key value
Technically it is a regression in behavior and should be 2.78a.
|
|
|
|
Original fix in this area was not really complete (but was the safest at
the release time). Now all the crazy configurations of slots going out
of sync should be handled here.
|
|
It was possible to have two viewports opened and start using Ctrl-0
to make different objects an active camera for the viewport. This
worked fine for viewports which had decoupled camera from the scene,
but if viewport was locked to scene camera it was possible to run into
situation when two different viewports are locked to scene camera but
had different v3d->camera pointers.
|
|
in BI
Nice to have in 2.78a, though not a regression.
|
|
dangling to invalid value in read code...
|
|
|
|
We were checking for number of tasks from given pool already active, and
then atomically increasing it if allowed - this is not correct, number
could be increased by another thread between check and atomic op!
Atomic primitives are nice, but you must be very careful with *how* you
use them... Now we atomically increase counter, check result, and if we
end up over max value, abort and decrease counter again.
Spotted by Sergey, thanks!
|
|
Pretty much same reason as for the 'from' pointer of shapekeys - runtime
data creating loops and 'ghost' dependencies between datablocks.
We need to handle them in cases like remapping, but whall not take them
into account to check dependencies between datablocks... :/
|
|
This is unsigned value (negative radius does not have much sense anyway!).
|
|
Was visible in Dynamic Context Menu add-on.
|
|
|
|
Datablock Previews
New recursive iteration over IDs in BKE_library_foreach_ID_link() was
broken by the infamous nodetree case. We cannot really recusively call
this function in that case, so better to deffer handling of
non-datablock NodeTrees as if real IDs here.
Also fixed initial ID not being stored as handled, in rare cases this
could also lead to infinite looping.
To be backported to 2.78a.
|
|
|
|
We *always* want to increase mat user count when from Object (and not
Data), because in that case we are moving mat from object to temp
generated mesh, material can never be 'borrowed' in that case.
To be backported to 2.78a
|
|
Removed in a7dbc0704f217a, but only should've removed default keymap entry.
|
|
If I didn't miss anything these are indeed not used. Old themes should still work (will only print info on redundant theme defines into console), but updated non-contrib themes already.
|
|
|
|
The `use_snapp_align_rotation` option was using only the first vertex
|
|
|
|
|
|
'camera' Object pointer of TimeMarkers is a 'temp' hack since Durian project...
Would need to be either made definitive now, or removed/reworked/whatever.
But since we intend to use that object pointer for other needs, and current code
could lead to crashing .blend files, for now let's fix that mess (was missing
some bits in read code, and also totally ignored in libquery code).
Should be safe for 2.78a.
|
|
|
|
Scene Strip
This change makes it so that when the sequences within a Scene strip are
evaluated, they use the Scene that they come from as the context as opposed
the Scene that the Scene strip is in. This is necessary, for example, in the
case of the MulticamSelector where it needs to reference strips in the original
Scene as opposed to the Scene where the Scene strip is located.
Patch by @Matt (HyperSphere), thanks!
|
|
Another case of float imprecision leading to endless loop. INcreasing a bit 'noise threashold' seems to work OK.
Not a regression, but might be nice to have in 2.78a.
|
