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.
This was in fact really nasty bug, caused by multitex_nodes
function using global variable R (which is a copy of current
renderer). this variable is not initialized to anything
meaningful for until first rendering (preview or final)
happened.
Since multitex_nodes might be used outside of render pipeline,
made it so whether CM is on or off as an argument to functions
multitex_ext_safe and multitex_ext. Now multitex_nodes() is
only shall be used for stuff happening from render pipeline!
Also needed to make some changes to other places, so all the
usages of texture sampling knows for the fact whether CM is
on or off.
And one more change is related on behavior of dispalcement,
wave, warp, weightvg modifiers and smoke. They'll be always
using CM off since texture is used for influence, not for
color.
It's rather bigger patch, but it's mostly straightforward
changes, which we really need to be done.
Reviewed by Brecht, thanks!
the UI on OS X.
The problem is due to a large variable on the stack, and pthreads have a smaller
stack size than the main thread by default. On Linux the pthread stack size seems
to be 2MB, OS X 512KB and Windows 256KB - 512KB.
Issue was caused by operator redo saving values for previous
inverted channels, meaning the same channels will be inverted
next time operator runs.
Don't think it's useful to save operator values here, since
you don;t have visual feedback about which channels were
inverted. So marked all this properties as SKIP_SAVE. Gives
much more predictable results.
- BLI_strncpy_wchar_from_utf8 wasn't NULL terminating the destination string, caused uninitialized memory use in BPY_python_start().
- BLI_strncpy_wchar_as_utf8 could write one byte past the buffer bounds.
* Fix the weird results with 800-804.3 Kelvin in SVM. This was an offset issue with the lookup table, made the table slightly larger now (from 954 to 956) which gives a small gap between the R/G/B components.
* Use Luminance also for values below 800 Kelvin, for consistency.
in fact the problem was caused by own previous fix/improvement for a different case, now this works as follows...
- render uses last-saved name, falls back to 'untitled' in blend file path.
- non render uses id-name always, saves into dir of last-saved image, fall back to blend file path.
With deformations and on a simple cube you could get axis flipping with normal-particle alignment.
now use the normal & tangent to create the orientation to give a stable matrix that wont flip.
The reported line visibility issue was caused by a wrong calculation of a 2D
bounding box (so-called "proscenium face" in Freestyle) in the case of a
spherical grid data structure used for a perspective camera. The problem was
resulting from the proscenium computation based on two corners (min and max)
of the 3D bounding box of imported mesh data. Aware of the spherical coordinate
transformation involving non-linear (arctangent) functions, now the proscenium
is computed by taking in account all the eight corners of the 3D bounding box.
Also added minor code changes to facilitate future debugging.
- reading bmp images was failing (needed to increase the size of the header to 64 bytes)
- the dnd image was being incorrectly checked (was always returning true even when none was used).
