The evaluated data must not copy the material if it's NULL.
Still the stroke exists in the file, so maybe need some thinking in how resolve this, but anyway this is a different topic not related to bug.
New brush option to calculate the distance to generate a new brush step using the cursor position over the mesh instead of the screen coordinates. This avoids artifacts when sculpting across curved surfaces.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D5432
Since OpenImageDenoise requires a CPU with SSE 4.1 or newer,
let the node act as passthrough on unsupported CPUs and display
a message in the node itself.
Running multiple instances of OIDN simultaneously can use dozens
of GBs of memory. Since OIDN is multithreaded internally, we can run
only one instance at a time and should not lose much performance.
Fixing T69006
With Blender 2.80 we introduced a more flexible matcap system. One
change we did was to multiply the matcap with the base color that was
shaded. As matcaps contains diffuse and specular lighting in a single
texture this lead to rendering artifacts. Artists were complaining that
everything looked to metalic.
We now support a separate `diffuse` and `specular` pass for matcaps.
`shaded_color = diffuse_light * base_color + specular_light`
For matcaps to support this feature they need to be multilayer openexr
files with 2 renderpasses (named `diffuse` and `specular`). In the future
we can change this to first pass/second pass in stead of this naming
convention.
Reviewed By: fclem, brecht
Differential Revision: https://developer.blender.org/D5335
Show Edges option in the UV editor does not do anything. Only RNA/DNA
code could be found, so it is save to be removed.
Differential Revision: https://developer.blender.org/D5446
Now all wire edges linked to the merged vertex are used for split faces.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D5603
Improved error handling of Join Area operator in cased it is passed cursor position that is not valid.
Differential Revision: https://developer.blender.org/D5598
Reviewed by Brecht Van Lommel
Compiling this big file for every Eevee material is bad for performance, and
now that we are adding more nodes it gets worse. This patch adds a simple
mechanism to split up that file, and use only the parts used by shader nodes.
When a function is used by GPU_link, we detect which GLSL file it came from
and use it in GLSL code generation automatically. Dependencies between GLSL
files are manually specified, and function names must be unique across all
GLSL files.
Most of the actual splitting up will be done in later commits.
Differential Revision: https://developer.blender.org/D5569
Issue was exposed by recent own rB03bf84db86b commit, but was actually
present in RNA API for PointCaches since (probably) ages: whole accessor
code here was assuming that owner ID was an Object, when it is actually
a scene for RigidBody simulations...
Had also to make `BKE_ptcache_id_find()` and friends a bit more
flexible, now they also accept a NULL object pointer parameter...
Before there were two options: Paste to original layer called "Paste" and Paste to active layer called "Paste & Merge"
Now, by default the paste is in active layer and the "Paste & Merge" has been renamed "Paste".
For old "Paste", now is called "Paste by Layer" and it's not the default value anymore.
Note: Minor edits to add icons not present in Differential revision.
Differential Revision: https://developer.blender.org/D5591
The correct fix would be to avoid all those hacks but this is needed if
we want to be able to parallelize object vbo extractions.
This is the fixed version of the hack. The issue was that the ibo ranges
were saved before the batch were reset and the IBO was discarded, leading
to a read after free error. All previous reported crash were tested and
are now not reproductible.
The specifc bug here came fro; some IDProperties ID pointer storing
references to workspaces.
But that was actually a main loophole in that 'unndoing data while
keeping same UI' process, as we never know who might store a pointer to
one of those datablocks that we want to keep the 'old' version off.
It might actually be ever more needed when we start undoing (changing)
only the IDs actually modified in an undo step...
Notes:
* While not ideal, I think we can afford an extra looping over the whole
Main DB here... Remapping process in itself is fairly cheap, thanks to
the hashes.
* This commit is considered rather risky (especially thanks to 'private'
IDs), think it should work fine for now, unless some IDPointers start
storing references to private IDs...
Once D5559 is in, we shall do another pass here, probably also forbids
assigning private IDs to IDProperties, etc.
