Age | Commit message (Collapse) | Author |
|
|
|
This abuse of one one size value to handle another allocated array of a
different size is bad in itself, but at least now read/write code of
this modifier should not risk invalid memory access anymore.
NOTE: invalid memory access would in practice only happen in case endian
switch would be performed at read time I think (those switches only check
for given length being non-zero, not for a NULL data pointer...).
|
|
Regression in 90a23dec4650d63a836cb9e9969aab4d0da4ba2f.
|
|
If merging is enabled, the mesh might be recreated before
the dirty flag can be cleared, which means the normals aren't
valid anymore. To fix this, clearing the dirty flag should happen
before the merging. This is an existing bug, just exposed by
more recent explicit dirty normal tagging.
|
|
For properties exposed to the geometry nodes modifier, decorators didn't
work at all for colors and it only worked on the X component of vectors.
The fix is to use -1 for the RNA index of the decorator button instead
of 1, which lets the UI code figure out what to do with arrays.
|
|
Geometry node group inputs and outputs get a new property that controls
the attribute name used for that field input/output when assigning the
node group to a modifier for the first time. If the default name is assigned
to an input, the default "Use attribute name" is true .
In order to properly detect when a node group is first assigned,
the modifier now clears its properties when clearing the node group.
Ref T96707
Differential Revision: https://developer.blender.org/D14761
|
|
When more than one, consecutive, subdivision modifier is used on a Mesh,
the last subsurf modifier is used for GPU subdivision even though it
might be disabled. This is because retrieving the last subsurf modifier
in the draw code did not check whether the modifier was disabled or not.
To fix this, the session UUID of the modifier which delegated evaluation
to the GPU code is cached and used in the draw to select the right subsurf
modifier.
Differential Revision: https://developer.blender.org/D14488
|
|
The new name is `Internal Dependencies`.
* Is more inline with the general goal of the panel.
* Can also show which external objects are used in the node tree in the future.
This name was choosen in the geometry nodes submodule meeting (2022-04-25).
Differential Revision: https://developer.blender.org/D14752
|
|
Applying the coordinates already tags the normals dirty
|
|
|
|
Caused by a typo/mistake in rB6a3c3c77b3ebdbcd4455.
|
|
If the attribute already existed, but had a different domain or data type
than the user tried to write to it with (i.e. writing to `position` with
a float), then the data from field evaluation wasn't freed.
This restructures the geometry nodes modifier attribute writing process
to solve that problem and remove some of the nested if statements
that made the process confusing.
One case that still doesn't work is writing to a builtin attribute from
a different domain. If `OutputAttribute` gets that feature then that
could be supported here too.
Differential Revision: https://developer.blender.org/D14706
|
|
Since {rBeae36be372a6b16ee3e76eff0485a47da4f3c230} the distinction
between float and byte colors is more explicit in the ui. So far, geometry
nodes couldn't really deal with byte colors in general. This patch fixes that.
There is still only one color socket, which contains float colors. Conversion
to and from byte colors is done when read from or writing to attributes.
* Support writing to byte color attributes in Store Named Attribute node.
* Support converting to/from byte color in attribute conversion operator.
* Support propagating byte color attributes.
* Add all the implicit conversions from byte colors to the other types.
* Display byte colors as integers in spreadsheet.
Differential Revision: https://developer.blender.org/D14705
|
|
This adds a new subpanel to the geometry nodes modifier which is just
used to display information about used attributes.
* A new panel is used because adding this information anywhere else
clutters the ui too much imo.
* The general layout is similar to that in the tooltip. I found it to be more
trouble than it's worth to share this code.
Possible future improvements:
* Don't show the panel if there are no used named attributes.
* Add some heuristics to determine which named attributes the user does
not have to care about because they are only used in the node group
and don't affect anything else.
Differential Revision: https://developer.blender.org/D14701
|
|
The "PROP" in the name reflects its generic status, and removing
"LOOP" makes sense because it is no longer associated with just
mesh face corners. In general the goal is to remove extra semantic
meaning from the custom data types.
|
|
This is mostly a cleanup to avoid hardcoding the eager calculation of
normals it isn't necessary, by reducing calls to `BKE_mesh_calc_normals`
and by removing calls to `BKE_mesh_normals_tag_dirty` when the mesh
is newly created and already has dirty normals anyway. This reduces
boilerplate code and makes the "dirty by default" state more clear.
Any regressions from this commit should be easy to fix, though the
lazy calculation is solid enough that none are expected.
|
|
This adds a structure, `ABCReadParams`, to store some parameters passed
to `ABC_read_mesh` so we avoid passing too many parameters, and makes it
easier to add more parameters in the future without worrying about
argument order.
Differential Revision: https://developer.blender.org/D14484
|
|
Also ensure space around text in C-comment blocks.
|
|
Both the Alembic and USD libraries use double precision floating
point numbers internally to store time. However the Alembic I/O
code defaulted to floats even though Blender's Scene FPS, which is
generally used for look ups, is stored using a double type. Such
downcasts could lead to imprecise lookups, and would cause
compilation warnings (at least on MSVC).
This modifies the Alembic exporter and importer to make use of
doubles for the current scene time, and only downcasting to float
at the very last steps (e.g. for vertex interpolation). For the
importer, doubles are also used for computing interpolation weights,
as it is based on a time offset.
Although the USD code already used doubles internally, floats were used
at the C API level. Those were replaced as well.
Differential Revision: https://developer.blender.org/D13855
|
|
color attribute system.
This commit removes sculpt colors from experimental
status and unifies it with vertex colors. It
introduces the concept of "color attributes", which
are any attributes that represents colors. Color
attributes can be represented with byte or floating-point
numbers and can be stored in either vertices or
face corners.
Color attributes share a common namespace
(so you can no longer have a floating-point
sculpt color attribute and a byte vertex color
attribute with the same name).
Note: this commit does not include vertex paint mode,
which is a separate patch, see:
https://developer.blender.org/D14179
Differential Revision: https://developer.blender.org/D12587
Ref D12587
|
|
Add blank lines after file references to avoid them being interpreted as
doc-strings the following declarations.
|
|
|
|
|
|
The Alembic procedural was only enabled during viewport renders
originally because it did not have any caching strategy. Now that
is does, we can allow its usage in final renders.
This also removes the `dag_eval_mode` argument passing to
`ModifierTypeInfo.dependsOnTime` which was originally added to detect if
we are doing a viewport render for enabling the procedural.
Differential Revision: https://developer.blender.org/D14520
|
|
This commit moves declarations that depend on `FN_field.hh` out of
`BKE_geometry_set.hh` into `BKE_geometry_fields.hh`. This helps to
reduce the number of areas that need to depend on the functions module,
which recently came in in review of D11591.
In the future we may have a library of standard field inputs in order to
make composing algorithms easier, so it makes sense to have a header
that could contain them and some basic related utilities relating the
concepts of geometry and fields.
Reducing use of unnecessary headers may also reduce compilation time.
Differential Revision: https://developer.blender.org/D14517
|
|
Don't always create a new geometry nodes node tree when adding a
geometry nodes modifier.
This avoids files getting cluttered with empty and unused geometry node
trees that are created every time a nodes modifier is added to an
object - even if only to apply an already existing.
This is also more consistent with other modifiers that also don't
automatically create new data blocks.
The new modifier still automatically gets populated with a new node
tree when adding it via the "New" button in the header of the
geometry nodes editor.
Reviewed By: Hans Goudey, Dalai Felinto, Pablo Vazquez
Differential Revision: D14458
|
|
Value-initialization has the potential to be more efficient.
Also, the code becomes simpler.
|
|
Also rename DNA struct members.
|
|
Follow conventions from T85728.
|
|
|
|
This implements the same interpolation method as for bevel weights
now for vertex and edge creases as well to improve the flexibility.
Differential Revision: http://developer.blender.org/D14170
|
|
- Deprecated headers
- Else after return
- Inconsistent parameter names (I used the most recently modified)
- Raw string literals
|
|
|
|
This moves `MOD_meshsequencecache.c` to C++ and fixes compile warnings
introduced from the change. This uses C++ style casts, as well as
`nullptr` instead of `NULL`.
This will allow to output `GeometrySets` from the modifier, which is C++.
Differential Revision: https://developer.blender.org/D13662
|
|
Currently there is a "calc_face_normal" argument to mesh to bmesh
conversion, but vertex normals had always implicitly inherited whatever
dirty state the mesh input's vertex normals were in. Probably they were
most often assumed to not be dirty, but this was never really correct in
the general case.
Ever since the refactor to move vertex normals out of mesh vertices,
cfa53e0fbeed7178c7, the copying logic has been explicit: copy the
normals when they are not dirty. But it turns out that more control is
needed, and sometimes normals should be calculated for the resulting
BMesh.
This commit adds an option to the conversion to calculate vertex
normals, true by default. In almost all places except the decimate
and edge split modifiers, I just copied the value of the
"calc_face_normals" argument.
Differential Revision: https://developer.blender.org/D14406
|
|
Typo (copy/paste mistake) in rB923b28aab85768e2b.
|
|
Since 3b6ee8cee7080af20, a list of vertex groups cannot be retrieved
from curve objects for merging because curve objects do not support
vertex groups. Previously the empty list on the object was returned.
Only mesh objects are supported for the caps.
|
|
This is a follow up to rB2252bc6a5527cd7360d1ccfe7a2d1bc640a8dfa6.
|
|
For more detail about `CPPType`, see `BLI_cpp_type.hh` and D14367.
Differential Revision: https://developer.blender.org/D14367
|
|
This commit removes the implementations of legacy nodes,
their type definitions, and related code that becomes unused.
Now that we have two releases that included the legacy nodes,
there is not much reason to include them still. Removing the
code means refactoring will be easier, and old code doesn't
have to be tested and maintained.
After this commit, the legacy nodes will be undefined in the UI,
so 3.0 or 3.1 should be used to convert files to the fields system.
The net change is 12184 lines removed!
The tooltip for legacy nodes mentioned that we would remove
them before 4.0, which was purposefully a bit vague to allow
us this flexibility. In a poll in a devtalk post showed that the
majority of people were okay with removing the nodes.
https://devtalk.blender.org/t/geometry-nodes-backward-compatibility-poll/20199
Differential Revision: https://developer.blender.org/D14353
|
|
|
|
So far it was needed to declare a new RNA struct to `RNA_access.h` manually.
Since 9b298cf3dbec we generate a `RNA_prototypes.h` for RNA property
declarations. Now this also includes the RNA struct declarations, so they don't
have to be added manually anymore.
Differential Revision: https://developer.blender.org/D13862
Reviewed by: brecht, campbellbarton
|
|
Activating a gizmo used the windows eventstate which may have values
newer than the event used to activate the gizmo.
This meant transforms check for the key that activated transform
could be incorrect.
Support passing an event when calling operators to avoid this problem.
|
|
|
|
|
|
Correct misspellings in code comments of "vertex" and "vertices".
See D13932 for more details.
Differential Revision: https://developer.blender.org/D13932
Reviewed by Harley Acheson
|
|
|
|
Differential Revision: https://developer.blender.org/D14225
|
|
This fix contains two parts. There was one critical mistake where
order of two indices was wrong when removing constraint planes from
the array. The other changes are improvements to the used thresholds
to keep everything numerically stable.
Differential Revision: http://developer.blender.org/D14183
|
|
|