Instead of 95, we can use 145 images now. This only affects Kepler and above (sm30, sm_35 and sm_50).
This can be increased further if needed, but let's first test if this does not come with a performance impact.
Originally developed during my GSoC 2013.
The issue was that we can't assume we support the colorspace from the file. The reported file had an invalid colorspace in fact, which was leading to the segfault in Blender.
Thanks for Sergey Sharybin for the help here.
airbrush + small brush size.
Fast textured strokes meant that sometimes the update width (calculated
from stroke distance) would be greater than the new ibuf width. This
meant out of bounds access for the new ibuf.
It's totally strange that I couldn't reproduce this issue on older
versions since the logic here has not really changed much between
versions.
This reverts commit 97823f6047.
I was to push a fix based on Brecht's solution (this commit) when he did
the same.
This fix is correct, but it misses replacing WM_JOB_TYPE_OBJECT_BAKE
with WM_JOB_OBJECT_BAKE_TEXTURE in the rest of the file, which may lead
to problems when calling the operator in a quickly sucession -
WM_jobs_test also tests for the same type of JOB.
I created WM_JOB_TYPE_OBJECT_BAKE elsewhere, may as well use it. Unless we revert 20c90ea and f194da3.
I'm fine with either way, just trying to get master to work again ;)
bNodeTree blocks.
This was broken by rB6e99fb0 (own commit). I expected the `do_action`
argument to be of no importance in this case due to node trees using
material animation, but this is not the case.
Anyway, this patch adds back a do_action to the BKE_libblock_copy_nolib
function as well to restore the previous behavior.
Although these crashes were quite sporadic, they seemed to happen most when
rmb-dragging strips randomly in quick succession. The most likely cause seems
to be a null check I accidentally took out during one of my commits yesterday.
Dashed lines were resetting stroke segment visibility by mistake (making invisible segments
visible, for example when applied to the results of square blueprint geometry modifier).
Frame nodes still have the "hidden" flag like all other nodes, but this
has to be ignored during resizing. width/height range for the frame
nodes must be unlimited for this to work correctly.
This makes it easier for finding the active or first selected channel
(where actual data channels need to be favoured over expanders - which come
first), as previously, long switch statements were needed everytime.
Previously mesh objects were created for individual visible stroke segments (recalling that
a stroke may consist of alternate visible and invisible segments). This could result in an
excessive memory consumption in stroke rendering when strokes are composed of many
short visible segments (for instance by means of dashed lines and/or blueprint geometry
modifiers).
Now mesh objects represent individual strokes instead of stroke segments, which tends to
reduce the number of generated mesh objects by an order of magnitude.
Code with contribution from Brecht Van Lommel (he wrote the
bake_differentials actually ;)
Reviewers: brecht
Differential Revision: https://developer.blender.org/D510
Show that modifier may not be supported in dyntopo rather than sculpt
mode in general. This is useful information since users may confuse the
two. Multires for instance is surely supported in sculpt mode, but not
in dyntopo.
Warn when a modifier does not support optimal drawing and mask/hidden
parts display.
User report was that hidden parts became visible after adding a new
modifier subdivision. Subdivision was added with the Ctrl+number keys.
First part of the fix was to make sure we add a multires instead of the
subsurf modifier in sculpt mode with the PageUp/Down Ctrl+number keys.
We can't really stop users from having added a subsurf modifier already.
We could be "smart" and convert subsurf to mulrires upon entering sculpt
mode maybe but that can easily backfire - or users may actually want
that. For now, just warn that the modifier won't support Hiding/Masking
and optimal drawing.
Multires did not support hiding in zero level. It's a case of PBVH not
being used in drawing due to code reporting active modifiers being used.
However multires level zero can be treated as effectively no modifier
and we can use mesh PBVH.
