`mesh_final` isn't really the final mesh but the "current" mesh. Adding the
extra word here isn't helpful. This also helps to reduce the size of the diff
in #119968 where the mesh variables have much smaller scopes.
Some nodes like the simulation input have sockets that depend on
other nodes in the tree, via dynamic declarations. The first fix here
is remapping those inter-node references before adding links and
updating declarations. The second is storing link references with
socket identifiers instead of socket pointers. This is necessary
because the new sockets aren't added to the socket map when the
node is copied. Avoiding pointer storage is also less fragile in general.
Pull Request: https://projects.blender.org/blender/blender/pulls/122013
After recent commits, the .cc file is only used for actual object data
evaluation in the depsgraph, and the header is only used for the old
DerivedMesh data structure that's still being phased out.
Mesh object evaluation is unrelated to DerivedMesh nowadays. Change the
name to something similar to the other evaluation functions called in
BKE_object_handle_data_update.
This simplifies zero-initializing `PointerRNA` in structs even when
just `RNA_types.hh` is included. Previously, one had to use
`RNA_access.h` to access it. It's also `constexpr` now which can
have small performance benefits in theory.
This adds PDF computation for eval functions as
well as using PDF for spatial denoising.
This seems to not do have any impact but at least
it seems more sounds than bsdf / pdf. Also
computing pdf is cheaper than whole bsdf.
Pull Request: https://projects.blender.org/blender/blender/pulls/121858
Grouping the legacy DerivedMesh code in the same place helps keep
the actively maintained code clearer and clarifies what we are hoping
to remove in the future.
Move to a file with the more consistent "mesh_legacy" naming, out of the
modifier evaluation code which has nothing to do with this anymore. That
file can be renamed in a separate step.
Using a non-virtual derived struct for polymorphism is error prone,
especially combined with the requirements of DNA. Instead, use a
separately allocated runtime struct as done for many other DNA structs.
In a followup commit, the remaining runtime members of `PreviewImage`
could be moved to the new runtime struct.
Pull Request: https://projects.blender.org/blender/blender/pulls/121509
The Viewport Compositor only operates on part of the render when doing
viewport rendering when in camera view. That's because the code wrongly
assumed camera offset even when doing viewport renders, which do not
exist in that case.
The function was declared in a BKE header but defined in
the sculpt_paint editors module. Move it to the slightly-less
arbitrary ED_sculpt.hh header instead.
- Don't store triangulation or triangle face indices in MeshRenderData.
This makes more automatic use of the lazy calculation and saves the
calculation of the face indices in some cases.
- Don't use the "extractor" abstraction for the triangle index buffer.
This is part of the ongoing transition described by #116901.
- Pass the "face sorted" data directly to the triangle index buffer
creation. That's the only place that needs it. This makes the
dependencies more explicit and might make better use of CPU cache.
Fix#121782
`GPencil` engine renders on the whole framebuffer.
If `Render region` is used, the result of GP rendering is scaled from whole
framebuffer down to the selected region.
The fix adds framebuffer viewport reset after rendering.
This resolves the problem for downstream consumers of
the framebuffer (e.g. `GPencil`).
The final result is somewhat similar to the `EEVEE Legacy`.
Now `EEVEE` rendering is done in the selected region, while `GPencil`
is rendered on whole viewport as before.
Pull Request: https://projects.blender.org/blender/blender/pulls/121979
BLF_str_offset_from_cursor_position is being called with a str_len of
INT_MAX, so max buffer size instead of string length. This works fine
right now but will not when this gets more complex. For example if we
need to call functions like BLI_str_cursor_step_next_utf8, which
assumes that str_len is the actual end of the string.
Pull Request: https://projects.blender.org/blender/blender/pulls/121966
Jittered Soft Shadows support.
Improves soft shadow quality at the cost of re-rendering shadow maps every sample.
Disabled by default in the viewport unless enabled in the Scene settings.
| Tracing-only | Jitter-only | Jitter+Over-blur |
| --- | --- | --- |
|  |  |  |
Tracing-only is the method used by default in EEVEE-Next.
Jitter-only is the method used by EEVEE-Legacy Soft Shadows.
Jitter+Over-blur combines both.
Co-authored by Miguel Pozo @pragma37 (initial patch #119753)
Pull Request: https://projects.blender.org/blender/blender/pulls/121836
