* Move missing script files inside a panel.
* Call it Missing Add-ons.
* Add an explicit "X" to dismiss (instead of the checkbox).
Note: The panel is collapsed by default.
Co-authored by Pablo Vazquez.
Pull Request: https://projects.blender.org/blender/blender/pulls/122721
The `nor` vertex buffer wasn't large enough for the indices in the lines
index buffer. This is undefined behavior at best AFAIK. On some drivers
it caused crashes when there was only loose geometry.
This commit makes the VBO large enough for all indices, filling the loose
geometry normals with (0,0,0,0), which the overlay wireframe shader
already checks for.
Pull Request: https://projects.blender.org/blender/blender/pulls/122720
Now it's possible to use link-drag-search with the extend socket of the Capture Attribute node again.
Implementation wise, the main unexpected things I noticed are that
`update_and_connect_available_socket` did not update the node declaration and currently uses
socket names instead of identifiers. This works fine right now, but should eventually be changed
to use identifiers (separate from this commit though).
Pull Request: https://projects.blender.org/blender/blender/pulls/122716
Add unit tests for the two main keyframing API functions: `insert_key_rna()` and `insert_keyframe()`.
The tests are not exhaustive of every possible permutation of parameters, but the tests do try to hit each of the behaviors in at least one permutation. In the future tests should also be added for the lower-level keying functions and behaviors as well, but I'm leaving that as future work since we aren't changing/refactoring those functions right now.
Pull Request: https://projects.blender.org/blender/blender/pulls/122553
The "Spacing" option had a few issues:
* If the radius unit of the brush was "Scene", the spacing wasn't correctly
calculated based on the size of the brush in view space.
* The maximum spacing could get very small, leading to extremly dense
strokes.
This makes sure we correctly calculate the brush radius in pixels and
then clamps the spacing so we don't subdivide too much.
It's hardcoded to a maximum of 4 points per pixel, which should be plenty.
This change fixes:
- Constant folder uses rect of size INT_MIN .. INT_MAX, which overflows integer
when calculating size.
- Calculation of an offset inside of input can lead to integer overflow for big
resolutions.
- texture_bilinear_extend() and texture_nearest_extend() do not seem to handle
single element buffers correctly.
- Kuwahara has division of zero when the input size is 0.
Pull Request: https://projects.blender.org/blender/blender/pulls/122674
This adds support for transform matrices in the accumulate field node. This is quite
useful to evaluate chains of parent matrices (although branching is not easily possible
with this approach).
The main tricky thing here is that matrices are generally accumulated using
multiplication and the order of multiplication matters. For other data types we
currently always use addition. I don't have use cases for other ways to accumulate
matrices right now, so maybe it's fine not to add additional options here for now.
It should be fairly straight forward to version this to support more accumulation
modes in the future. Additionally, I hope we get a more general solution for custom
accumulations at some point.
Pull Request: https://projects.blender.org/blender/blender/pulls/121326
Split `bpy.types.LightProbe` into specialized subclasses.
- Rename all grid_* to remove the prefix in the RNA and limit access to
volume probe.
- Parallax and other sphere probe only properties should be limited to
sphere probe.
- `visibility` properties are deprecated (to be removed in a future
Blender version)
Ref #113976
Pull Request: https://projects.blender.org/blender/blender/pulls/122353
On a M3 MacBook Pro, this change increases the benchmark score by 8% (with classroom seeing a path-tracing speedup of 15%).
The integrator state is currently store using struct-of-arrays, with one array per field. Such fine grained separation can result in poor GPU cache utilisation in cases where multiple fields of the same parent struct are accessed together. This PR changes the layout of the `ray`, `isect`, `subsurface`, and `shadow_ray` structs so that the data is interleaved (per parent struct) instead of separate. To try and keep this change localised, I encapsulated the layout change by extending the integrator state access macros, however maybe we want to do this more explicitly? (e.g. by updating every bit of code that accesses these parts of the state). Feedback welcome.
Pull Request: https://projects.blender.org/blender/blender/pulls/122015
- `bpy.types.Material.blend_method` aliases `bpy.types.Material.surface_render_method`.
'Opaque' and 'Alpha Clip' maps to deferred.
- Renamed `show_transparent_back` to `use_transparency_overlap`
- Renamed `use_screen_refraction` to `use_raytrace_refraction`
- Deprecate `use_sss_translucency` and `use_sss_translucency`
Related to: #113976
**NOTE**
The light probe changes will be done in a different patch.
Both patches should land just before we remove EEVEE Legacy
from the code-base.
Pull Request: https://projects.blender.org/blender/blender/pulls/122297
OpenimageIO v2.5.11.0
OpenEXR 3.2.4
LibTIFF 4.6.0
This updates OIIO and resolves some CVE's in openexr and libtiff.
some patches that were merged upstream have been removed
Pull Request: https://projects.blender.org/blender/blender/pulls/121823
This is an oversight of #122543, for which benchmarking was done in
the headless mode.
The solution is to tweak policy a little bit, and keep refresh intervals
low for the first 10 seconds of render, after which increase updates to
every 15 seconds. Doing so allows:
- Have quick cancel of complex files when the error is noticed during
the first few samples.
- Have more predictable cancel time after long render.
- Mitigate the performance regression.
This does not fully solve the regression, but it makes it much more
manageable. There are some compromises to be done from the performance
for the UI renders. The interactivity is also not as fantastic, but it
could be solved later by introducing some "Instant Cancel" operations
which would be able to also stop render in the middle of a sample.
Performance measured with the Spring file (path tracing time in seconds):
Samples: 300 1024 2048
Base (prior to #122543): 29.1 85.4 174.1
This patch: 37.0 95.7 180.2
This is measured on M2 Ultra GPU render.
The penalty is close to a constant time (the time within which a more
interactive cancel is possible.
Pull Request: https://projects.blender.org/blender/blender/pulls/122658
This handles the transition to EEVEE-Next (now EEVEE).
This removes some things that make no sense to keep
even for compatibility.
- Scene.eevee.light_cache_data
- Scene Light cache operators
- Scene Light cache RNA properties
The remaining legacy properties will be removed later
on to avoid python API breakage.
We keep the identifier of EEVEE-Next as `BLENDER_EEVEE_NEXT`
to avoid addons being incorrectly silently made compatible
with the EEVEE-Next where the Python API is different.
This renaming should be done in 5.0 release.
Thank you EEVEE-Legacy, you served us well.
Pull Request: https://projects.blender.org/blender/blender/pulls/122433
We were passing a sentinel maximum enum value to `ENUM_OPERATOR`, which
is incorrect. In particular, this caused the bitwise-not operator to
work incorrectly and produce invalid values.
Pull Request: https://projects.blender.org/blender/blender/pulls/122711
Duplicates the UI code for the "Stroke" panel and makes
sure it checks for the new GPv3 type in the poll functions.
This will allow us to slightly adapt the UI without
interfering with GPv2.
The sculpting template was created in Blender 2.80 and never adjusted
since then. The alpha socket is added as after linking step of the
versioning.
The GPU material clipping was done before clipping and would crash when
sockets don't exist.
Pull Request: https://projects.blender.org/blender/blender/pulls/122706
The system context is expected to be bound prior to the Blender
can be properly initialized. Otherwise GHOST will be doing OpenGL
calls without system context bound.
This follows code from DRW_render_context_enable().
Pull Request: https://projects.blender.org/blender/blender/pulls/122708
A regression since #118841.
It is possible that the selected preference device is not found, in which
case a default-initialized DeviceInfo would have added to the list. This
device is set to CPU, but with differnet other fields (such as description)
compared to the actual CPU device.
Pull Request: https://projects.blender.org/blender/blender/pulls/122701
The issue would happened in any situation where the light
moves (update, animation, jitter) or have a lot of LOD
tagged by moving casters. In these cases, the actual
effective LOD min is bigger than the one from the UI which
results in shadow acnee artifacts (because the computed bias
is too small).
This patch saves the effective min LOD per tilemaps and
amend the `light.lod_min` to replace it by the min of
all tilemaps in used by one light.
This adds the smooth post process option from GPv2 to the
GPv3 draw tool.
This now smoothes the positions, opacities and radii. In GPv2 the radii were not smoothed for some reason.
There were some private methods in `PaintOperation` that
were only called in `PaintOperation::on_stroke_done`. These
don't need to be private methods and can just be static functions.
There was also some code that changed the selection in the
function that was supposed to only trim the end points,
so that functionality is moved to it's own function instead.
The issue is visible when adding an assert in the delta accessors of
the TranslateOperation operation (get_delta_x and get_delta_y), and
rendering compositor-nodes-desintegrate-wipe-01.blend (either command
line or F12, doesn't matter).
Seems that under certain circumstances the system might skip determining
the area of interest. For such cases ensure delta from the beginning of
the threaded code.
Pull Request: https://projects.blender.org/blender/blender/pulls/122686
This fixes#69535 and #98930.
We use a equi-solid-angle sampling algorithm for rectangular area lights,
but it is not particularly robust for small area lights (either small
in general and/or small because it's being viewed from grazing angles).
The actual sampling part is fine since it just gets clamped into the
valid area anyways, and the difference isn't notable for small lights.
However, we also need to compute the solid angle to get the sampling PDF,
and that computation is quite sensitive to numerical issues for small
values.
Therefore, this commit adds a fallback path for small values, which instead
uses the classic equi-area sampling PDF term times the area-to-solid-angle
Jacobian term. This approximation assumes that all points on the light have
the same distance and angle to the sampling point, which is of course not
strictly the case, but it's close enough for small area lights and better
than failing altogether.
Pull Request: https://projects.blender.org/blender/blender/pulls/122323
Reformulates some terms in the equi-solid-angle rectangle sampling code to
handle small area lamps better, and allows for some rounding error in the
check whether the sampled position is inside the area light.
Pull Request: https://projects.blender.org/blender/blender/pulls/122323
