Note that lib_override functions have kept the unused argument,
but this may be removed too. It impacts many lib_override functions
so this can be handled separately.
This commit is a big overhaul to the Mikktspace module, which is used
to compute tangents. I'm not calling it a rewrite since it's the
result of a lot of iterations on the original code, but pretty much
everything is reworked somehow.
Overall goal was to a) make it faster and b) make it maintainable.
Notable changes:
- Since the callbacks for requesting geometry data were a big
bottleneck before, I've ported it to C++ and made it header-only,
templating on the data source. That way, the compiler generates code
specific to the caller, which allows it to inline the data source and
specialize for some cases (e.g. subd vs. non-subd in Cycles).
- The one input parameter, an optional angle threshold, was not used
anywhere. Turns out that removing it allows for considerable
algorithmic simplification, removing a lot of the complexity in the
later stages. Therefore, I've just removed the option in the new code.
- The code computes several outputs, but only one (the tangent itself)
is ever used in Blender. Therefore, I've removed the others to
simplify the code. They could easily be brought back if needed, none
of the algorithmic simplifications are conflicting with them.
- The original code had fallback paths for many steps in case temporary
memory allocation fails, but that never actually gets used anyways
since malloc() doesn't really ever return NULL in practise, so I
removed them.
- In general, I've restructured A LOT of the code to make the
algorithms clearer and make use of some C++ features (vectors,
std::array, booleans, classes), though there's still some of cleanup
that could be done.
- Parallelized duplicate detection, neighbor detection, triangle
tangent computation, degenerate triangle handling and tangent space
accumulation.
- Replaced several algorithms with faster equivalents: Duplicate
detection uses a (concurrent) hash set now, neighbor detection uses
Radixsort and splits vertices by index pairs etc.
As for results, the exact speedup depends on the scene of course, but
let's consider the file from T97378:
- Blender 3.1 (before D14675): 6.07sec
- Blender 3.2 (with D14675): 4.62sec
- rBf0a36599007d (last nightly build): 4.42sec
- With this commit: 0.90sec
This speedup will mostly be noticed at the start of Cycles renders and,
even more importantly, in Eevee when doing something that changes the
geometry (e.g. animating) on a model using normal maps.
Differential Revision: https://developer.blender.org/D15589
This changes the two tangent-related files in BKE to C++ in preparation for the C++ Mikktspace port in D15589.
For now, they still use the original Mikktspace.
Differential Revision: https://developer.blender.org/D15636
The `mvert` pointer was passed to `bm_to_mesh_shape` and was never
reset to the beginning of the vertex array. Use spans instead to
eliminate this error completely. This also has the benefit of letting
the CustomData system handle allocation of mesh layers.
3484c6d4f1 removed parts of 6e5eb46d73 by mistake,
returning no attribute when attribute data wasn't found. However, we
want that attributes can exist even on empty geometry. This commit
restores the fix and tries to make it more explicit to avoid the same
mistake again.
Differential Revision: https://developer.blender.org/D15899
The constraint attempted to access mesh normals on a mesh with
wrapper type ME_WRAPPER_TYPE_BMESH. This commit reverses the if
statements so that If there is an editmesh then we use that as the
source of truth - otherwise use the evaluated mesh.
Differential Revision: https://developer.blender.org/D15809
It's easier to keep track of state in these algorithms if it's stored in
a central place like a set. Plus, using flags requires clearing them
beforehand. For the selected linked operators, using the topology
cache means we don't have to iterate over all links.
Before 58c650a44c, the nodes span was rebuilt on every redraw. Now
that it's only rebuilt as necessary, we need to tag it dirty when nodes
are reordered. Relying on the order of the nodes at all isn't ideal, but
it's fairly fundamental in many areas at the moment.
Do not allow the loading of old-style non-scalable fonts.
See D15884 for more details.
Differential Revision: https://developer.blender.org/D15884
Reviewed by Brecht Van Lommel
Many existing .blend files (including startup ones) seem to have invalid
embedded IDs (they are not properly tagged with `LIB_EMBEDDED_DATA`).
We cannot `do_version` this so just fix it on the fly when detecting the
issue. User then need to re-save these files.
We also need to update some release files (default factory startup is
OK, but e.g. the VSE template one is not).
Keeping the assert is important here, as such missing flag is a critical
data corruption that can potentially have many serious consequences
throughout the ID management code.
A `blender::Pool` can construct and destruct elements without reordering. Freed items memory
will be reused by next allocations.
Elements are allocated in chunks to reduce memory fragmentation and avoid reallocation.
Reviewed By: JacquesLucke
Differential Revision: https://developer.blender.org/D15894
Completely forgot in rBcd49fee74114 to handle the owner ID copying case
(this code now also needs to re-assign to `owner_id` pointer of the
newly copied embedded IDs to their rightful owner).
In 8cf52e8226 we assumed that the UV IBO's are only needed in edit mode,
however the UV lines also need to work in texture paint mode. So prefer to
use bmesh when available to fix the original bug, but don't assume the face
is hidden when there is no bmesh.
Differential Revision: https://developer.blender.org/D15895
Caused by {rB31365c6b9e4c}.
The new API `CustomDataAttributeProvider` just did not support
`CD_MASK_PROP_STRING`.
While strings dont perform nicely in their current form, still add
support back for the API.
Adding Strings to the supported types seems to survive just
fine, see attached example file.
Maniphest Tasks: T100747
Differential Revision: https://developer.blender.org/D15851
Otherwise we disable this feature. This is because some driver
does not support any vertex storage buffers but still support
8 ssbo in fragment shader.
The only difference between `GPU_SHADER_2D_LINE_DASHED_UNIFORM_COLOR`
and `GPU_SHADER_3D_LINE_DASHED_UNIFORM_COLOR` is that in the vertex
shader the 2D version uses `vec4(pos, 0.0, 1.0)` and the 3D version
uses `vec4(pos, 1.0)`.
But VBOs with 2D attributes work perfectly in shaders that use 3D
attributes. Components not specified are filled with components from
`vec4(0.0, 0.0, 0.0, 1.0)`.
So there is no real benefit to having two different shader versions.
The only real difference between `GPU_SHADER_2D_SMOOTH_COLOR` and
`GPU_SHADER_3D_SMOOTH_COLOR` is that in the vertex shader the 2D
version uses `vec4(pos, 0.0, 1.0)` and the 3D version uses
`vec4(pos, 1.0)`.
But VBOs with 2D attributes work perfectly in shaders that use 3D
attributes. Components not specified are filled with components from
`vec4(0.0, 0.0, 0.0, 1.0)`.
So there is no real benefit to having two different shader versions.
This will simplify porting shaders to python as it will not be
necessary to use a 3D and a 2D version of the shaders.
In python the new name for '2D_SMOOTH_COLOR' and '3D_SMOOTH_COLOR'
is 'SMOOTH_COLOR', but the old names still work for backward
compatibility.
The only real difference between `GPU_SHADER_2D_IMAGE` and
`GPU_SHADER_3D_IMAGE` is that in the vertex shader the 2D
version uses `vec4(pos, 0.0, 1.0)` and the 3D version uses
`vec4(pos, 1.0)`.
But VBOs with 2D attributes work perfectly in shaders that use 3D
attributes. Components not specified are filled with components from
`vec4(0.0, 0.0, 0.0, 1.0)`.
So there is no real benefit to having two different shader versions.
This will simplify porting shaders to python as it will not be
necessary to use a 3D and a 2D version of the shaders.
In python the new name for '2D_IMAGE' and '3D_IMAGE'
is 'IMAGE', but the old names still work for backward
compatibility.
The only real difference between `GPU_SHADER_2D_FLAT_COLOR` and
`GPU_SHADER_3D_FLAT_COLOR` is that in the vertex shader the 2D
version uses `vec4(pos, 0.0, 1.0)` and the 3D version uses
`vec4(pos, 1.0)`.
But VBOs with 2D attributes work perfectly in shaders that use 3D
attributes. Components not specified are filled with components from
`vec4(0.0, 0.0, 0.0, 1.0)`.
So there is no real benefit to having two different shader versions.
This will simplify porting shaders to python as it will not be
necessary to use a 3D and a 2D version of the shaders.
In python the new name for '2D_FLAT_COLOR'' and '3D_FLAT_COLOR'
is 'FLAT_COLOR', but the old names still work for backward
compatibility.
The only real difference between `GPU_SHADER_2D_UNIFORM_COLOR` and
`GPU_SHADER_3D_UNIFORM_COLOR` is that in the vertex shader the 2D
version uses `vec4(pos, 0.0, 1.0)` and the 3D version uses
`vec4(pos, 1.0)`.
But VBOs with 2D attributes work perfectly in shaders that use 3D
attributes. Components not specified are filled with components from
`vec4(0.0, 0.0, 0.0, 1.0)`.
So there is no real benefit to having two different shader versions.
This will simplify porting shaders to python as it will not be
necessary to use a 3D and a 2D version of the shaders.
In python the new name for '2D_UNIFORM_COLOR'' and '3D_UNIFORM_COLOR'
is 'UNIFORM_COLOR', but the old names still work for backward
compatibility.
Differential Revision: https://developer.blender.org/D15836
Minimum horizontal area size should be scaled by UI resolution.
See D15865 for more details.
Differential Revision: https://developer.blender.org/D15865
Reviewed by Brecht Van Lommel
For copy-on-write, we want to share attribute arrays between meshes
where possible. Mutable pointers like `Mesh.mvert` make that difficult
by making ownership vague. They also make code more complex by adding
redundancy.
The simplest solution is just removing them and retrieving layers from
`CustomData` as needed. Similar changes have already been applied to
curves and point clouds (e9f82d3dc7, 410a6efb74). Removing use of
the pointers generally makes code more obvious and more reusable.
Mesh data is now accessed with a C++ API (`Mesh::edges()` or
`Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`).
The CoW changes this commit makes possible are described in T95845
and T95842, and started in D14139 and D14140. The change also simplifies
the ongoing mesh struct-of-array refactors from T95965.
**RNA/Python Access Performance**
Theoretically, accessing mesh elements with the RNA API may become
slower, since the layer needs to be found on every random access.
However, overhead is already high enough that this doesn't make a
noticible differenc, and performance is actually improved in some
cases. Random access can be up to 10% faster, but other situations
might be a bit slower. Generally using `foreach_get/set` are the best
way to improve performance. See the differential revision for more
discussion about Python performance.
Cycles has been updated to use raw pointers and the internal Blender
mesh types, mostly because there is no sense in having this overhead
when it's already compiled with Blender. In my tests this roughly
halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million
face grid).
Differential Revision: https://developer.blender.org/D15488
