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
This PR introduces baking reflective light from light probes. Light probes
are baked on the fly when the light probe data has changed. It doesn't update
directly when other scene data is changed in the viewport.
When doing image rendering the light probes are updated on each frame.
Currently the world probe and closest reflection probe are composited
together in shader. This allows different resolutions. We expect that we
eventually composite it before usage. This would improve the performance.
Unclear if we would support both compositing options eventually.
Pull Request: https://projects.blender.org/blender/blender/pulls/109909
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`.
We need setters and getters for these two very commonly accessed attributes of grease pencil.
The code is based on the implementation of `CurvesGeometry::positions()` and `CurvesGeometry::positions_for_write()`.
Co-authored-by: Falk David <falk@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/109733
Users were reporting offset issues when the retopology overlay
was disabled. The reason those issues were happening is because of
`vs_offset = min(vs_offset, vs_z * -0.5);`.
That line is necessary for proper functioning of the retopology
overlay, but causes issues at lower offset values (such as zero, when
the retopology overlay is disabled).
Fixes#109640
Pull Request: https://projects.blender.org/blender/blender/pulls/109657
Doing so avoids having duplicated logic for working with pixel
data which is being passed throughout the render pipeline.
Notable changes:
- ImBug can now store GPU texture.
This is not very finished part of the API, which will be
worked further to support tiling for very-high-res images.
- Implicit sharing is removed from the image buffer, as it is
no longer needed.
There should be no functional changes on user level with this
change.
Ref #108618
Pull Request: https://projects.blender.org/blender/blender/pulls/109788
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
When switching shading between material preview and solid modes, the
world reflective light could become uninitialized. The reason was that
the world was only updated when they actually changed. When switching
it might not be the case that the world changed and the world probe
wasn't uploaded to the texture.
This fix will reduce the locations where this information was stored
(removing the `do_world_update` attribute in `ReflectionProbeModule`).
It also doesn't reset the `do_render` flag during syncing, but post-
pone it to the actual drawing.
Pull Request: https://projects.blender.org/blender/blender/pulls/109901
When using many reflection probes with different subdivisions
it can happen that the reflection probe uses texture space that
is already been allocated for another probe.
The cause for that is that negative shift operations result into
undefined behavior, this was fixed previously by clamping the
number of bit shifts to perform, but ignoring to shift into the
other direction
This change also includes `ProbeLocationFinder.print_debug`
for future debugging.
Pull Request: https://projects.blender.org/blender/blender/pulls/109823
This PR fixes a compiler issue when using NVIDIA. It was introduced
when adding the reflection probes. NVIDIA compiler doesn't like
to access elements in a bound resource and pass it directly
as a parameter. It should first be added as a local variable.
Pull Request: https://projects.blender.org/blender/blender/pulls/109891
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
Instead of keeping track of a local array of positions in the modifier
stack itself, use the existing edit mode SoA "edit cache" which already
contains a contiguous array of positions. Combined with positions as a
generic attribute, this means the state is contained just in the mesh
(and the geometry set) making the code much easier to follow.
To do this we make more use of the mesh wrapper system, where we can
pass a `Mesh` that's actually stored with a `BMesh` and the extra
cached array of positions. This also resolves some confusion-- it was
weird to have the mesh wrapper system for this purpose but not use it.
Since we always created a wrapped mesh in edit mode, there's no need
for `MOD_deform_mesh_eval_get` at all anymore. That function was quite
confusing with "eval" in its name when it really retrieved the original
mesh.
Many deform modifiers had placeholder edit mode evaluation functions.
Since these didn't do anything and since the priority is node-based
deformation now, I removed these. The case is documented more in the
modifier type struct callbacks.
Pull Request: https://projects.blender.org/blender/blender/pulls/108637
Split much of BKE_pbvh.h into BKE_pbvh_api.hh.
BKE_pbvh.h is included by BKE_paint.h, which in
turn is included by large amounts of code including
RNA.
This makes it extremely difficult to change
or clean up the PBVH API, since each modification
of BKE_pbvh.h can take 20-30 minutes to compile,
even on a quad-core system with an SSD. This
commit fixes that by moving most of BKE_pbvh.h
into another file and just having the core,
external-facing interfaces in BKE_pbvh.h.
This utility counts the number of occurrences of each index in an array.
This is used for building mesh topology maps offsets, or for counting
the number of connected elements. Some users are geometry nodes,
the subdivision draw cache, and mesh to curve conversion.
See #109628
