The simulation used to reset when the previously computed frame is the
same as the current one. However, in this case the output should just be
the same as in the previous computation.
Pull Request: https://projects.blender.org/blender/blender/pulls/110799
Show node group inputs in the redo panel, including the
"use attribute" toggle. There are a few limitations that will
be solved separately:
- The redo panel is _always_ drawn, there is no way to show it conditionally yet
- There is no way to add the operator name to the redo panel title yet
- Attribute search is still missing for attribute inputs
Pull Request: https://projects.blender.org/blender/blender/pulls/109975
Remove the "_for_read" suffix from methods to get geometry and geometry
components. That should be considered the default, so the suffix just
adds unnecessary text. This is consistent with the attribute API and
various implicit sharing data access methods.
Use "from_mesh" instead of "create_with_mesh". This is consistent with
the recently used naming for the `IndexMask` API.
Pull Request: https://projects.blender.org/blender/blender/pulls/110738
A few places already calculated vertex normals with better contextual
information to improve performance. To allow changing the storage of
vertex normals more (mostly for improved caching), change some code
from "get normals, set values, clear dirty flag" to "make vertex
normals data, give to mesh". This makes the API less awkward too,
since previously the "get for write" and "clear dirty" calls always
had to be separated.
Pull Request: https://projects.blender.org/blender/blender/pulls/110754
Replace `BKE_mesh_face_flip_ex()` with `bke::mesh_flip_faces()`.
This gives better performance since it avoids custom data name
lookups for every face index, and processes data in a more cache
friendly way. Also remove the `CustomData_swap` API function
as mentioned in 09b6eac5c4.
Flipping 16 million faces, I observed a 3.25x speedup, from 760 to 230 ms.
Pull Request: https://projects.blender.org/blender/blender/pulls/110702
Historically, the OCIO based color management implementation in Blender
had exceptions to treat specific configurations differently. It was a
compatibility with the legacy "No color management" option.
With time and more development in the area there are better ways of
achieving this goal, if needed.
This commit removes the named-based exception, which also solves confusion
about why certain similar configurations (from OCIO stand point) give
different results. As well as allows to create a cleaner plate for an
upcoming additions in the OCIO configuration such as AgX.
Quite simple and technical change which constant-folds the check for
whether the scene color management enabled or not with "true" value.
Ref #110685
Pull Request: https://projects.blender.org/blender/blender/pulls/110580
The issue was that `CustomData_swap` modifies all layers, but does not ensure
that the layers are actually mutable. This resulted in it modifying shared layers.
Now it ensures that the layers are mutable first (which copies the layers if they
are shared).
Longer term, it would be good to remove `CustomData_swap` since it's not a
good API performance wise, but that is outside of the scope of this patch.
Pull Request: https://projects.blender.org/blender/blender/pulls/110678
Previously the panel type name of a modifier (e.g. "MOD_PT_Smooth") was
created by copying from the ModifierTypeInfos name.
This meant that modifiers with the same default name would use
the same identifier for the panels.
Since different object types (e.g. OB_GREASE_PENCIL and OB_MESH)
might want to use the same default modifier name, this PR introduces
an idname field in the ModifierTypeInfo struct. This is then used to
generate the panel type name.
For compatibility reasons, the idname is the same as the name for now.
Note: Because the name was used previously, this means that some
modifiers have spaces in their panel type name.
E.g. "MOD_PT_Volume to Mesh".
Pull Request: https://projects.blender.org/blender/blender/pulls/110468
Currently, while calculating face corner normals, Blender retrieves
custom normal data with write access. When the the custom normals in a
single smooth corner fan don't match, they are reset to the average
value.
This behavior is very old, but it comes from when Blender didn't have a
strong idea of const correctness. Indeed, modifying custom normal data
while calculating normals isn't threadsafe, which is important because
normals are calculated for viewport drawing, for example. And in the
future, properly caching face corner normals (see #93551) will require
the ability to calculate normals on a properly const mesh.
The fix is to still use the average of custom normals in a fan, but
not write that back to the custom data array. In my testing the results
are the same. Setting custom normals still fills the same value for all
corners in a fan.
Pull Request: https://projects.blender.org/blender/blender/pulls/110478
Implements the rest of #101689, after 5e9ea9243b.
- `vdata` -> `vert_data`
- `edata` -> `edge_data`
- `pdata` -> `face_data`
- `ldata` -> `loop_data`
A deeper rename of `loop` to `corner` will be proposed as a next
step, and renaming `totvert` and `totedge` can be done separately.
Pull Request: https://projects.blender.org/blender/blender/pulls/110432
Utility functions make accessing the next and previous corner of a face
more obvious, and range based for loops make iterating over corners
or vertices in a face simpler too.
The cleanup of blenkernel last weeks , caused the house of cards to
collapse on top of bf_gpu's shader_builder, which is off by default
but used on a daily basis by the rendering team.
Given the fixes forward in #110394 ran into a ODR violation in OSL that
was hiding there for years, I don't see another way forward without
impeding the rendering teams productivity for "quite a while" as there
is no guarantee the OSL issue would be the end of it.
the only way forward appears to be back.
this reverts :
19422044eda670b53abe0f541db97cbe516e8c813e88a2f44c4e64b772f59547e7a31707fe6c5a57
The problematic commit was 07fe6c5a57
as blenkernel links most of blender, it's a bit of a link order issue
magnet. Given all these commits stack, it's near impossible to revert
just that one without spending a significant amount of time resolving
merge conflicts. 99% of that work was automated, so easier to just
revert all of them, and re-do the work, than it is to deal with the
merge conflicts.
Pull Request: https://projects.blender.org/blender/blender/pulls/110438
Implements part of #101689.
The "poly" name was chosen to distinguish the `MLoop` + `MPoly`
combination from the `MFace` struct it replaced. Those two structures
persisted together for a long time, but nowadays `MPoly` is gone, and
`MFace` is only used in some legacy code like the particle system.
To avoid unnecessarily using a different term, increase consistency
with the UI and with BMesh, and generally make code a bit easier to
read, this commit replaces the `poly` term with `poly`. Most variables
that use the term are renamed too. `Mesh.totface` and `Mesh.fdata` now
have a `_legacy` suffix to reduce confusion. In a next step, `pdata`
can be renamed to `face_data` as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/109819
"Flip" option in mirror modifier is only effective for when "Bisect" is
enabled, thus grey out the flip option when it's ineffective to avoid
confusion on the user interface.
Pull Request: https://projects.blender.org/blender/blender/pulls/110191
Update VertexWeighEdit modifier Group Add / Remove threshold to be inclusive.
Additionally, add 3.6 backwards compatibility (4.0 versioning) to slightly offset Group Add / Remove threshold property value to make exclusive.
Pull Request: https://projects.blender.org/blender/blender/pulls/108286
This formats code that is disabled using `#if 0`. Formatting was achieved
by temporarily changing `#if 0` to `#if 1 /*something*/`, then formatting,
and then changing it back to `#if 0`.
This adds support for running a set of nodes repeatedly. The number
of iterations can be controlled dynamically as an input of the repeat
zone. The repeat zone can be added in via the search or from the
Add > Utilities menu.
The main use case is to replace long repetitive node chains with a more
flexible alternative. Technically, repeat zones can also be used for
many other use cases. However, due to their serial nature, performance
is very sub-optimal when they are used to solve problems that could
be processed in parallel. Better solutions for such use cases will
be worked on separately.
Repeat zones are similar to simulation zones. The major difference is
that they have no concept of time and are always evaluated entirely in
the current frame, while in simulations only a single iteration is
evaluated per frame.
Stopping the repetition early using a dynamic condition is not yet
supported. "Break" functionality can be implemented manually using
Switch nodes in the loop for now. It's likely that this functionality
will be built into the repeat zone in the future.
For now, things are kept more simple.
Remaining Todos after this first version:
* Improve socket inspection and viewer node support. Currently, only
the first iteration is taken into account for socket inspection
and the viewer.
* Make loop evaluation more lazy. Currently, the evaluation is eager,
meaning that it evaluates some nodes even though their output may not
be required.
Pull Request: https://projects.blender.org/blender/blender/pulls/109164
This data-block was originally added in eb4e3bbe68.
However, that original plan wasn't fully implemented, with simulations
now integrated with geometry nodes and modifiers instead of a separate
data-block. We kept the data-block around anyway since we have the
loose plan of using a similar data-block to make global simulations
connected between multiple objects. But it may be a while before we
implement that, and in the meantime having this just causes confusion.
When we don't need to preserve a persistent cache, we can use
the geometry from the last frame directly rather than copying it.
Though implicit lets us avoid copying large data arrays when they
aren't changed, this can still give a large improvement for something
like particle simulation where the majority of the data was copied
every frame.
Pull Request: https://projects.blender.org/blender/blender/pulls/109742
The "No Cache" simulation nodes option effectively changes the cache
to work in a "realtime mode" where there are only two states, the
current and previous frame. Whenever the current frame doesn't
increase, the previous state should reset. This didn't happen
properly, and it was hard to verify because the code was shared
with the regular "cache on" mode.
Instead, separate the caching more in the code, using a different
struct to store the two "realtime" states. Also clarify that we
don't support animation of the "No Cache" option by disabling
support for that in RNA.
Pull Request: https://projects.blender.org/blender/blender/pulls/109741
There's quite a few libraries that depend on dna_type_offsets.h
but had gotten to it by just adding the folder that contains it to
their includes INC section without declaring a dependency to
bf_dna in the LIB section.
which occasionally lead to the lib building before bf_dna and the
header being missing, while this generally gets fixed in CMake by
adding bf_dna to the LIB section of the lib, however until last
week all libraries in the LIB section were linked as INTERFACE so
adding it in there did not resolve the build issue.
To make things still build, we sprinkled add_dependencies wherever
we needed it to force a build order.
This diff :
Declares public include folders for the bf_dna target so there's
no more fudging the INC section required to get to them.
Removes all dna related paths from the INC section for all
libraries.
Adds an alias target bf:dna to signify it has been updated to
modern cmake
Declares a dependency on bf::dna for all libraries that require it
Removes (almost) all calls to add_dependencies for bf_dna
Future work:
Because of the manual dependency management that was done, there is
now some "clutter" with libs depending on bf_dna that realistically
don't. Example bf_intern_opencolorio itself has no dependency on
bf_dna at all, doesn't need it, doesn't use it. However the
dna include folder had been added to it in the past since bf_blenlib
uses dna headers in some of its public headers and
bf_intern_opencolorio does use those blenlib headers.
Given bf_blenlib now correctly declares the dependency on bf_dna
as public bf_intern_opencolorio will get the dna header directory
automatically from CMake, hence some cleanup could be done for
bf_intern_opencolorio
Because 99% of the changes in this diff have been automated, this diff
does not seek to address these issues as there is no easy way to
determine why a certain dependency is in place. A developer will have
to make a pass a this at some later point in time. As I'd rather not
mix automated and manual labour.
There are a few libraries that could not be automatically processed
(ie bf_blendthumb) that also will need this manual look-over.
Pull Request: https://projects.blender.org/blender/blender/pulls/109835
