Also see #103343.
Couldn't move two files yet:
* `softbody.c`: The corresponding regression test fails. It seems like the
conversion to C++ changes floating point accuracy, but it's not clear where that happens exactly.
* `writeffmpeg.c`: Is a bit more complex to convert because of the static array in `av_err2str`.
Pull Request: https://projects.blender.org/blender/blender/pulls/110182
This turns the embedded group into a pointer.
Note: Older files will not load the grease pencil v3 object properly after this.
The objects will not have any layers in them.
Pull Request: https://projects.blender.org/blender/blender/pulls/110007
Move the node previews to the overlay region, atop each node.
It allows nodes to keep the same size when the preview is toggled,
which is more convenient for large nodes and large nodetrees.
The preview has to be drawn from `node_draw_extra_info_panel`
because there could be overlapping between info text and the preview.
When the node is out of the view, it also has to make sure that the
preview is also out of the view before exiting the draw function.
Pull Request: https://projects.blender.org/blender/blender/pulls/108001
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 moves the remaining `.c` files in the following `editors` folders to C++:
`physics`, `screen`, `sound`, `space_buttons`, `space_file`, `space_graph` and `space_image`.
One exception is `fsmenu.c` which has platform specific issues on macos and
windows. E.g. the `Carbon/Carbon.h` include also declares a `Collection` type that collides
with ours.
Also see #103343.
Pull Request: https://projects.blender.org/blender/blender/pulls/109918
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.
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
Clay strips was using it's own brush local matrix,
which wasn't quite compatible with texture matrices.
This could lead to brush textures not lining up with
the stroke dabs.
There was also a bug where the stroke was starting
20 pixels into the stroke, which is much higher than
necassary to derive the initial rake angle.
Notes:
* The clay strips brush now uses SCULPT_cube_tip_init
to calculate the local brush matrix.
* SCULPT_cube_tip_init now accepts custom brush location
and radius arguments.
* The mouse sample preroll used to calculate initial brush
rotation angle is now smaller than the update interval.
* Clay strips now supports tip_scale_x, which has also
been added to DNA defaults.
`use_ambient_occlusion` is a legacy property and not
connected to anything. The clip editor still write
to it for enabling the ambient occlusion renderpass.
This change will remove the legaccy option and
won't enable ambient occlusion pass anymore due
to visual and performance impact.
Pull Request: https://projects.blender.org/blender/blender/pulls/109783
Minor tweaks to the API to support drag & drop management in the layer tree UI.
These changes were needed for #109826:
- Add `TreeNode.parent_group()`
- Add `LayerGroup.as_node()`
- Use `TreeNode` instead of `Layer` whenever a link is needed to link or unlink a layer.
Pull Request: https://projects.blender.org/blender/blender/pulls/109824
All probes (including the world background probe) are stored in a single texture. Each probe
can be of any resolution as long as it is a power of 2 and not larger than 2048. So valid options
are (2048x2048, 1024x1024, 512x512, etc).
Each probe can be stored in their own resolution and can be set by the user.
> NOTE: Eventually we would like to add automatic resolution selection.
The probes are packed in an 2d texture array with the dimension of 2048*2048. The number of
layers depends on the actual needed layers. If more layers are needed the texture will be recreated.
This can happen when a new reflection probe is added, or an existing reflection probe is made visible
to the scene or its resolution is changed.
### Octahedral mapping
Probes are rendered into a cubemap. To reduce memory needs and improve sampling performance the cubemap
is stored in octahedral mapping space. This is done in `eevee_reflection_probe_remap_comp.glsl`.
The regular octahedral mapping has been extended to fix leakages at the edges of the texture
and to be able to be used on an atlas texture and by sampling the texture once.
To reduce sampling cost and improve the quality we add an border around the
octahedral map and extend the octahedral coordinates. This also allows us to
generate lower resolution mipmaps of the atlas texture using 2x2 box filtering
from a higher resolution.
### Subdivisions and areas
Probes data are stored besides the texture. The data is used to find out where the probe is stored
in the texture. It is also used to find free space to store new probes.
This approach ensures that we can be flexible at storing probes with different
resolutions on the same layer. Lets see an example how that works
Code-wise this is implemented by `ProbeLocationFinder`. ProbeLocationFinder can view a texture in a
given subdivision level and mark areas that are covered by probes. When finding a free spot it returns
the first empty area.
**Notes**
* Currently the cubemap is rendered with a fixed resolution and mipmaps are generated in order to
increase the quality of the atlas. Eventually we should use dynamic resolution and no mipmaps.
This will be done as part of the light probe baking change.
Pull Request: https://projects.blender.org/blender/blender/pulls/109688
This introduces an alias target `bf::intern::atomic` for
`bf_intern_atomic`. This has the following benefits:
- Any target name with `::` in it will be recognized as an actual
target by cmake, rather than a library name it may not know about.
and will be validated by cmake to exist. Which means if you make
a typo in the LIB section, CMake will error out telling you it
doesn't know about this specific target rather than passing it on
to the build system, where you'll either get build or linker errors
because of said typo.
- Given there is quite a cleanup still to do in the build system,
it won't always be obvious which targets have been updated to
modern targets and which still need to be done. Having a namespaced
target name is a good indicator there.
Pull Request: https://projects.blender.org/blender/blender/pulls/109784
This moves the following `editors/*` directories to C++:
- animation, armature, lattice, mesh, metaball, object, scene.
Much of the changes in this commit (inserting casts in particular)
was automated. Further changes like switching to functional style
casts can be done separately by existing automated scripts.
See #103343
Pull Request: https://projects.blender.org/blender/blender/pulls/109715
It was only used by OpenEXR and Iris images, and saving the Z Buffer
in those formats was disabled by default. This option comes from the
times prior to the addition of the Multilayer EXR.
It also worth noting that it was not possible to save Iris with Depth
pass from Blender as internally it is called IRIZ format and it was
not exposed. But even after exposing this format option something still
was missing as saving and loading ITIZ did not show up the Depth pass.
The reason of removal is to make it a more clear match of the ImBuf
with a render pass, and use it instead of a custom type in the render
result and render pass API. This will simplify the API and also avoid
stealing buffers and making shallow copies when showing the render
result.
For the cases when Depth is needed a Multilayer EXR is to be used,
as most likely more than just the Depth will be needed.
On a user level this change:
- Removes the "Z Buffer" option from the interface.
- It preserves existing sockets in compositor nodes, but it will
output black image. Also changing the image data-block will
remove the socket unless a Multilayer EXR with Depth pass image
is selected.
- Removes "Depth" socket of the Viewer and Composite nodes.
Ref #108618
Pull Request: https://projects.blender.org/blender/blender/pulls/109687
Adds a new function to insert a frame with a duration on a layer.
Also adds tests for the edge cases.
This introduces the concept of a `null-frame`.
It can be created with `GreasePencilFrame::null()` and checked for with
`is_null()`.
The purpose of a `null` frame is to indicate the end of whatever frame
comes before it. This way, the frames map does not need to store
the duration of frames. The duration is always implied by the distance
to the next frame.
When using ASAN without WITH_COMPILER_ASAN, for example when enabling it
in Xcode, some symbols would be missing from makesdna. Instead just always
include them, there's no harm in it.
Also deduplicate some code.
Pull Request: https://projects.blender.org/blender/blender/pulls/109666
Renames `OB_MODE_EDIT_GPENCIL`, `OB_MODE_PAINT_GPENCIL`, `OB_MODE_SCULPT_GPENCIL`, `OB_MODE_WEIGHT_GPENCIL`, `OB_MODE_VERTEX_GPENCIL, and the context modes` to `*_LEGACY`.
Pull Request: https://projects.blender.org/blender/blender/pulls/109648
No user visible changes expected. The feature is not exposed yet.
For the asset shelf (#102879), design is to use a paginated scrolling
style. That means, that any scrolling will always snap to a multiple of
the page size (the size used when pressing the Page Up/Down keys).
Together with strict region size snapping (implemented in the asset
shelf patch, #104831), this gives a clean scrolling experience where
partially visible rows are avoided (impossible even).
Introduces:
- `View2D.flag` value `V2D_SNAP_TO_PAGESIZE_Y`, which will cause any
scrolling to only use multiples of the page size.
- A custom page size via `View2D.page_size_y` for when the full region
size is not the appropriate page size value.
- API function `UI_view2d_offset_y_snap_to_closest_page()` to enforce
the snapping from outside View2D. The asset shelf uses this to keep
strict scrolling over DPI changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/109154
Also see #103343.
The main complication here was that the `long` type was poisoned in GCC, but it's used by
some included C++ headers. I removed the compile-dependent poison and added a new
check for `long` and `ulong` so that they still can't be used in DNA.
Pull Request: https://projects.blender.org/blender/blender/pulls/109617
The simulation state used by simulation nodes is owned by the modifier. Since a
geometry nodes setup can contain an arbitrary number of simulations, the modifier
has a mapping from `SimulationZoneID` to `SimulationZoneState`. This patch changes
what is used as `SimulationZoneID`.
Previously, the `SimulationZoneID` contained a list of `bNode::identifier` that described
the path from the root node tree to the simulation output node. This works ok in many
cases, but also has a significant problem: The `SimulationZoneID` changes when moving
the simulation zone into or out of a node group. This implies that any of these operations
loses the mapping from zone to simulation state, invalidating the cache or even baked data.
The goal of this patch is to introduce a single-integer ID that identifies a (nested) simulation
zone and is stable even when grouping and un-grouping. The ID should be stable even if the
node group containing the (nested) simulation zone is in a separate linked .blend file and
that linked file is changed.
In the future, the same kind of ID can be used to store e.g. checkpoint/baked/frozen data
in the modifier.
To achieve the described goal, node trees can now store an arbitrary number of nested node
references (an array of `bNestedNodeRef`). Each nested node reference has an ID that is
unique within the current node tree. The node tree does not store the entire path to the
nested node. Instead it only know which group node the nested node is in, and what the
nested node ID of the node is within that group. Grouping and un-grouping operations
have to update the nested node references to keep the IDs stable. Importantly though,
these operations only have to care about the two node groups that are affected. IDs in
higher level node groups remain unchanged by design.
A consequence of this design is that every `bNodeTree` now has a `bNestedNodeRef`
for every (nested) simulation zone. Two instances of the same simulation zone (because
a node group is reused) are referenced by two separate `bNestedNodeRef`. This is
important to keep in mind, because it also means that this solution doesn't scale well if
we wanted to use it to keep stable references to *all* nested nodes. I can't think of a
solution that fulfills the described requirements but scales better with more nodes. For
that reason, this solution should only be used when we want to store data for each
referenced nested node at the top level (like we do for simulations).
This is not a replacement for `ViewerPath` which can store a path to data in a node tree
without changing the node tree. Also `ViewerPath` can contain information like the loop
iteration that should be viewed (#109164). `bNestedNodeRef` can't differentiate between
different iterations of a loop. This also means that simulations can't be used inside of a
loop (loops inside of a simulation work fine though).
When baking, the new stable ID is now written to disk, which means that baked data is
not invalidated by grouping/un-grouping operations. Backward compatibility for baked
data is provided, but only works as long as the simulation zone has not been moved to
a different node group yet. Forward compatibility for the baked data is not provided
(so older versions can't load the data baked with a newer version of Blender).
Pull Request: https://projects.blender.org/blender/blender/pulls/109444
This PR adds a new operator to run a node group on object geometry.
Only curves sculpt mode is supported for now, to simplify the design.
A new geometry node editor context to edit operator groups is also
added. This allows changing any node group, rather than only node
groups that are part of the active modifier context.
3D viewport menus are added with any geometry node group
asset in a catalog that contains the `Operator` tag. Currently Blender
must be restarted to refresh the list of available operators.
This is only the first phase of the node group operator feature.
Many more features will be added in next steps.
See #101778
Pull Request: https://projects.blender.org/blender/blender/pulls/108947
Similar to 5f16e24cc9, this adds support for edit mode
to the point cloud object type, which is currently hidden behind an
experimental option. No interaction is possible yet, for now this
can be used as a testing for a node-group-operator-only mode.
`CD_HAIRLENGTH` is not really a custom data type, it was just used to
specify the hair particle "length" attribute to pass it to EEVEE and
material preview. Because of the "typemap" array in `CustomData`,
it's better not to have this unnecessary type. Instead, use the same
mechanism used to request the active color attribute.
Pull Request: https://projects.blender.org/blender/blender/pulls/109449
