Remove the need for the `calc_vertex_coords` function by combining
the scale into the existing transform needed to export vertex positions
in global space. This simplifies code and may slightly improve performance
(I only observed a few percent difference in the positions export, which is
not a slower part of the export).
- Use Span where ownership is unnecessary
- Use Array when dynamic growth is unnecessary
- Use Vector in all other cases
Also remove unnecessary namespace specification.
When running the render test for EEVEE-Next the command printed on
the report to update the reference images was incorrect. In stead of
displaying
`BLENDER_TEST_UPDATE=1 ctest -R eevee_next` it displayed
`BLENDER_TEST_UPDATE=1 ctest -R eevee next`.
The cause of this is that the title of the report is used to create
the command. EEVEE-Next has a space in its title which generates
an incorrect command.
A quick fix would be to replace spaces with underscores. But it would
be better to fix this more clearly by adding an attribute containing the
engine name.
This PR adds a `set_engine_name` method to the Report class. By
default the engine name is set based on the title.
Pull Request: https://projects.blender.org/blender/blender/pulls/117503
Boolean ID property support was added in ef68a37e5d, but the JSON
serializer for ID properties was not updated for it. This would be a
forward compatibility issue, if future json files containing boolean
properties would be read with old versions. Such properties are added
in #106303, for example.
When a keying set is enabled and the keying set option
"Active Keying Set" was chosen from the menu, it would
give an error.
That is because the active keyingset uses a special
ID string (`"__ACTIVE__"`)
that doesn't actually exist as a keying set.
To fix it, explicitly check against that string and return
the active if encountered.
Pull Request: https://projects.blender.org/blender/blender/pulls/116192
The recently landed PR #115798has made it so the
hotkey `K` would call `anim.keyframe_insert_menu` with the property
`always_prompt` set to `True`.
This property still defaulted to `False` when called
from the menu leading to inconsistent
behavior when a keying set is active.
Fix it by setting `always_prompt` to `True` for the menu entries.
Pull Request: https://projects.blender.org/blender/blender/pulls/117511
The CPU implementation had the following downsides:
- The kernels sizes below 3 did not make much sense, often leading
to a full white image.
- The way how the total number of pixels in the kernel was calculated
quite strangely.
From these points of view the GPU compositor behaves more user friendly.
There is a versioning code which lowers the kernel size, to match the
result prior to these tweaks.
Pull Request: https://projects.blender.org/blender/blender/pulls/117505
This changes fixes the slowdown when baking data passes like Normal with
the denoiser enabled on scene settings.
When baking to 4K textures denoising could take considerable amount of
time, which is better be avoided.
Pull Request: https://projects.blender.org/blender/blender/pulls/117483
This is in response to feedback to the changes from #113504
While it does simplify inserting keyframes,
sometimes artists want to insert keys only to e.g. Location.
This takes longer to do now, since the option is in a menu.
This PR changes the following:
* new `K` hotkey to bring up the "Keying Set" menu.
This will always show the menu, even if a keying set is active.
* `Shift + K` will open a menu to set the active keying set
* with "Pie Menu on Drag" enabled in the user preferences,
hitting `I` and moving the mouse will bring up a pie menu
to insert only specific transform channels
Conceptually this separates the keying set behavior from the
insert keyframe behavior.
`I` will always add keyframes.
While `K` always shows keying set options.
Pull Request: https://projects.blender.org/blender/blender/pulls/115798
The part of the patch wasn't properly applied from a working branch,
and it wasn't very visible because the development environment already
had all files on disk.
Pull Request: https://projects.blender.org/blender/blender/pulls/117504
There exist a bunch of "give me a (filtered) image pixel at this location"
functions, some with duplicated functionality, some with almost the same but
not quite, some that look similar but behave slightly differently, etc.
Some of them were in BLI, some were in ImBuf.
This commit tries to improve the situation by:
* Adding low level interpolation functions to `BLI_math_interp.hh`
- With documentation on their behavior,
- And with more unit tests.
* At `ImBuf` level, there are only convenience inline wrappers to the above BLI
functions (split off into a separate header `IMB_interp.hh`). However, since
these wrappers are inline, some things get a tiny bit faster as a side
effect. E.g. VSE image strip, scaling to 4K resolution (Windows/Ryzen5950X):
- Nearest filter: 2.33 -> 1.94ms
- Bilinear filter: 5.83 -> 5.69ms
- Subsampled3x3 filter: 28.6 -> 22.4ms
Details on the functions:
- All of them have `_byte` and `_fl` suffixes.
- They exist in 4-channel byte (uchar4) and float (float4), as well as
explicitly passed amount of channels for other float images.
- New functions in BLI `blender::math` namespace:
- `interpolate_nearest`
- `interpolate_bilinear`
- `interpolate_bilinear_wrap`. Note that unlike previous "wrap" function,
this one no longer requires the caller to do their own wrapping.
- `interpolate_cubic_bspline`. Previous similar function was called just
"bicubic" which could mean many different things.
- Same functions exist in `IMB_interp.hh`, they are just convenience that takes
ImBuf and uses data pointer, width, height from that.
Other bits:
- Renamed `mod_f_positive` to `floored_fmod` (better matches `safe_floored_modf`
and `floored_modulo` that exist elsewhere), made it branchless and added more
unit tests.
- `interpolate_bilinear_wrap_fl` no longer clamps result to 0..1 range. Instead,
moved the clamp to be outside of the call in `paint_image_proj.cc` and
`paint_utils.cc`. Though the need for clamping in there is also questionable.
Pull Request: https://projects.blender.org/blender/blender/pulls/117387
This change fixes confusion situation when the render output
is an RGBA image: the difference in color was not visible in
the report because alpha channel was all zeros. This is due
to idiff performing per-channel difference.
The solution to this problem is to have separate images for
color and alpha difference, which makes it clear where the
difference actually is coming from.
Remove divergent code paths for hair refinement. Metal
previously opted for transform-feedback based hair
refinement due to improved performance, but best
to utilise the same compute path with new engines in
mind.
Separate PRs can be made to optimize the compute
path.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/117477
This is more like a hack, which ensures view layer depsgraph evaluation
when baking line art. It should fix the problem where the camera marker
switch would cause `view_layer->object_bases_array == null`.
Pull Request: https://projects.blender.org/blender/blender/pulls/117227
Broken from 72ab6faf5d
Because the `IMA_GEN_TILE` flag was not cleared during the memory pack,
the tile was regenerated on reloading. Mimic what is done during save
and clear the flag if all tiles pack successfully.
Pull Request: https://projects.blender.org/blender/blender/pulls/117472
Straightforward change from usage of iostream to CLOG.
Using CLOG unifies info/warning/error logging under a common
infrastructure that provides facilities for standardized filtering,
categorization, and printing. It also removes direct dependencies on
`<iostream>` which can be detrimental to compile times.
Pull Request: https://projects.blender.org/blender/blender/pulls/117429
This (likely copy-pasted) check to report either an unknown operator
type, or a known operator type missing its RNA struct definition, had a
reversed logic. It would report a 'missing srna' for unknown operator,
and vice-versa.
Cycles can use a per face flag to determine if a face is smooth or flat,
and there is no need to use corner normals in such cases. So revert to
not doing that as before, which also saves a bit of memory.
There is a pre-existing issue where faces are split by sharp edges and
autosmooth, which is not solved by this. It's only fixing the regression.
The fix in the logic is similar to 5875349390. It's needed
because we now skip computing face corner (BMLoop) normals when the
BMesh is completely flat shaded. It might be completely flat shaded
just because of edge smoothness though, which wasn't taken into
account before.
This simplifies code using these functions because of RAII,
range based for loops, and the lack of output arguments.
Also pass object pointer array as a span in more cases.
Pull Request: https://projects.blender.org/blender/blender/pulls/117482
