The situation at this stage of readfile process is now sane enough, that
the regular Pose freeing code can be called, avoiding potential
memleaks.
Note that this whole 'non-Empty object with NULL obdata' case should now
be very hypothetical, since in case a linked obdata goes missing,
Blender will generate and empty place-holder for it at read time.
Tested by artificially setting all Armature objects' obdata pointer to
null in read_data code, and loading some complex production files from
Pets Project.
Keeping a mutable reference to vertex normals for the entire lifetime
of the PBVH structure makes caching the normals and sharing the cache
harder than it should be. Generally code is safer when we reduce the
number of mutable references to data.
Currently the normals are modified in two places. First is the sculpt
mesh normal recalculation. There we can just retrieve the normals from
the mesh each time. Second is the restore from an undo step. That is
unnecessary because the normals are marked for recalculation anyway.
It doesn't even make much sense to store the normals in an undo step
when we can easily recalculate them based on new positions.
This change helps with #110479. These were also the last place that
kept a mutable reference to normals. I tested undo and redo after
sculpting, and it works well for each PBVH type.
Pull Request: https://projects.blender.org/blender/blender/pulls/111470
The `lib_link` callback cannot always be fully replaced/removed, as in
some case it is also doing some validation checks, or data editing based
on the result of lib_linking internal ID pointers.
The callback has been renamed for that purpose, from `read_lib` to
`read_after_liblink`. It is now called after all ID pointers have been
fully lib-linked for the current ID, but still before the call to
`do_versions_after_linking`.
This change should not have any behavioral effect. Although in theory
the side-effect of this commit (to split lib linking itself, and the
validation/further processing code) into two completely separated steps
could have some effects, in practice none are expected, and tests did
not show any changes in behavior either..
Part of implementing #105134: Removal of readfile's lib_link & expand code.
This PR adds an initial set of nodes using the new rotation socket.
6 nodes build rotations or convert them to other formats, a 7th rotates
a vector with a rotation, and the last inverts rotations.
The design task #109965 describes the choice to use separate nodes
for the rotation construction and separation operations. In the future,
a "Switch Node" operator (#111438) will help to make working with
these separated nodes faster.
- **Axis Angle to Rotation**
- **Rotation to Axis Angle**
- **Combine Quaternion**
- **Separate Quaternion**
- **Euler to Rotation**
- **Rotation to Euler**
- **Rotate Vector**
- **Invert Rotation**
See #92967
Pull Request: https://projects.blender.org/blender/blender/pulls/109030
After undoing a visibility change, the visibility is propagated from
multires grids to mesh faces and vertices. This progress was completely
single threaded and more complicated than necessary. Simplify it
using newer C++ data structures and APIs.
The `expand` callback is 'trivial' to replace, since it is only iterating
over ID pointers and calling a callback.
The only change in behavior here is that some pointers that were not
processed previously will now be.
In practice this is not expected to have any real effect (usually
the IDs used by these pointers would have been expanded through other
usages anyway). But it may solve a few corner cases, undocumented issues
though.
Part of implementing #105134: Removal of readfile's lib_link & expand code.
There are actually cases where you do not want to access the original
ID pointers, even though the callback will not modify them. One example
is the incoming generic 'expand' readfile callback, which will replace the
dedicated one for all ID types.
Related to #105134: Removal of readfile's lib_link & expand code.
In readfile context, some ID pointers have to be ignored: typically the
'owner_id' pointers of embedded data.
Currently unused, but required for replacing `blend_read_lib`/
`blend_read_expand` by `foreach_id` (#105666).
Call functions directly in lambdas rather than passing their
arguments in a separate void * argument. This can be changed
more in the future to move callback arguments out of smaller
structs.
This commit adds a new option flag to the lib_query foreach_id code,
which will make deprecated ID pointers to be processed as well.
NOTE: Currently there is no report to the callbakcs about the fact that
it is processing a deprecated ID. This can be easily added later if it
becomes necessary.
Part of implementing #105134: Removal of readfile's lib_link & expand code.
This is in prevision of EEVEE panoramic projection support.
EEVEE-Next is planned to add support for these parameters.
Not having these parameters in Blender DNA will make Cycles
and EEVEE not share the same parameters and will be confusing
for the user.
We handle forward compatibility by still writing the parameters
as ID properties as previous cycles versions expect.
Since this change will break the API compatibility it is crucial
to make it for the 4.0 release.
Related Task #109639
Pull Request: https://projects.blender.org/blender/blender/pulls/111310
Blender's C++ data structures have configurable inline buffers used to
avoid allocation when the needed size is small. Use them in multires
code instead of an uglier C solution.
Pull Request: https://projects.blender.org/blender/blender/pulls/111070
The only acceptable case to handle internal data in 'lib_link' code is
when it depends on other IDs info. Otherwise, it should be done in
'read_data' code (and versioning if relevant).
Implements the paper [A Microfacet-based Hair Scattering
Model](https://onlinelibrary.wiley.com/doi/full/10.1111/cgf.14588) by
Weizhen Huang, Matthias B. Hullin and Johannes Hanika.
### Features:
- This is a far-field model, as opposed to the previous near-field
Principled Hair BSDF model. The hair is expected to be less noisy, but
lower roughness values takes longer to render due to numerical
integration along the hair width. The hair also appears to be flat when
viewed up-close.
- The longitudinal width of the scattering lobe differs along the
azimuth, providing a higher contrast compared to the evenly spread
scattering in the near-field Principled Hair BSDF model. For a more
detailed comparison, please refer to the original paper.
- Supports elliptical cross-sections, adding more realism as human hairs
are usually elliptical. The orientation of the cross-section is aligned
with the curve normal, which can be adjusted using geometry nodes.
Default is minimal twist. During sampling, light rays that hit outside
the hair width will continue propogating as if the material is
transparent.
- There is non-physical modulation factors for the first three
lobes (Reflection, Transmission, Secondary Reflection).
### Missing:
- A good default for cross-section orientation. There was an
attempt (9039f76928) to default the orientation to align with the curve
normal in the mathematical sense, but the stability (when animated) is
unclear and it would be a hassle to generalise to all curve types. After
the model is in main, we could experiment with the geometry nodes team
to see what works the best as a default.
Co-authored-by: Lukas Stockner <lukas.stockner@freenet.de>
Pull Request: https://projects.blender.org/blender/blender/pulls/105600
Partially reverts b14a0ee57e.
Instead of renaming the DNA field, use namespaces in C++ to resolve
name collisions (which is the reason this change was done
in the first place).
The potential data already read in `instance_weights` listbase needs to
be freed, instead of just clearing the listbase.
Also move some (very old!) versioning code out of Particle's 'lib_link'
code into proper versioning code.
Not sure how bad that was in practice, was likely harmless. But
foreach_id logic should never decide to not process an ID pointer
because its value is NULL. Callback code is expected to handle NULL
pointers appropriately.
