There's been a handful of reports where "obviously" not a UDIM filenames
were detected as such during image open.[1]
This change makes the detection less aggressive by enforcing that the
4-digit sequence be delineated on both sides by one of the following 3
characters ., -, _
This fixes the problem for such filenames as:
"screenshot-1080p.png", "Image-1920x1080.png", "(1999) Photo.png", and
"antiguaChestnut_X_1240Wx814H.png"
[1] T97366 T98918 T99154 T100035
Differential Revision: https://developer.blender.org/D15573
This is a port of sculpt-dev's `SculptVertRef` refactor
(note that `SculptVertRef was renamed to PBVHVertRef`)
to master. `PBVHVertRef` is a structure that abstracts
the concept of a vertex in the sculpt code; it's simply
an `intptr_t` wrapped in a struct.
For `PBVH_FACES` and `PBVH_GRIDS` this struct stores a
vertex index, but for `BMesh` it stores a direct pointer
to a BMVert. The intptr_t is wrapped in a struct to prevent
the accidental usage of it as an index.
There are many reasons to do this:
* Right now `BMesh` verts are not logical sculpt verts;
to use the sculpt API they must first be converted to indices.
This requires a lot of indirect lookups into tables, leading to performance
loss. It has also led to greater code complexity and duplication.
* Having an abstract vertex type makes it feasible to have one unified
temporary attribute API for all three PBVH modes, which in turn
made it rather trivial to port sculpt brushes to DynTopo in
sculpt-dev (e.g. the layer brush, draw sharp, the smooth brushes,
the paint brushes, etc). This attribute API will be in a future patch.
* We need to do this anyway for the eventual move to C++.
Differential Revision: https://developer.blender.org/D14272
Reviewed By: Brecht Van Lommel
Ref D14272
Instead of specifying which symbols to hide, we hide all and make a few
visible. Some users may be relying on calling internal Blender functions,
but Windows is already hiding all of them and this is just not supported.
Fixes T99900: crash with some third-party Python libraries since OneAPI
Ref T76442
Differential Revision: https://developer.blender.org/D14971
Adds `rna_path.cc` and `RNA_path.h`.
`rna_access.c` is a quite big file, which makes it rather hard and
inconvenient to navigate. RNA path functions form a nicely coherent unit
that can stand well on it's own, so it makes sense to split them off to
mitigate the problem. Moreover, I was looking into refactoring the quite
convoluted/overloaded `rna_path_parse()`, and found that some C++
features may help greatly with that. So having that code compile in C++
would be helpful to attempt that.
Differential Revision: https://developer.blender.org/D15540
Reviewed by: Brecht Van Lommel, Campbell Barton, Bastien Montagne
While this was not a critical issue (that lib pointer is only used for
some kind of sanity check that no linked data uses local ID pointers),
better to keep `IDP_BlendReadLib` in sync with all other lib-linking
code.
This patch implements the necessary changes to the GPU module that are
needed by the realtime compositor.
A new function GPU_material_from_callbacks was added to construct a GPU
material from a number of callbacks. A callback to construct the
material graph by adding and linking the necessary GPU material nodes.
And the existing code generator callback. This essentially allows the
construction of GPU materials independent of node trees and without the
need to do any node tree localization.
A new composite source output to the code generator was added. This
output contains the serialization of nodes that are tagged with
GPU_NODE_TAG_COMPOSITOR, which are the nodes linked to the newly added
composite output links.
Two new GPU uniform setters were added for int2 and matrix3 types.
Shader create info now supports generated compute sources.
Shaders starting with gpu_shader_compositor are now considered part of
the shader library.
Additionally, two fixes were implemented. First, GPU setter node
de-duplication now appropriately increments the reference count of the
references resources. Second, unlinked sockets now get their value from
their associated GPU node stack instead of the socket itself.
Differential Revision: https://developer.blender.org/D14690
Reviewed By: Clement
Currently, draw engines are not notified of view updates if a render
engine is active and was updated. It is unclear why this is the case
currently, but this behavior was part of the initial commit.
This patch propagates view updates regardless if the update was handled
by an active render engine. This is needed by the realtime compositor as
it implements logic for view updates, which currently does not execute
if Cycles is rendering for instance.
Differential Revision: https://developer.blender.org/D15207
Reviewed By: Brecht
Replace our existing two fonts with a stack of new fonts to increase
and improve language coverage and to add many new symbols and icons.
Covers glyphs of top 44 languages - 1.5 billion more potential users.
See D10887 for lots of details.
Differential Revision: https://developer.blender.org/D10887
Reviewed by Brecht Van Lommel
Allow FontBLFs to exist with NULL FT_Face, added only when actually
needed. Speeds up startup and unused fonts are not loaded.
See D15258 for more details.
Differential Revision: https://developer.blender.org/D15258
Reviewed by Brecht Van Lommel
Optimize font drawing by skipping empty strings.
See D15472 for more details.
Differential Revision: https://developer.blender.org/D15472
Reviewed by Campbell Barton
This is a quite interesting case, where two arguments to a function are
evaluated in different order on Apple Clang than on GCC and I guess
MSVC. Left a comment on that.
There was already a utility to retrieve the correct node group idname
from the context, `node_group_idname`, but often it's clearer to
use lower-level arguments, or the context isn't accessible.
Storing the group idname in the tree type makes it accessible
without rewriting it elsewhere.
This reverts commit e2c02655c78b2c669468ae568ddf4b17953cc98d. It was already
reverted in the 3.2 branch, as it caused more serious issues than it solved.
Fixes T99805, T99323, T99296.
The new implementation leverage compute shaders to reduce the
number of passes and complexity.
The max blur amount is now detected automatically, replacing the property
in the render panel by a simple checkbox.
The dilation algorithm has also been rewritten from scratch into a 1 pass
algorithm that does the dilation more efficiently and more precisely.
Some differences with the old implementation can be observed in areas with
complex motion.
This removes the quirk of having to call the sync function for each new
render loop.
# Conflicts:
# source/blender/draw/engines/eevee_next/eevee_view.cc
New `oldnewmap_lib_insert` does nothing special, it just wraps around existing
`oldnewmap_insert`, but it's the logical counter part of `oldnewmap_liblookup`.
It also helps tremendously when debuging complex ID pointers issues in
readfile.c code.
Crash would happen when a linked ID would become missing, that was
'pre-declared' and used only once as a 'weak link' in another library
stored before the one it came from.
In that case, the place-holder generated in read code would be freed in
`read_library_clear_weak_links`, when handling its 'owner' library, but
since all previous libraries in the list had already been 'lib_linked'
and their filedata (and related libmap) freed, the update of the libmaps
in `read_library_clear_weak_links` would not apply to data from those
previous libraries, leading to ID pointers there pointing to freed
memory.
This fix should also be backported to 2.93.
The Python based importer had a special case handling of "no faces in
the whole file at all", where it ended up treating the whole file
as essentially a point-cloud-like object (just loose vertices, no
faces or edges). The new importer code was missing this special case.
Fixes T100017. Added gtest coverage that was failing without the fix.
Only nodes supporting lazyness can mark inputs as unused. For other
nodes, this is done automatically of all outputs are unused.
Differential Revision: https://developer.blender.org/D15409
