The OpenVDB update added a load() function. This function clashes with a helper IO function (only used when exporting and running the simulation externally) that was also named load().
Removed invel MAC grid since it is sufficient to use the cell centered vec3 representation. When setting initial velocities these will be interpolated by the setter functions.
With the new image editor drawing there were was some mutual exclusive
functionality. When rendering the alpha was shown correctly or the pure
emissive colors were shown correctly, but never both. The cause of this
is that the image_gpu did not used the correct alpha mode when generating
gpu textures for non-images (render results, compositors viewer)
The implementation always checked the alpha_mode. Alpha mode is an
attribute for images, but aren't set for non images. This patch adds
a more detailed check to ensure that the gpu texture is premultiplied.
The issue has been tested using several bug report files and production
files.
Reviewed By: Brecht van Lommel
Differential Revision: https://developer.blender.org/D8978
Since {D8234} the image editor is drawn using a depth buffer.
When using `draw_texture_2d` the image is drawn using the 2D_IMAGE
shader. inside the vertex buffer the image was pushed to the background.
This was introduced by {648924333234} what seems to be out dated as we
have done several overhauls in this area. (workbench refactor, overlay
engine refactor, color management pipeline).
This patch removes the pushing of the image to the background.
During viewport render animation the gpu textures weren't tagged as
invalid. As the image uv editor now draws the gpu texture only the first
was shown as it wasn't refreshed with the actual image data.
I created a bugreport T80859 earlier.
The problem is in the file source/blender/editors/sculpt_paint/paint_image_proj.c (line numbers against commit d376aea61)
at the lines 5309 and 5320 the functions `IMB_rect_from_float(...)` and `IMB_float_from_rect(...)` are called from threaded code on a shared ibuf.
However, ps->reproject_ibuf is shared between threads, so this is not thread-safe.
This is a race condition and leads to wrong output when projecting float data onto a uchar texture or vice versa on a multithreaded system.
The checks on line 5308 and 5319 are already a race condition.
I created this patch which fixes the problem , but I'm not sure if I'm overlooking something.
This makes sure reproject_ibuf contains the correct formats *before* the threadpool is started.
I replaced the original location of the conversions with BLI_asserts(). That may be overkill?
Reviewed By: #sculpt_paint_texture, mont29
Maniphest Tasks: T80859
Differential Revision: https://developer.blender.org/D8936
When introduced in rB1ca1744c29e2, the Weight Paint Overlay XRay's
corresponding depth pass was not considering clipping planes.
Maniphest Tasks: T81013
Differential Revision: https://developer.blender.org/D8970
target in certain situations
Regression from rBdeaff945d0b96.
mesh_ensure_looptri_data would overflow.
Crash would only happen if a Data Transfer modifier (transferring
UVs) follows, so exact reason for this is not yet entirely clear. Also
there are edit-mode versions of the following BVH lookup functions so it
could be avoided (since this is a expensive operation), marking as TODO.
Similar fix as
- rB0945a79ed1eafae444d3021a5912cb39801a7209
- rB56d7e39b92997768b3db8ce2dbc262f869994145
Reviewers: mont29, campbellbarton
Maniphest Tasks: T80996
Differential Revision: https://developer.blender.org/D8973
The placement of the start and end factor and mapping settings for
curves has been quite misleading for a long time. They were in the
"Bevel" subpanel, but they aren't related to bevel because they affect
curves with only extrusion and no bevel.
This commit moves these properties to their own subpanel, labeled
"Start & End Mapping".
Differential Revision: https://developer.blender.org/D8910
This commit contains the Performance improvement, that was originally
proposed in D8966.
It improves the performance of the Weld Modifier by a lot.
It had a loop with execution time O(N^2) which is now O(N*log(N)) at a
bare maximum.
This patch adds a new operator to convert a black and white image into
grease pencil strokes.
If the image is not B/W, an internal conversion is done.
This is the first operator using Potrace, but we expect to add more features in next Blender versions.
Reviewed By: HooglyBoogly
Maniphest Tasks: T79877
Differential Revision: https://developer.blender.org/D8951
The issue was two fold.
First something sets the loop element tag and doesn't clear it before
the UV code in question tries to use the tags. Added a sanity clear to
make sure that it operates on a clean tag state.
The next one was that the UV maps in question had quite a few points
that had zero length UV loop edges. This would lead to division by
zero.
Reviewed By: Jeroen Bakker, Brecht
Differential Revision: http://developer.blender.org/D8967
It's generally considered a better codestyle to check conditions early
and exit early when they are not met, over having most logic of a
function within a big `if`-block. Otherwise people have to go over the
entire block to see if there's possibly an `else` somewhere, or any
followup logic.
There's the old and ugly hack where the `uiBut.poin` points to the
button itself. When reallocating the button we have to update that
pointer of course.
Those two functions had `BKE_` prefix, were defined in BKE headers, but
implemented in ED code, yuck.
Moved everything to ED area for now, since those do not look fondamental
enough to belong to BKE, and none of their usages requires it currently.
As noted by @lichtwerk (thanks), one can have a local object and/or
material using a linked image data-block, this case needs some different
handling to prevent painting on such linked image.
For now, tweak `BKE_paint_proj_mesh_data_check` (eeeek, that name
prefix!) to consider paintslots with linked image as 'non-existing'.
The function this was in already checks the conditions under which it
can operate (as it should). No need to force the caller to do these
(quite specific) checks, the function can just do nothing if the button
doesn't need these operations.
Otherwise we'd have to always execute these checks before calling, which
makes calling it a hassle, makes the code harder to follow and generally
harder to maintain (what if the conditions change?).
Allows scripters to store additional information in the marker itself instead
of using work-around approach based on marker names and such.
Differential Revision: https://developer.blender.org/D8944
Originally was noticed when transforming mesh created by
object.to_mesh() from an object without modifier, in which case the
result references CustomData layers used by the object itself.
The issue goes a bit deeper: mesh.transform() should never modify
referenced layers, hence it should duplicate referenced layers.
This fix changes one specific aspect of the reported behavior. The
case where vertices coordinates are modified manually will still have
affect on the source mesh (as no referenced CustomData layers are being
duplicated). Proper fix for this case is not yet clear to me.
Differential Revision: https://developer.blender.org/D8939
The issue was that the pointcache was not storing dead particles,
even though they are displayed. This lead to the rendering issue,
because only alive particles can be read from the point cache in
the frame that is rendered.
This also fixes an issue unrelated to rendering: when dead particles
are displayed, their position is incorrect when some frames are
skipped during playback.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D8907
Keep braces balanced where possible, even with ifdef's as it avoids
confusions with editors calculating correct indentation level &
finding matching brackets.
This patch tries to sanitize the types of our size parameters across our read
and write code, which is currently fairly inconsistent (using `int`, `uint`,
`size_t`...), by using `size_t` everywhere. Since in Blender file themselves
we can only store chunk of size `MAX_INT`, added some asserts to ensure that
as well.
See {T79561} for details.
Differential Revision: https://developer.blender.org/D8672
Collections of liboverride data only support insertion of new items (and
deleting or moving those around). No operation on existing items from linked
data is allowed.
Reflect that in RNA functions used to edit py-defined RNA collections.
Note that this is not ideal currently, it does the job but feedback to
user is rather poor. Ideally add-ons should implement higher-level
checks for override cases in their operators.
Supporting IDProperty-based data storage here in a generic way is fairly
simple, unlike actual RNA data (DNA-based), for which getting a proper
generic way to duplicate them from within RNA is currently not really
possible.
Part of T79562.
