This PR is contains the initial capture pipeline for planar probes.
It requires work to generate the correct view to capture and to include
the result during ray tracing. These will be developed in a separate PR.
This PR detects if a planar probe is active in the scene. If this is
the case the planar probe pipeline will be activated. During rendering
this is done by querying the depsgraph, during viewport drawing this
is done during sync. If an planar probe is detected and the pipeline
wasn't activated. The pipeline will be activated and the sampling
will be reset to ensure the pipeline is filled with all objects.
Per object the user can set the visibility of the object in planar
reflections.
For a reflection plane the resolution and clipping offset can be set.
EDIT: Resolution option was removed because too complex to
implement with the little time we have at the moment.
Related to #112966
Co-authored-by: Clément Foucault <foucault.clem@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/113203
Nodes that are scheduled can be executed in any order in theory. So when
there are many scheduled nodes, it can be benefitial to start evaluating
them in parallel.
Note that it is not very common that many nodes are scheduled at the
same time in typical setups because the evaluator uses a depth-first heuristic
to decide in which order to evaluate nodes. It can happen more easily in
generated node trees though.
Also, this change only has an affect in practice if none of the scheduled nodes
uses multi-threading internally, as this would also trigger the user of multiple
threads in the graph executor.
The goal here is to make it easier to use the socket declaration builder
for cases where the actual socket type is not known at compile time.
For that purpose, all the methods that are not dependent on the specific
socket type are moved to the base socket declaration builder.
A nice side effect of this is reduced templated boilerplate and that more
code can be moved out of the header.
With this patch, one is now forced to put type specific method calls before
generic method calls in a chain. For example `.default_value(...).supports_field()`
instead of `supports_field().default_value(...)`. In theory, we could keep
support for both orders but that would involve a lot of additional boilerplate
code. Enforcing this order is simple enough. Note that this limitation only
applies when chaining multiple method calls. This is still possible:
```
auto &decl = b.add_input<decl::Vector>("Value");
decl.supports_field();
decl.default_value(...);
```
Pull Request: https://projects.blender.org/blender/blender/pulls/113410
In some cases processing events was modifying them, as there can be
multiple event consumers, manipulating events isn't correct.
Even though in practice it didn't cause issues, it's straightforward
not to do this and makes logic easier to reason about.
IME editing would cast GHOST_TEventImeData to wmIMEData then read/write
an additional member that doesn't exist in GHOST_TEventImeData.
In practice it's likely struct padding prevented this from showing up
as a bug. Nevertheless it's bad practice to rely on this.
- Make GHOST_TEventImeData read-only, move the is_ime_composing boolean
into the window.
- Add static assert to ensure both structs are the same size.
- Correct code comments.
This moves the thickness from shadow map
approximation out of the lighting and shadowing
loop. Instead of using the thickness from
the shadow tracing from each individual light
before SSS evaluation, we precompute the
average thickness from all shadowed light.
This is then mixed with the nodetree thicknes.
## SSS Translucency
This add back SSS transmission support by using
the mentionned thickness computation, and applying the
transmission profile on it. This is then applied on top of a
flipped normal LTC computation.
Pull Request: https://projects.blender.org/blender/blender/pulls/113401
This allow splitting shadow and light evaluation.
This is the first step to deferred shadowing.
The evaluate closure types can be dynamically
set which mean we can have arbitrary BSDF
evaluation inside the same shader.
This also contain some refactor to `light_lib.glsl`
for more consistency and less clutter.
Note that this breaks the SSS translucency
as the shadow evaluation changes for these.
A new solution for this feature is to be found
Pull Request: https://projects.blender.org/blender/blender/pulls/113257
A copy has to compare equal to itself and have the same hash
when it is supposed to be used as a reference in a hash table
like `VectorSet`.
Just making the hash not change during a copy by hashing the
geometry component pointers instead of the geometry-set pointer
does not work because of `geometry_set_from_reference` which
assumed that changing the geometry set does not change the
hash of the reference.
For now the solution is to just not use a hash table as this
makes it easier to get corretness right. Instead, just use a
regular `Vector` to store all the references which avoids
the need for a hash function.
This can now lead to some O(n^2) behavior when adding many
references. Fortunately, this is not too common yet, as usually
one has few references but many instances that use those.
It's still something that has to be solved at some point. It's
not clear yet what approach would work best:
* Reintroduce `VectorSet` for the references and properly update
the reference positions in the hash table after the references
have changed.
* Add a separate `Map<Object*/Collection*, int>` for the
deduplication.
* Do deduplication on the call-site of `add_reference` by building
a temporary map there.
The 3D cursor's quaternion and euler storage are not always in sync.
The quaternion rotation should be retrieved by speciffic functions,
which I had previously missed.
This was only used for accessing cursor themes which only worked
with gnome and wasn't used in official releases.
Use the default theme or the theme defined by XCURSOR_THEME.
Eventually wp_cursor_shape_manager_v1 can be supported which avoids
having to access the theme.
When WITH_GHOST_SDL or WITH_HEADLESS were used, the message didn't make
much sense, especially since the features warned about weren't
necessarily enabled or even supported by the platform.
Replace with a `set_and_warn_incompatible` macro which only reports
configuration changes based on incompatible features.
Printing that a library is found every time CMake runs isn't helpful.
Restrict these messages for the first execution so messages are limited
to information developers may need to know such as features being
disabled because of incompatible configurations.
