The file is easier to read and change when less context is needed at
each step. Also extract some complex-looking flag testing into a
separate function, and move some constant checks out of loops.
When blender is not focused and a selection is executed
with the mouse, since there is no conversion from `wl_fixed` to `int`,
the bounds of the selection can cause the selection box to be too large,
causing `draw_select_framebuffer_depth_only_setup` to fail when create
`g_select_buffer.texture_depth`.
Ref !109834
The Alembic importer can optionnaly interpolate vertex and matrix data.
To detect if two samples can be interpolated `get_weight_and_index`
needs to be called which output the interpolation weight and the indices
for the floor and ceil samples separately. Either the weight or the
indices could be used to determine if interpolation was needed.
This adds a `SampleInterpolationSettings` structure to hold the weight
and indices together so we don't need to manage multiple local
variables, and replaces `get_weight_and_index` with
`get_sample_interpolation_settings` which returns either a
`SampleInterpolationSettings` or nothing if no interpolation is
necessary.
This also modifies `AbcMeshData` to have an optional
`SampleInterpolationSettings` and removes members used for interpolation
from `CDStreamConfig`, which simplifies the latter structure as well as
the check in `read_mverts` to verify if interpolation is needed.
`get_config` also no longer needs a parameter for setting the now removed
`use_vertex_interpolation` member from `CDStreamConfig`. This was only
used for Mesh vertex interpolation despite also being set in the points
reader (which does not yet support any interpolation).
No functional changes.
Pull Request: #109155
* Renamed BKE_pbvh_raycast_project_ray_root to
BKE_pbvh_clip_ray_ortho for greater
clarity.
* BKE_pbvh_clip_ray_ortho no longer strictly clips
within the input ray interval. This is not necassary
for orthographic views and was too prone to floating
point error. The function is only called to clip
brush rays for orthographic views so this is acceptable.
Navigation operations, like those of the trackpad, are not modal and
therefore are confirmed on each call.
To prevent the transform operations from being updated in this case,
add a fake navigation flag.
The removal of this flag is postponed to the next call.
`list_assert_duplicates` validates a list that should contain no
duplicates, contains no duplicates, with scope keywords now being
allowed in `INC` sections, there is the situation where multiple
include paths can have the same scope set on them causing
`list_assert_duplicates` to error out.
To remedy this we remove the scope keywords from the list first,
before running the test.
So that there is some lighting when there are no lights in the scene,
and black when there are lights. This matches the behavior of other
Hydra renderers.
Ref #96731
* Use pi factor to convert between radiant flux and intensity
* Mark lights as normalized on export
* Add spot light export support
* Add treatAsPoint support for import and export
* Empirically match normalized distant light
* Fix wrong unnormalized point/sphere/disk light unit in Cycles
Overall it should be much closer now for all light types. Point and distant
light units are inconsistent between renderers, so not possible to match
everything there.
Ref #109404
Pull Request: https://projects.blender.org/blender/blender/pulls/109795
Minor tweaks to the API to support drag & drop management in the layer tree UI.
These changes were needed for #109826:
- Add `TreeNode.parent_group()`
- Add `LayerGroup.as_node()`
- Use `TreeNode` instead of `Layer` whenever a link is needed to link or unlink a layer.
Pull Request: https://projects.blender.org/blender/blender/pulls/109824
This fixes the issue described in https://projects.blender.org/blender/blender/issues/108957.
Instead of modeling distant lights like a disk light at infinity, it models them as cones. This way, the radiance is constant across the entire range of directions that it covers.
For smaller angles, the difference is very subtle, but for very large angles it becomes obvious (here's the file from #108957, the angle is 179°):
| Old | New |
| - | - |
| ![old_bigsun.png](/attachments/4ef8e7a7-1a29-4bdf-a74c-3cfa103bf1e7) | ![new_bigsun.png](/attachments/d53c7749-2672-40b6-9048-ccf2fffceeb7) |
One notable detail is the sampling method: Using `sample_uniform_cone` can increase noise, since the sampling method no longer preserves the stratification of the samples. This is visible in the "light tree multi distant" test scene.
Turns out we can do better, and after a bit of testing I found a way to adapt the concentric Shirley mapping to uniform cone sampling. I hope the comment explains the logic behind it reasonably well.
Here's the result, note that even the noise distribution is the same when using the new sampling:
| Method | Old | New, basic sampling | New, concentric sampling |
| - | - |- | - |
| Image | ![old.png](/attachments/b3258a70-f015-4065-a774-193974cce439) | ![new_basic.png](/attachments/a9008576-0af6-4152-a687-c800fd958bbd) | ![new_concentric.png](/attachments/769b6c43-34bc-434e-a4fd-ce69addd1ba5) |
| Render time (at higher spp)| 9.03sec | 8.79sec | 8.96sec |
I'm not sure if I got the `light->normalized` handling right, since I don't really know what the expectation from Hydra is here.
Co-authored-by: Weizhen Huang <weizhen@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/108996
The spotlight is now treated as a sphere instead of a view-aligned disk.
The implementation remains almost identical to that of a point light,
except for the spotlight attenuation and spot blend. There is no
attenuation inside the sphere. Ref #108505
Other changes include:
## Sampling
Instead of sampling the disk area, the new implementation samples either
the cone of the visible portion on the sphere or the spread cone, based
on which cone has a smaller solid angle. This reduces noise when the
spotlight has a large radius and a small spread angle.
| Before | After |
| -- | -- |
|![spot_size_before.png](/attachments/04ea864a-6bf9-40fe-b11b-61c838ae70cf)|![spot_size_after.png](/attachments/7077eaf9-b7a8-41b1-a8b6-aabf1eadb4f4)
## Texture
Spot light can now project texture using UV coordinates.
<video src="/attachments/6db989d2-7a3c-4b41-9340-f5690d48c4fb"
title="spot_light_texture.mp4" controls></video>
## Normalization
Previously, the normalization factor for the spotlight was \(\pi r^2\),
the area of a disk. This factor has been adjusted to \(4\pi r^2\) to
account for the surface area of a sphere. This change also affects point
light since they share the same kernel type.
## Versioning
Some pipeline uses the `Normal` socket of the Texture Coordinate node for
projection, because `ls->Ng` was set to the incoming direction at the
current shading point. Now that `ls->Ng` corresponds to the normal
direction of a point on the sphere (except when the radius is zero),
we replace these nodes with a combination of the Geometry shader node
and the Vector Transform node, which gives the same result as before.
![versioning.png](/attachments/5bbfcacc-26c5-4f7f-8360-c42bcd851f68)
Example file see https://archive.blender.org/developer/T93676
Pull Request: https://projects.blender.org/blender/blender/pulls/109329
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
Split off from [#106952: Animation: Butterworth Smoothing filter](https://projects.blender.org/blender/blender/pulls/106952)
This patch allows the slider to take a different string than just "%",
the use case is on #106952 where we want to display "Hz" instead.
Additionally the slider got the ability to set modes, which determine
how the factor number is displayed.
`SLIDER_MODE_PERCENT` means it will multiply by 100 and display as whole numbers
`SLIDER_MODE_FLOAT` means it will display just floats with one digit after the comma
Additionally to that, because the slider range is now arbitrary and potentially deals with
large numbers, the mouse distance needed to travel from min to max has been normalized
to the range.
Pull Request: https://projects.blender.org/blender/blender/pulls/109768
Locked `FCurves` had 2 visual issues
* the dashing is so short it just creates visual noise
* keyframes are drawn in white looking like they are selected
This PR changes this by
* Increasing the dash width
* Keyframes are drawn in black on locked curves
* To indicate that they can't be selected, draw them in a X shape
* To further reduce visual noise, locked curves no longer draw thicker when selected
This is part of the changes discussed in this design task #104867
Pull Request: https://projects.blender.org/blender/blender/pulls/106052
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
ebe8f8ce719729eef402 and 5669c5a61b2f049ec1b5 added multithreading but
a typo meant it wasn't used for half of the process. Fixing that gives a
30% improvement in my tests, from about 80 to 60 ms converting a grid.