It gives some slight differences on the plane corners, but can't
really figure out source of the issue here yet.
It's still better than fully white texture for the previews anyway.
At this point we should perhaps ifdef chunks of the code in order
to have faster GLSL compilation and probably even faster compiled
code. Will look into this shortly.
In addition to the original bug report, I've gone through cleaning up a range of
related bugs which only became clear when hunting around the code...
* Custom Handle References weren't getting cleared when the bones they used got
deleted. But, neither was the custom bone shape location/transform reference.
* Various places where posebone settings are copied around were also missing code
to handle the new Bendy Bone properties.
(WHY DO WE HAVE SO MANY VARIATIONS OF COPYING POSE DATA!?!?)
* If duplicating a Bendy Bone with custom references, and the custom references
are also selected/duplicated, the new Bendy Bones will use the corresponding
duplicated bones
This commit adds Peak Memory to the stamp options, the value is the same one that is already shown in the image viewer.
Requested by @nutel.
Reviewers: campbellbarton
Subscribers: campbellbarton, nutel
Differential Revision: https://developer.blender.org/D1989
Was not so far, because this effect is not modifying its 'own' PaintPoint, which means
it's not threadsafe. Since a global lock (mutex or spinlock) would not be much efficient
(we need to lock a given point pretty much all the computaion cycle), and since locking
a same PaintPOint from different threads at the same time is *very* unlikely,
solution here is to use an 'array of locks', one for each PaintPoint (same thing as BLI_bitmap,
using atomic ops to set/clear bits).
Here in own test (complex dynapaint over a huge sphere combining all dynapaint types), it gives
20% speedup of the whole dynapaint simulation!
Note: maybe we'd want to move that kind of bitlock into BLI lib some day - not totally sure how,
so let's keep it local for now...
Vertex's normal is always normalized - and its conversion from short to float should not change that!
On the other hand, linear interpolation of three normals **does not give a normalized vector**
(unless all three inputs are exactly the same).
Also, minor optimization, avoid recomputing that interpolated normal twice for each PaintUVPoint.
It was totally useless to multiply diffuse color with the vertex color
when doing texture painting. It was masking actual texture and only was
forcing artists to create an empty vertex color layer to work this around.
The idea of pole merge is to fade interocular distance after a certain
altitude to zero when altitude goes closer to a pole. This should prevent
annoyances looking up in the sky or down to the bottom.
Works for both panorama and perspective cameras when Spherical Stereo
is enabled.
Reviewers: dfelinto, brecht
Reviewed By: brecht
Subscribers: sebastian_k
Differential Revision: https://developer.blender.org/D1998
When using Left Click select, it wasn't possible to sculpt using E+LMB.
I've changed the order of things in the keymap so that the select operator won't
end up catching and blocking all these events.
This commit/patch/branch brings a bunch of powerful new options for B-Bones and
for working with B-Bones, making it easier for animators to create their own
rigs, using fewer bones (which also means hopefully lighter + faster rigs ;)
This functionality was first demoed by Daniel at BConf15
Some highlights from this patch include:
* You can now directly control the shape of B-Bones using a series of properties
instead of being restricted to trying to indirectly control them through the
neighbouring bones. See the "Bendy Bones" panel...
* B-Bones can be shaped in EditMode to define a "curved rest pose" for the bone.
This is useful for things like eyebrows and mouths/eyelids
* You can now make B-Bones use custom bones as their reference bone handles,
instead of only using the parent/child bones. To do so, enable the
"Use Custom Reference Handles" toggle. If none are specified, then the BBone will
only use the Bendy Bone properties.
* Constraints Head/Tail option can now slide along the B-Bone shape, instead of
just linearly interpolating between the endpoints of the bone.
For more details, see:
* http://aligorith.blogspot.co.nz/2016/05/bendy-bones-dev-update.html
* http://aligorith.blogspot.co.nz/2016/05/an-in-depth-look-at-how-b-bones-work.html
-- Credits --
Original Idea: Daniel M Lara (pepeland)
Original Patch/Research: Jose Molina
Additional Development + Polish: Joshua Leung (aligorith)
Testing/Feedback: Daniel M Lara (pepeland), Juan Pablo Bouza (jpbouza)
Together with the extended loop callback and userdata_chunk, this allows to perform
cumulative tasks (like aggregation) in a lockfree way using local userdata_chunk to store temp data,
and once all workers have finished, to merge those userdata_chunks in the finalize callback
(from calling thread, so no need to lock here either).
Note that this changes how userdata_chunk is handled (now fully from 'main' thread,
which means a given worker thread will always get the same userdata_chunk, without
being re-initialized anymore to init value at start of each iter chunk).
New code is actually much, much better than first version, using 'fetch_and_add' atomic op
here allows us to get rid of the loop etc.
The broken CAS issue remains on windows, to be investigated...
Some variants of gcc compilation were reporting 'control reaching end of non-void function' error
in this switch/case maze. Either use break everywhere or not at all (which is simpler, since we
only always return anyway...).
There are some serious issues under windows, causing deadlocks somehow (not reproducible under linux so far).
Until further investigation over why this happens, better to revert to previous
spin-locked behavior.
This reverts commits a83bc4f59707ab and 98123ae9168.
Reading the shared state->iter value after storing it in the 'reference' var could in theory
lead to a race condition setting state->iter value above state->stop, which would be 'deadly'.
This **may** be the cause of T48422, though I was not able to reproduce that issue so far.
When writing temp blenbuffer file, libraries of linked datablocks where not tagged correctly, which
means they were not put in the temp Main used to write the buffer, resulting in implicit localization
of linked data.
Previous to 2.77, this used to be default behavior, was changed in rB591f4549c958b.
However, in most append cases, you do want a full localization of your data, so this new behavior
is kept by default, but there is now an option in append operator to only localize the 'first level'
of data (i.e. datablocks from linked library itself, and not those from other 'sub-libraries').
