Currently there are many function declarations in `BKE_node.h` that
don't actually have implementations in blenkernel. This commit moves
the declarations to `NOD_composite.h`, `NOD_texture.h`, and
`NOD_shader.h` instead. This helps to clarify the purpose of the
different modules.
Differential Revision: https://developer.blender.org/D13869
Fixes T93680
For current drivers of Intel HD Graphics 4400 and 4600, various Program Introspection functions appear broken and return incorrect values, causing crashes in the current handling of SSBOs. Disable use of this feature on those devices. Add checks to features that use SSBOs (Hair and Subdivision Modifier).
Reviewed By: fclem, jbakker
Maniphest Tasks: T93680
Differential Revision: https://developer.blender.org/D13806
This patch introduces an extrude node with three modes. The vertex mode
is quite simple, and just attaches new edges to the selected vertices.
The edge mode attaches new faces to the selected edges. The faces mode
extrudes patches of selected faces, or each selected face individually,
depending on the "Individual" boolean input.
The default value of the "Offset" input is the mesh's normals, which
can be scaled with the "Offset Scale" input.
**Attribute Propagation**
Attributes are transferred to the new elements with specific rules.
Attributes will never change domains for interpolations. Generally
boolean attributes are propagated with "or", meaning any connected
"true" value that is mixed in for other types will cause the new value
to be "true" as well. The `"id"` attribute does not have any special
handling currently.
Vertex Mode
- Vertex: Copied values of selected vertices.
- Edge: Averaged values of selected edges. For booleans, edges are
selected if any connected edges are selected.
Edge Mode
- Vertex: Copied values of extruded vertices.
- Connecting edges (vertical): Average values of connected extruded
edges. For booleans, the edges are selected if any connected
extruded edges are selected.
- Duplicate edges: Copied values of selected edges.
- Face: Averaged values of all faces connected to the selected edge.
For booleans, faces are selected if any connected original faces
are selected.
- Corner: Averaged values of corresponding corners in all faces
connected to selected edges. For booleans, corners are selected
if one of those corners are selected.
Face Mode
- Vertex: Copied values of extruded vertices.
- Connecting edges (vertical): Average values of connected selected
edges, not including the edges "on top" of extruded regions.
For booleans, edges are selected when any connected extruded edges
were selected.
- Duplicate edges: Copied values of extruded edges.
- Face: Copied values of the corresponding selected faces.
- Corner: Copied values of corresponding corners in selected faces.
Individual Face Mode
- Vertex: Copied values of extruded vertices.
- Connecting edges (vertical): Average values of the two neighboring
edges on each extruded face. For booleans, edges are selected
when at least one neighbor on the extruded face was selected.
- Duplicate edges: Copied values of extruded edges.
- Face: Copied values of the corresponding selected faces.
- Corner: Copied values of corresponding corners in selected faces.
**Differences from edit mode**
In face mode (non-individual), the behavior can be different than the
extrude tools in edit mode-- this node doesn't handle keeping the back-
faces around in the cases that the edit mode tools do. The planned
"Solidify" node will handle that use case instead. Keeping this node
simpler and faster is preferable at this point, especially because that
sort of "smart" behavior is not that predictable and makes less sense
in a procedural context.
In the future, an "Even Offset" option could be added to this node
hopefully fairly simply. For now it is left out in order to keep
the patch simpler.
**Implementation**
For the implementation, the `Mesh` data structure is used directly
rather than converting to `BMesh` and back like D12224. This optimizes
for large extrusion operations rather than many sequential extrusions.
While this is potentially more verbose, it has some important benefits:
First, there is no conversion to and from `BMesh`. The code only has
to fill arrays and it can do that all at once, making each component of
the algorithm much easier to optimize. It also makes the attribute
interpolation more explicit, and likely faster. Only limited topology
maps must be created in most cases.
While there are some necessary loops and allocations with the size of
the entire mesh, I tried to keep everything I could on the order of the
size of the selection rather than the size of the mesh. In that respect,
the individual faces mode is the best, since there is no topology
information necessary, and the amount of work just depends on the size
of the selection.
Modifying an existing mesh instead of generating a new one was a bit
of a toss-up, but has a few potential benefits:
- Avoids manually copying over attribute data for original elements.
- Avoids some overhead of creating a new mesh.
- Can potentially take advantage of future ammortized mesh growth.
This could be changed easily if it turns out to be the wrong choice.
Differential Revision: https://developer.blender.org/D13709
This commit improves NURBS knot generation by adding proper support
for the combination of the Bezier and cyclic options. In other cases
the resulting knot doesn't change. This cyclic Bezier knot is used to
create accurate accurate "Nurbs Circle", "Nurbs Cylinder" primitives.
"Nurbs Sphere" and "Nurbs Torus" primitives are also improved by
tweaking the spin operator.
The knot vector in 3rd order NURBS curve with Bezier option turned on
(without cyclic) is changed in comparison to previous calculations,
although it doesn't change the curve shape itself.
The accuracy of the of NURBS circle is fixed, which can be checked by
comparing with mesh circle. Tessellation spacing differences in
circular NURBS is also fixed, which is observable with the NURBS
cylinder and sphere primitives. These were causing seam-like effects.
This commit contains comments from Piotr Makal (@pmakal).
Differential Revision: https://developer.blender.org/D11664
From an error in rBcfa53e0fbeed, the vertex normals in `SculptSession`
seem to be used, but in the case when no "pbvh" is used, the value of
the pointer is never assigned.
Normals were not generally dirty before this "ensure" function with
regular sculpting operations, so this addition shouldn't have any cost.
Differential Revision: https://developer.blender.org/D13854
The UI team requested adding woff2 support to freetype.
this required a new dependency brotli.
This changes adds brotili to the builder and bumps
freetype to version 2.11.0
As freetype now depends on other libraries, for consistency
all use of ${FREETYPE_LIBRARY} in cmake has been updated to
use ${FREETYPE_LIBRARIES} adjustments have been made in the
windows platform file, all other platforms use cmake's
FindFreeType.cmake which already sets this variable.
reviewed by: brecht
Differential Revision: https://developer.blender.org/D13448
This node can scale individual edges and faces. When multiple selected
faces/edges share the same vertices, they are scaled together.
The center and scaling factor is averaged in this case.
For some examples see D13757.
Differential Revision: https://developer.blender.org/D13757
Currently there is no way to flip normals in geometry nodes. This node
makes that possible by flipping the winding order of selected faces.
The node is purposely not called "Flip Normals", because normals are
derived data, changing them is only a side effect. The real change is
that the vertex and edge indices in the face corners of every selected
polygon are reversed, and face corner attribute data is reversed.
While there are existing utilities to flip a polygon and its custom
data, this node aims to process an attribute's data together instead
of processing all attributes separately for each index.
Differential Revision: https://developer.blender.org/D13809
The code here was using velocity based interpolation copied from particles.
However there is no velocity cached in the rigid body point cache so the
results were non-sensical.
This adds a new curve primitive to generate arcs.
Radius mode (default): Generates a fixed radius arc on XY plane
with controls for Angle, Sweep and Invert.
Points mode: Generates a three point curve arc from Start to End
via Middle with an Angle Offset and option to invert the arc.
There are also outputs for arc center, radius and normal direction
relative to the Z-axis.
This patch is based on previous patches
D11713 and D13100 from @guitargeek. Thank you.
Reviewed By: HooglyBoogly
Differential Revision: https://developer.blender.org/D13640
This adds vertex creasing support for OpenSubDiv for modeling, rendering,
Alembic and USD I/O.
For modeling, vertex creasing follows the edge creasing implementation with an
operator accessible through the Vertex menu in Edit Mode, and some parameter in
the properties panel. The option in the Subsurf and Multires to use edge
creasing also affects vertex creasing.
The vertex crease data is stored as a CustomData layer, unlike edge creases
which for now are stored in `MEdge`, but will in the future also be moved to
a `CustomData` layer. See comments for details on the difference in behavior
for the `CD_CREASE` layer between egdes and vertices.
For Cycles this adds sockets on the Mesh node to hold data about which vertices
are creased (one socket for the indices, one for the weigths).
Viewport rendering of vertex creasing reuses the same color scheme as for edges
and creased vertices are drawn bigger than uncreased vertices.
For Alembic and USD, vertex crease support follows the edge crease
implementation, they are always read, but only exported if a `Subsurf` modifier
is present on the Mesh.
Reviewed By: brecht, fclem, sergey, sybren, campbellbarton
Differential Revision: https://developer.blender.org/D10145
This brush fixes the random spikes that
occasionally happen in multires models.
These spikes can be nearly impossible to
fix manually and can make working with
multires a nightmare.
- Add BM_mesh_debug_print & BM_mesh_debug_info.
- Report flags in Mesh.cd_flag in BKE_mesh_debug_print
- Move custom data printing into customdata.cc (noted as a TODO).
Note that the term "runtime" has been removed from
`BKE_mesh_runtime_debug_print` since these are useful for debugging any
kind of mesh data.
Code that handled merging & initializing custom-data from other
meshes sometimes missed checks for this flag, causing bevel weights to
lost when the mesh was converted to a BMesh.
The following changes are a more general fix for T94197.
- Add BM_mesh_copy_init_customdata_from_mesh_array which initializes
custom-data from multiple meshes at once.
As well as initializing custom-data layers from Mesh.cd_flag.
This isn't essential for boolean, however it avoids the overhead of
resizing custom-data layers.
- Loading mesh data into a BMesh now respects Mesh.cd_flag
instead of only checking if the BMesh custom-data-layer exists.
Without this, the order of meshes passed to BM_mesh_bm_from_me could
give different (incorrect) results.
- Copying mesh data now copies `cd_flag` too. This is a precaution
as in my tests evaluating modifiers these values always matched.
Nevertheless it's correct to copy this value as custom-data it's
self is being copied.
This node allows accessing data of other elements in the context geometry.
It is similar to the Transfer Attribute node in Index mode. The main difference
is that this node does not require a geometry input, because the context
is used.
The node can e.g. be used to generalize what the Edge Vertices node is doing.
Instead of only being able to get the position of the vertices of an edge,
any field/attribute can be accessed on the vertices.
Differential Revision: https://developer.blender.org/D13825
It's now easier than before to do the interpolation of attributes
only for the elements that are actually used in some cases.
This can result in a speedup because unnecessary computations
can be avoided. See the patch for a simple performance test.
Differential Revision: https://developer.blender.org/D13828
Object/collection asset workflow would need the bounding box for snapping.
The bounding box is stored using ID properties in the scene. Currently ID properties
aren't stored in the asset index, what would break object snapping. For this reason
Asset Indexing is turned off in mater. This patch will introduce the indexing of ID
properties what will allow the indexing to be turned on again.
## Data Mapping ##
For data mapping we store the internal structure of IDProperty to the indexer (including meta-data) to be able to deserialize it back.
```
[
{
"name": ..,
"value": ..,
"type": ..,
/* `subtype` and `length` are only available for IDP_ARRAYs. */
"subtype": ..,
},
]
```
| **DNA** | **Serialize type** | **Note** |
| IDProperty.name | StringValue| |
| IDProperty.type | StringValue| "IDP_STRING", "IDP_INT", "IDP_FLOAT", "IDP_ARRAY", "IDP_GROUP", "IDP_DOUBLE"|
| IDProperty.subtype | StringValue| "IDP_INT", "IDP_FLOAT", "IDP_GROUP", "IDP_DOUBLE" |
| IDProperty.value | StringValue | When type is IDP_STRING |
| IDProperty.value | IntValue | When type is IDP_INT |
| IDProperty.value | DoubleValue | When type is IDP_FLOAT/IDP_DOUBLE |
| IDProperty.value | ArrayValue | When type is IDP_GROUP. Recursively uses the same structure as described in this section. |
| IDProperty.value | ArrayValue | When type is IDP_ARRAY. Each element holds a single element as described in this section. |
NOTE: IDP_ID and IDP_IDARRAY aren't supported. The entry will not be added.
Example
```
[
{
"name": "MyIntValue,
"type": "IDP_INT",
"value": 6,
},
{
"name": "myComplexArray",
"type": "IDP_ARRAY",
"subtype": "IDP_GROUP",
"value": [
[
{
"name": ..
....
}
]
]
}
]
```
## Considered alternatives ##
- Add conversion functions inside `asset_indexer`; makes generic code part of a specific solution.
- Add conversion functions inside `BLI_serialize`; would add data transformation responsibilities inside a unit that is currently only responsible for formatting.
- Use direct mapping between IDP properties and Values; leads to missing information and edge cases (empty primitive arrays) that could not be de-serialized.
Reviewed By: Severin, mont29, HooglyBoogly
Maniphest Tasks: T92306
Differential Revision: https://developer.blender.org/D12990
Typo in rB605cdc4346e5f82, both `eBlendfileLinkAppendForeachItemFlag`
flags had the same value, effectively preventing to filter out direct
vs. indirect appended items.
Override layers are a standard feature of Alembic, where archives can override
data from other archives, provided that the hierarchies match.
This is useful for modifying a UV map, updating an animation, or even creating
some sort of LOD system where low resolution meshes are swapped by high resolution
versions.
It is possible to add UV maps and vertex colors using this system, however, they
will only appear in the spreadsheet editor when viewing evaluated data, as the UV
map and Vertex color UI only show data present on the original mesh.
Implementation wise, this adds a `CacheFileLayer` data structure to the `CacheFile`
DNA, as well as some operators and UI to present and manage the layers. For both
the Alembic importer and the Cycles procedural, the main change is creating an
archive from a list of filepaths, instead of a single one.
After importing the base file through the regular import operator, layers can be added
to or removed from the `CacheFile` via the UI list under the `Override Layers` panel
located in the Mesh Sequence Cache modifier. Layers can also be moved around or
hidden.
See differential page for tests files and demos.
Reviewed by: brecht, sybren
Differential Revision: https://developer.blender.org/D13603
For an upcoming refactoring of library remapping we want to be able to test if the logic won't change.
It also increased my experience inside the remapping codebase and find out what exactly needed to
be refactored.
This patch adds test cases for the core functionality of `foreach_libblock_remap_callback`. The test cases
don't cover of all the branches. Also pre-, post-processing, referencing and proxies are not tested.
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D13815
I noticed these when doing final cleanup on rBcfa53e0fbeed.
One use was removed in that commit, the others were unused
going further back a few years.
Differential Revision: https://developer.blender.org/D13834
`BKE_layer_collection_sync` was missing a specific handling for one of
those pre-master collection cases,
NOTE: It is a bit unfortunate to have to do 'do-version' code in BKE...
At some point might look into moving this into actual `do_version` file,
but this is not fully trivial not critical improvement for now.
2-point-curves are treated separately from 3plus-point-curves (assume a
lot of the twisting reduction can be skipped, so there is a dedicated
function for single segment curves).
And while using the 3plus-point-curves function [`make_bevel_list_3D`]
would actually work in this case, the dedicated function
`make_bevel_list_segment_3D` would only consider the tilt of the second
point and would just copy over the quat to the first point as well. Dont
see a reason for this, now consider the first point's tilt as well.
Maniphest Tasks: T94837
Differential Revision: https://developer.blender.org/D13813
The mask is only used if it's not zero. Adding the normal mask made
it not zero, but it didn't include anything else, so all custom data
layers except normals were removed. The fix is to only add normals
to the mask when it should be used.
As described in T91186, this commit moves mesh vertex normals into a
contiguous array of float vectors in a custom data layer, how face
normals are currently stored.
The main interface is documented in `BKE_mesh.h`. Vertex and face
normals are now calculated on-demand and cached, retrieved with an
"ensure" function. Since the logical state of a mesh is now "has
normals when necessary", they can be retrieved from a `const` mesh.
The goal is to use on-demand calculation for all derived data, but
leave room for eager calculation for performance purposes (modifier
evaluation is threaded, but viewport data generation is not).
**Benefits**
This moves us closer to a SoA approach rather than the current AoS
paradigm. Accessing a contiguous `float3` is much more efficient than
retrieving data from a larger struct. The memory requirements for
accessing only normals or vertex locations are smaller, and at the
cost of more memory usage for just normals, they now don't have to
be converted between float and short, which also simplifies code
In the future, the remaining items can be removed from `MVert`,
leaving only `float3`, which has similar benefits (see T93602).
Removing the combination of derived and original data makes it
conceptually simpler to only calculate normals when necessary.
This is especially important now that we have more opportunities
for temporary meshes in geometry nodes.
**Performance**
In addition to the theoretical future performance improvements by
making `MVert == float3`, I've done some basic performance testing
on this patch directly. The data is fairly rough, but it gives an idea
about where things stand generally.
- Mesh line primitive 4m Verts: 1.16x faster (36 -> 31 ms),
showing that accessing just `MVert` is now more efficient.
- Spring Splash Screen: 1.03-1.06 -> 1.06-1.11 FPS, a very slight
change that at least shows there is no regression.
- Sprite Fright Snail Smoosh: 3.30-3.40 -> 3.42-3.50 FPS, a small
but observable speedup.
- Set Position Node with Scaled Normal: 1.36x faster (53 -> 39 ms),
shows that using normals in geometry nodes is faster.
- Normal Calculation 1.6m Vert Cube: 1.19x faster (25 -> 21 ms),
shows that calculating normals is slightly faster now.
- File Size of 1.6m Vert Cube: 1.03x smaller (214.7 -> 208.4 MB),
Normals are not saved in files, which can help with large meshes.
As for memory usage, it may be slightly more in some cases, but
I didn't observe any difference in the production files I tested.
**Tests**
Some modifiers and cycles test results need to be updated with this
commit, for two reasons:
- The subdivision surface modifier is not responsible for calculating
normals anymore. In master, the modifier creates different normals
than the result of the `Mesh` normal calculation, so this is a bug
fix.
- There are small differences in the results of some modifiers that
use normals because they are not converted to and from `short`
anymore.
**Future improvements**
- Remove `ModifierTypeInfo::dependsOnNormals`. Code in each modifier
already retrieves normals if they are needed anyway.
- Copy normals as part of a better CoW system for attributes.
- Make more areas use lazy instead of eager normal calculation.
- Remove `BKE_mesh_normals_tag_dirty` in more places since that is
now the default state of a new mesh.
- Possibly apply a similar change to derived face corner normals.
Differential Revision: https://developer.blender.org/D12770
The fundamental limitation is that we can only have one instance
("dupli") generator at a time. Because the mesh output of a curve
object is output as an instances, the geometry set instances existed,
replacing the object as font instances. The "fix" is to reverse the
order. The behavior won't be perfect still, but at least the old
behavior will be preserved, which is really what matters for a
feature like this.
One way to take this change further would be completely disabling
regular geometry evaluation while this option is active. However,
it doesn't seem like that would actually improve the state of the code.
Differential Revision: https://developer.blender.org/D13768
This is my attempt of adding defaults for the space clip editor struct
(in line with https://developer.blender.org/T80164).
It adds the default allocation for `SpaceClip` and
`node_composite_movieclip.cc`. This also solves the error below (for
C++ files using the DNA_default_alloc), which was put forward by
Sergey Sharybin.
Differential Revision: https://developer.blender.org/D13367
Reviewed by: Julian Eisel
This patch implements the vector types (i.e:`float2`) by making heavy
usage of templating. All vector functions are now outside of the vector
classes (inside the `blender::math` namespace) and are not vector size
dependent for the most part.
In the ongoing effort to make shaders less GL centric, we are aiming
to share more code between GLSL and C++ to avoid code duplication.
####Motivations:
- We are aiming to share UBO and SSBO structures between GLSL and C++.
This means we will use many of the existing vector types and others
we currently don't have (uintX, intX). All these variations were
asking for many more code duplication.
- Deduplicate existing code which is duplicated for each vector size.
- We also want to share small functions. Which means that vector
functions should be static and not in the class namespace.
- Reduce friction to use these types in new projects due to their
incompleteness.
- The current state of the `BLI_(float|double|mpq)(2|3|4).hh` is a
bit of a let down. Most clases are incomplete, out of sync with each
others with different codestyles, and some functions that should be
static are not (i.e: `float3::reflect()`).
####Upsides:
- Still support `.x, .y, .z, .w` for readability.
- Compact, readable and easilly extendable.
- All of the vector functions are available for all the vectors types
and can be restricted to certain types. Also template specialization
let us define exception for special class (like mpq).
- With optimization ON, the compiler unroll the loops and performance
is the same.
####Downsides:
- Might impact debugability. Though I would arge that the bugs are
rarelly caused by the vector class itself (since the operations are
quite trivial) but by the type conversions.
- Might impact compile time. I did not saw a significant impact since
the usage is not really widespread.
- Functions needs to be rewritten to support arbitrary vector length.
For instance, one can't call `len_squared_v3v3` in
`math::length_squared()` and call it a day.
- Type cast does not work with the template version of the `math::`
vector functions. Meaning you need to manually cast `float *` and
`(float *)[3]` to `float3` for the function calls.
i.e: `math::distance_squared(float3(nearest.co), positions[i]);`
- Some parts might loose in readability:
`float3::dot(v1.normalized(), v2.normalized())`
becoming
`math::dot(math::normalize(v1), math::normalize(v2))`
But I propose, when appropriate, to use
`using namespace blender::math;` on function local or file scope to
increase readability.
`dot(normalize(v1), normalize(v2))`
####Consideration:
- Include back `.length()` method. It is quite handy and is more C++
oriented.
- I considered the GLM library as a candidate for replacement. It felt
like too much for what we need and would be difficult to extend / modify
to our needs.
- I used Macros to reduce code in operators declaration and potential
copy paste bugs. This could reduce debugability and could be reverted.
- This touches `delaunay_2d.cc` and the intersection code. I would like
to know @howardt opinion on the matter.
- The `noexcept` on the copy constructor of `mpq(2|3)` is being removed.
But according to @JacquesLucke it is not a real problem for now.
I would like to give a huge thanks to @JacquesLucke who helped during this
and pushed me to reduce the duplication further.
Reviewed By: brecht, sergey, JacquesLucke
Differential Revision: https://developer.blender.org/D13791
