The function really just gives an index mask of all the faces in the
provided nodes. The multires usage of the function didn't need that,
since it just passed all nodes. Also pass the SubdivCCG directly rather
than the PBVH. And rename the function to make this clearer.
This adds a new `Bake` node which allows saving and loading intermediate geometries.
Typical use cases we want address with this currently are:
* Bake some data for use with a render engine.
* Bake parts of the node tree explicitly for better performance.
For now, the format that is written to disk is not considered to be an import/export format.
It's not guaranteed that data written with one Blender version can be read by another
Blender version. For that it's better to use proper interchange formats. Better support for
those will be added eventually as well. We also plan an `Import Bake` node that allows
reading the blender-specific baked data independent of the Bake node and at different frames.
The baking works very similar to the baking in the simulation zone (UI and implementation
wise). Major differences are:
* The Bake node has a `Bake Still` and `Bake Animation` mode.
* The Bake node doesn't do automatic caching.
Implementation details:
* Refactored how we create the Python operators for moving socket items so that it also
makes sense for non-zones.
* The `ModifierCache` stores an independent map of `SimulationNodeCache` and
`BakeNodeCache`, but both share a common data structure for the actually baked data.
* For baking, the `Bake` node is added as a side-effect-node in the modifier. This will make
sure that the node is baked even if it's currently not connected to the output.
* Had to add a new `DEG_id_tag_update_for_side_effect_request` function that is used
during baking. It's necessary because I want to evaluate the object again even though none
of its inputs changed. The reevaluation is necessary to create the baked data. Using
`DEG_id_tag_update` technically works as well, but has the problem that it also uses the
`DEG_UPDATE_SOURCE_USER_EDIT` flag which (rightly) invalidates simulation caches
which shouldn't happen here.
* Slightly refactored the timeline drawing so that it can also show the baked ranges of
Bake nodes. It does not show anything for baked nodes with a in Still mode though.
* The bake operator is refactored to bake a list of `NodeBakeRequest` which makes the
code easier to follow compared to the previous nested
`ObjectBakeData > ModifierBakeData > NodeBakeData` data structure.
* The bake operators are disabled when the .blend file is not yet saved. This is technically
only necessary when the bake path depends on the .blend file path but seems ok to force
the user anyway (otherwise the bake path may be lost as well if it's set explicitly).
* The same operators are used to bake and delete single bakes in `Bake` nodes and
`Simulation Zones`. On top of that, there are separate operators of baking and deleting all
simulation bakes (those ignore bake nodes).
* The `Bake` node remembers which inputs have been fields and thus may be baked as attributes.
For that it uses an `Is Attribute` flag on the socket item. This is needed because the baked data
may still contain attribute data, even if the inputs to the bake node are disconnected.
* Similar to simulation zones, the behavior of `Bake` nodes is passed into the geometry nodes
evaluation from the outside (from the modifier only currently). This is done by providing the
new `GeoNodesBakeParams` in `GeoNodesCallData` when executing geometry nodes.
Next Steps (mostly because they also involve simulations):
* Visualize nodes that have not been evaluated in the last evaluation.
* Fix issue with seemingly loosing baked data after undo.
* Improve error handling when baked data is not found.
* Show bake node in link drag search.
* Higher level tools for managing bakes.
Pull Request: https://projects.blender.org/blender/blender/pulls/115466
This refactors `SocketValueVariant` with the following goals in mind:
* Support type erasure so that not all users of `SocketValueVariant` have
to know about all the types sockets can have.
* Move towards supporting "rainbow sockets" which are sockets whoose
type is only known at run-time.
* Reduce complexity when dealing with socket values in general. Previously,
one had to use `SocketValueVariantCPPType` a lot to manage uninitialized
memory. This is better abstracted away now.
One related change that I had to do that I didn't see coming at first was that
I had to refactor `set_default_remaining_outputs` because now the default value
of a `SocketValueVariant` would not contain any value. Previously, it was
initialized the zero-value of the template parameter. Similarly, I had to change
how implicit conversions are created, because comparing the `CPPType` of linked
sockets was not enough anymore to determine if a conversion is necessary.
We could potentially use `SocketValueVariant` for the remaining socket types in the
future as well. Not entirely sure if that helps yet. `SocketValueVariant` can easily be
adapted to make that work though. That would also justify the name
"SocketValueVariant" better.
Pull Request: https://projects.blender.org/blender/blender/pulls/116231
Add a utility to set attribute values to their default, use it in a few
places that have already done this samething. Also:
- Don't create resolution or cyclic attributes unnecessarily
- Use API function to set new curve's type
- Always create the new selection on the curve domain
- Remove selection before resize to avoid unnecessary work
Whenever movie frame encoding needs to be in non-RGBA format (pretty much
always, e.g. H.264 uses YUV etc.), the ffmpeg code has been using
sws_scale() since 2007. But that one is completely single threaded.
It can be multi-threaded by passing "threads" option to SwsContext
(in a cumbersome way), combined with sws_scale_frame API. Which however
requires frame data buffers to be allocated via AVBuffer machinery.
Rendering a 300-frame part of Sprite Fright Edit (target H.264 Medium):
- Windows Ryzen 5950X: 16.1 -> 12.0 seconds (generate_video_frame part
4.7 -> 0.7 sec).
- Mac M1 Max: 13.1 -> 12.5 sec. Speedup is smaller, but comparatively,
entirely other part of movie rendering (audio resampling inside audaspace)
is way more expensive compared to the windows machine.
Add support for enum values in ID properties.
This is needed for the "Menu Switch" node implementation (#113445) which
relies on ID properties for the top-level modifier UI.
Enums items can optionally be added to the UI data of integer
properties. Each property stores a full set of the enum items to keep
things simple.
Enum items can be added to properties using the `id_properties_ui`
function in the python API. A detailed example can be found in the
`bl_pyapi_idprop.py` test.
There is currently no support yet for editing enum items through the UI.
This is because the "Edit Property" feature is implemented entirely
through a single operator (`WM_OT_properties_edit`) and its properties.
Buttons to add/remove/move items would be operators changing another
operator's properties. A refactor of the custom properties UI is likely
required to make this work.
Pull Request: https://projects.blender.org/blender/blender/pulls/114362
Before this happened as two steps: first allocating the PBVH with a type,
then calculating the BVH and filling it with data. This just confused things,
so change to allocating the struct when building it. Also move the functions
to the C++ namespace, and fix some cases of requiring the PBVH to be set
when it wasn't yet.
This `update_vertex_data` only found nodes with the color update
tag and also added redraw tags. But whenever nodes are marked
for a color update, those redraw tags are already set anyway.
It appears this was meant to solve problems switching active
color attributes during undo and redo, but it doesn't make a
difference when this function is removed.
Studio lights based on image resources are kept in memory, even when only
displayed as an icon. When having many studio lights configured
leads to allocating a lot of memory that are not used.
This patch free image resources when only icons are requested.
For studio lights that are used in a viewport the image resources are kept.
Pull Request: https://projects.blender.org/blender/blender/pulls/116191
Studio lights had gone over several iterations during 2.80. Some
unused options where still in the code, but not used.
This PR cleans up the studio lights to options that are still in use.
Removing:
- Spherical Harmonics: It was used by workbench, but was replaced
by regular OpenGL lights
- Irradiance textures: Was used by an old eevee world light evaluation
- Cached data files.
Pull Request: https://projects.blender.org/blender/blender/pulls/116186
This is a replacement for the workflow that uses
"Bake Curve" and "Unbake Curve" to quickly generate
dense key data.
Compared to the existing workflow it has the advantage
of allowing the user more control over the key types,
and distance between keys, as well as the frame range affected.
Operator options
* Range: the range that will be baked.
Defaults to the scene range or preview range.
* Step: Distance between keyframes.
Can be used to bake on 2s or even bake to subframes.
* Remove Existing Keys: Boolean option that
if enabled also removes keys outside the specified baking range
* Interpolation Type: Choose a interpolation mode used
for new keys e.g. Constant or Bezier
* Bake Modifiers: If enabled bakes the effect of the
modifier stack to keys and deletes the modifier stack.
If false, the code disables the modifiers before baking,
so the resulting keys will behave as if the modifiers didn't exist
The operator can be found in the Graph Editor under `Channel->Bake Channels`
Part of: #111050
Pull Request: https://projects.blender.org/blender/blender/pulls/111263
The term `looptri` was used ambiguously for both single & arrays.
The term `tri` was also used, causing `tri->tri`.
Use terms:
- `looptris` for an array or when dealing with multiple items.
- `looptri` is used when dealing with a single item.
- `lt` for a single MLoopTri variables & arguments.
This was already a convention but not followed closely.
In the context of meshes `totface` reads as if its the number of faces
in the mesh. This was infact the number of looptris however as this
is converted into a "bodyface" array, use that as the prefix.
Link/append code sets the scene pointer to `null` when the active
scene is a linked one, to avoid attempt to instantiate linked data
(objects or collections) into a linked scene, which is forbidden.
However, code was still calling some functions expecting a valid scene
pointer, leading to crash.
It is unclear when exactly this issue was introduced code wise. From a
user perspective, it seems to have been revealed between 3.6 and 4.0
release (bisect points at 00a36cbf24, which does not seem to be
directly related...).
In any case, the fix is trivial and safe, so should we do another 4.0
bugfix release, this commit should be backported.
These shouldn't be called in hot loops at all, and mostly aren't
anymore anyway. Definining them outside of a header allows removing
the `BKE_customdata.hh` include from `BKE_mesh.hh`.
Doing this in preparation for also supporting volume
grids in the same type (#115270).
At some point we could also actually use an `std::variant` in this
type, but that would change behavior without futher changes.
The previous behavior, fairly rough, was simply considering all
Collections and IDs found as part of the root's hierarchy as to be
overridden.
The new behavior is based on a specific tag added to some ID usages.
Currently, these are only the links from a Collection to its Objects
and children Collections, and the link from an Object to its parent.
The goal of this huge reduction of the 'automatically overridden' set of
data in a hierarchy is to avoid creating liboverrides for 'utils' data,
e.g. a collection used as source of data by a GeometryNode generating
some parametric geometry (Blender Studio use-case: some form of LOD
handling).
In general, it means that only Collections and objects part of the
collection hierarchy of the root collection are now overridden.
This should not change in the typical recommended use-case so far (where
there is a clear root collection to the whole overridden hierarchy, and
it contains all related collections and objects).
But this should allow much less overhead (and viewport pollution, due to
the current principle that local (and therefore liboverridden) objects
have to be instanciated in a Scene) for more complex setups.
Note that the initial idea/change is fairly simple and easy to
implement, but it creates some additional complexity in the partial
resync code, since now some linked data may not be detected as needing
a liboverride anymore when processing a sub-hierarchy, while it would
require it when processing the whole hierarchy.
This required adding some more processing to the util functions which
define which ID should be overridden. It essentially creates a
'reference set' of all reference IDs that should be overridden when
the whole hierarchy is considered, and use this as additional input to
decide which ID to override when processing a sub-hierarchy for the
partial resync.
Pull Request: https://projects.blender.org/blender/blender/pulls/115853
This patches refactors the compositor File Output mechanism and
implements the file output node for the Realtime Compositor. The
refactor was done for the following reasons:
1. The existing file output mechanism relied on a global EXR image
resource where the result of each compositor execution for each
view was accumulated and stored in the global resource, until the
last view is executed, when the EXR is finally saved. Aside from
relying on global resources, this can cause effective memory leaks
since the compositor can be interrupted before the EXR is written and
closed.
2. We need common code to share between all compositors since we now
have multiple compositor implementations.
3. We needed to take the opportunity to fix some of the issues with the
existing implementation, like lossy compression of data passes,
and inability to save single values passes.
The refactor first introduced a new structure called the Compositor
Render Context. This context stores compositor information related to
the render pipeline and is persistent across all compositor executions
of all views. Its extended lifetime relative to a single compositor
execution lends itself well to store data that is accumulated across
views. The context currently has a map of File Output objects. Those
objects wrap a Render Result structure and can be used to construct
multi-view images which can then be saved after all views are executed
using the existing BKE_image_render_write function.
Minor adjustments were made to the BKE and RE modules to allow saving
using the BKE_image_render_write function. Namely, the function now
allows the use of a source image format for saving as well as the
ability to not save the render result as a render by introducing two new
default arguments. Further, for multi-layer EXR saving, the existent of
a single unnamed render layer will omit the layer name from the EXR
channel full name, and only the pass, view, and channel ID will remain.
Finally, the Render Result to Image Buffer conversion now take he number
of channels into account, instead of always assuming color channels.
The patch implements the File Output node in the Realtime Compositor
using the aforementioned mechanisms, replaces the implementation of the
CPU compositor using the same Realtime Compositor implementation, and
setup the necessary logic in the render pipeline code.
Pull Request: https://projects.blender.org/blender/blender/pulls/113982
The Realtime compositor currently relies on the GPU cache in image IDs.
That cache only supports single layer images, so multi-layer images will
be acquired without a cache, introducing significant IO bottlenecks for
the GPU compositor.
This patch ignores the image GPU cache and stores the images in the
static cache manager of the compositor. Draw data was introduced to the
image ID for proper cache invalidation, like other IDs such as masks.
The downside is that the cache will no longer be shared between EEVEE
and the compositor. But realistically, images are not typically shared
between materials and compositors.
This is just a temporary solution until we have proper GPU storage
support for image buffers.
Pull Request: https://projects.blender.org/blender/blender/pulls/115511
This gives better asserts in debug builds through use of Span, more
safety when name convention attributes happen to have different types
or domains, and simpler code in some cases. But the main reasoning is to
avoid relying on the specifics of CustomData more to allow us to replace
it in the future.
