The old Sculpt initialization code did double duty
as versioning code. This commit implements proper
versioning logic in versioning_400.cc; the existence
of the default fields are checked in DNA and if they
don't exist they're initialized. This is similar to
how the old code checked if the fields were zero.
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
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 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.
Selecting a rigid body world collection is supposed to set up rigid
bodies for all of its mesh members (if they are not rigid bodies
already), expected result would be just the same as if `Object` > `Rigid
Body` > `Add ...` was used.
Doing it via just the world collection had the following issues though:
- calculating mass would crash on such a freshly created rigid body
objects (be1b32e4e4 falsely assumed `ob->rigidbody_object` is always
present on evaluated objects -- without tagging for depsgraph updates
this is not the case though)
- rigid body simulation would not work even on these freshly created
rigid body objects
Now tag bmain relations and object transforms for update to make both of
these work (following code in `BKE_rigidbody_add_object` that is used
when adding these through `Object` > `Rigid Body` > `Add ...`)
Pull Request: https://projects.blender.org/blender/blender/pulls/109961
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.
The spotlight is now treated as a sphere instead of a view-aligned disk.
The implementation remains almost identical to that of a point light,
except for the spotlight attenuation and spot blend. There is no
attenuation inside the sphere. Ref #108505
Other changes include:
## Sampling
Instead of sampling the disk area, the new implementation samples either
the cone of the visible portion on the sphere or the spread cone, based
on which cone has a smaller solid angle. This reduces noise when the
spotlight has a large radius and a small spread angle.
| Before | After |
| -- | -- |
||
## Texture
Spot light can now project texture using UV coordinates.
<video src="/attachments/6db989d2-7a3c-4b41-9340-f5690d48c4fb"
title="spot_light_texture.mp4" controls></video>
## Normalization
Previously, the normalization factor for the spotlight was \(\pi r^2\),
the area of a disk. This factor has been adjusted to \(4\pi r^2\) to
account for the surface area of a sphere. This change also affects point
light since they share the same kernel type.
## Versioning
Some pipeline uses the `Normal` socket of the Texture Coordinate node for
projection, because `ls->Ng` was set to the incoming direction at the
current shading point. Now that `ls->Ng` corresponds to the normal
direction of a point on the sphere (except when the radius is zero),
we replace these nodes with a combination of the Geometry shader node
and the Vector Transform node, which gives the same result as before.
Example file see https://archive.blender.org/developer/T93676
Pull Request: https://projects.blender.org/blender/blender/pulls/109329
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
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
String search & replace is a higher level function (unlike BLI_string.h)
which handlers lower level replacements for printing and string copying.
Also use BLI_string_* prefix (matching other utilities).
This makes it possible to use BLI_string in Blender's internal utilities
without depending on DynStr, MemArena... etc.
`Project Individual Elements` was never supported for `Vert Slide` and
`Edge Slide`, however, albeit erroneously, this option still affected
those operations.
In Blender 3.6 this situation of `Project Individual Elements`
affecting the result, has been "fixed". But users still preferred the
old behavior.
Therefore, instead of falling back to `Snap To Face`, support
`Project Individual Elements` for `Vert Slide` and `Edge Slide`.
This is more like how it worked previously.
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
Replace `typedef struct X {} X;` with `struct X {};`
In some cases the first and last name didn't match although this
is rarely useful, even a typo in some cases, e.g. TrachPathPoint.
Also rename:
- `SCE_SNAP_MODE_FACE_NEAREST` to `SCE_SNAP_INDIVIDUAL_NEAREST`
- `SCE_SNAP_MODE_FACE_RAYCAST` to `SCE_SNAP_INDIVIDUAL_PROJECT`
And arrange the enums in numerical order.
By removing the extra complete check/remapping of ID pointers in undo
case, ebb5643e59 merely revealed how broken the 'undo_preserve' code of
Scene was.
It cumulated a flock of issues, all more or less related to ID pointers:
* 'source of truth' should be the _old_ data (toolsettings), not the new
one, since this is the one kept at the end of the process;
* In some cases, some paint data may exist in one, but not the other
of the two 'old' and 'new' toolsettings data.
* Since this data is preserved to its latest version accross undos, its
ID pointers can become completely unrelated to these read from the
undo memfile, _even when the Scene itself is detected as unchanged_!
This implies that:
+ undo_preserve code has to be called even when there is no liblinking
(when the ID is detected as unchanged and re-used 'as-is').
+ Using existing ID addresses to find/validate an ID pointer in
undo_preserve process is like playing Russian roulette - invalid
memory access and crash is guaranteed at some point or another.
Use `session_uuid` value instead to ensure a valid ID pointer is set
(or null in case none can be found).
NOTE: while these issues also exist in previous releases (including both
latest LTSs), they were hidden by the code later in `setup_app_data`,
preventing any crash to happen. So backporting this fix would be far too
risky for a very minimal benefit imho.
In this specific code path (recursive reading inside .blend files
containing assets), reading datablocks marked as asset would move
ownership over the asset metadata without indicating that in the source
that owned it previously. This would cause a double free attempt.
