Currently, while calculating face corner normals, Blender retrieves
custom normal data with write access. When the the custom normals in a
single smooth corner fan don't match, they are reset to the average
value.
This behavior is very old, but it comes from when Blender didn't have a
strong idea of const correctness. Indeed, modifying custom normal data
while calculating normals isn't threadsafe, which is important because
normals are calculated for viewport drawing, for example. And in the
future, properly caching face corner normals (see #93551) will require
the ability to calculate normals on a properly const mesh.
The fix is to still use the average of custom normals in a fan, but
not write that back to the custom data array. In my testing the results
are the same. Setting custom normals still fills the same value for all
corners in a fan.
Pull Request: https://projects.blender.org/blender/blender/pulls/110478
Implements the rest of #101689, after 5e9ea9243b.
- `vdata` -> `vert_data`
- `edata` -> `edge_data`
- `pdata` -> `face_data`
- `ldata` -> `loop_data`
A deeper rename of `loop` to `corner` will be proposed as a next
step, and renaming `totvert` and `totedge` can be done separately.
Pull Request: https://projects.blender.org/blender/blender/pulls/110432
Utility functions make accessing the next and previous corner of a face
more obvious, and range based for loops make iterating over corners
or vertices in a face simpler too.
The cleanup of blenkernel last weeks , caused the house of cards to
collapse on top of bf_gpu's shader_builder, which is off by default
but used on a daily basis by the rendering team.
Given the fixes forward in #110394 ran into a ODR violation in OSL that
was hiding there for years, I don't see another way forward without
impeding the rendering teams productivity for "quite a while" as there
is no guarantee the OSL issue would be the end of it.
the only way forward appears to be back.
this reverts :
19422044eda670b53abe0f541db97cbe516e8c813e88a2f44c4e64b772f59547e7a31707fe6c5a57
The problematic commit was 07fe6c5a57
as blenkernel links most of blender, it's a bit of a link order issue
magnet. Given all these commits stack, it's near impossible to revert
just that one without spending a significant amount of time resolving
merge conflicts. 99% of that work was automated, so easier to just
revert all of them, and re-do the work, than it is to deal with the
merge conflicts.
Pull Request: https://projects.blender.org/blender/blender/pulls/110438
Implements part of #101689.
The "poly" name was chosen to distinguish the `MLoop` + `MPoly`
combination from the `MFace` struct it replaced. Those two structures
persisted together for a long time, but nowadays `MPoly` is gone, and
`MFace` is only used in some legacy code like the particle system.
To avoid unnecessarily using a different term, increase consistency
with the UI and with BMesh, and generally make code a bit easier to
read, this commit replaces the `poly` term with `poly`. Most variables
that use the term are renamed too. `Mesh.totface` and `Mesh.fdata` now
have a `_legacy` suffix to reduce confusion. In a next step, `pdata`
can be renamed to `face_data` as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/109819
Reduce indentation in two armature drawing functions, by flipping
conditions and using `continue` (instead of having the entire `for`-body
inside two nested conditions).
No functional changes.
The normals were inverted because they use
geometric normals. These are computed using
partial derivatives (`dFdx` & `dFdy`) and are
dependent on the view orientation. But the
baking views were not all captured from the
same side, which flipped sufels normals in
2 out of the 3 views.
Introduces a strategy pattern for the implementation of the various
armature drawing modes. Instead of having to `switch (arm->drawtype)`
(or `if`/`else if`/`else` chains) everywhere, one function is used to
select the appropriate `ArmatureBoneDrawStrategy` subclass.
In the future this class could be expanded even further. Currently there
are still places where there are explict checks for the draw type,
making it cumbersome to add new types. For now I feel it's already a
good enough move forward; future extensions can be done in later PRs.
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/106232
This replaces the trilinear interpolation with manually
placed samples to avoid most light leak.
Add two new parameters to bias the sampling position:
- Normal bias
- View bias
Move the irradiance smoothing parameter per grid.
Pull Request: https://projects.blender.org/blender/blender/pulls/110312
Adds the UI for layer opacity in the layer panel.
Currently layer blending rendering is not implemented, so the last layer's opacity will affect all of the layers.
Pull Request: https://projects.blender.org/blender/blender/pulls/110177
This PR adds diffuse light from environment to the scene without having an
irradiance volume in the scene.
It does this by extracting the sperical harmonics from the world probe and
store it in the irradiance brick that is reserved for world diffuse light
in the irradiance cache.
This also fixes that selecting an LookDev HDRI didn't update the diffuse
light.
**Known Issues**
- When sampling probes with lower resolution strokes are visible, leading
to flickering and instability in the spherical harmonics. This is an
issue that should be solved in a separate patch as it is already visible
in main
- When selecting a lookdev HDRI all irradiance volumes needs to be disabled
manually for the expected results (but this also disabled GI). In the future
this will be done automatically or we will add a solution to separate the
world diffuse light from the irradiance cache so we can update it on the fly.
Pull Request: https://projects.blender.org/blender/blender/pulls/110110
This change replaces a bare RenderEngine owned by a viewport
with a VeiwRender. This unlocks a possibility of accessing
RenderResult for viewport renders. Currently it is not done,
but it will be needed for an upcoming work towards unification
of the render passes handling.
Ref #108618
Pull Request: https://projects.blender.org/blender/blender/pulls/110244
The world light direction in the irradiance cache was inverted due
to misunderstanding of a code review comment. This PR fixes this
so the captured light from a direction is stored in the SH correctly.
Pull Request: https://projects.blender.org/blender/blender/pulls/110258
Shader write must be correctly specified where required for
shaders which perform direct image and buffer writing operations.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/110219
When scenes only have a world probe the world probe had several
artifacts.
- The first sample didn't update the world.
- When switching between viewports the world didn't get updates
- When rendering it ignored the resolution that was set by the user
The reason was that the ubo was only updated when the probes where
synced. This PR adds an exception to also update when there is only
the world probe.
Pull Request: https://projects.blender.org/blender/blender/pulls/110238
The LOD selection for reflection probes wasn't correct and would
select a noisier texture than required. This change will improve
the LOD selection making less noise in the rendered image.
Pull Request: https://projects.blender.org/blender/blender/pulls/110234
Introduced in recent commit (#110194) where the reflection probes are used as
ubos. Ubos have different memory requirements, but the struct
wasn't adjusted, resulting in incorrect renderings.
Pull Request: https://projects.blender.org/blender/blender/pulls/110202
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
Our intent was that uniform buffers would have been used already. The
buffer was already marked as uniform buffer, but still was attached
as an SSBO leading to incorrect bindings.
Until now we didn't detect any artifacts, but it conflicted with
cryptomatte.
Pull Request: https://projects.blender.org/blender/blender/pulls/110194
Finalize the hair & curves implementation for EEVEE Next.
- Ensure Hair particles have their own `ResourceHandle` and
`ObjectKey`, so Motion Blur works correctly.
(Note that the `ObjectHandle` and the `ObjectKey` are always created
"on the fly" instead of being stored as `DrawData`, since it's not
supported for particle system `ID`s).
- The (unused) `ObjectKey::use_particle_hair` has been replaced by an
integer `sub_key`, so multiple particle systems per object can be
supported.
- `VelocityModule::step_object_sync` now has 2 extra optional
parameters for syncing Hair particle systems.
- Update `DRW_curves_update` so it's safe to call it from "Next"
engines.
- Disable the `sampling.reset()` call from `step_object_sync`, since
`is_deform` is always true for objects with particle modifiers, and
this causes the renderer to get stuck at sample 1.
Pull Request: https://projects.blender.org/blender/blender/pulls/109833
Add support for point cloud rendering in EEVEE Next.
Update `point_cloud_sub_pass_setup` to retrieve texture based
attributes, since that's the way they're actually meant to be used.
Pull Request: https://projects.blender.org/blender/blender/pulls/109832
