Animators (especially for film and TV) often need
to track the movement of things in screenspace.
At the end of the day, the pixel motion is what counts.
But motion paths were always in world space,
which made it hard to use when the camera
is also animated (during action scenes e.g.)
This PR introduces the feature of projecting a motion path into the screen space of the active scene camera.
Limitations
This makes the motion path only useful when looking through the active scene camera.
Switching the scene camera using markers is not yet supported.
Technical Implementation
This is achieved by baking the motion path points into the
camera space on creation. For every point calculated,
the camera is evaluated through the depsgraph and
the resulting world matrix is used.
Then I pass in the current frame's world matrix of the
camera into the shader to make sure the points follow it.
As can be seen in the video, it looks quite odd when
viewed at another angle but this is expected.
I mentioned that in the tooltip, so it shouldn't be an issue
Pull Request: https://projects.blender.org/blender/blender/pulls/117593
This was caused by hair subpass growing the subpass
vector but not adding anything to the sorting_values_
vector. This means the indices that was return by
`sub_passes_.append_and_get_index` were dereferencing
the `sorting_values_` vector out of bounds on this line:
`float a_val = sorting_values_[a.index];`
The deferred combine pass was not rendered for these pixels
since they would not output any BSDF.
The check in pipeline sync have to be removed in order to
support emission only passes.
Curves draw buffer updates and operations like resampling access the
evaluated lengths cache of curves. However, when the curve has only one
point the evaluated lengths will be empty. This is not a problem for
open curves, because they skip calculation of the last point, but cyclic
curves expect to have as many length entries as there are points.
This crashes in certain cases:
- Grease Pencil v3 edit mode "Toggle Cyclic" operator
- Geometry nodes resampling of cyclic, single-vertex curves
Checking for the single-point case when building draw buffers handles
these corner cases.
Fixes#117833Fixes#117838
Pull Request: https://projects.blender.org/blender/blender/pulls/117842
There seems to be a driver bug on Linux + Mesa + AMD
The bug only appears in renderdoc if looking at the film pass
but not in the motion blur pass nor the volume pass.
Adding a clear event seems to fix the issue.
The render shadow loop would always tag new casters to update
the tiles that were already rendered. This patch split the
caster tagging into it's own pass and move it out of the loop.
Also adds a needed `async_flush_to_host` to make sure the
statistic buffer is up to date.
The root cause is still unknown. But replacing the
use of the depth texture by the hiz buffer fixes the
issue.
The issue was apparent on Linux + Mesa + AMD.
* For materials with UDIM tiles support, get array and mapping in one call
* For viewers that can use render results, add a dedicated function
* Fix potential use of render results in stencil overlay and grease pencil
Pull Request: https://projects.blender.org/blender/blender/pulls/117563
`GLBatch::draw_indirect` has additional overhead compared to
`GLBatch::draw`, and can become a bottleneck in scenes that require
many draw calls (ie. with too many unique meshes).
The performance difference is almost exclusively caused by the
`GL_COMMAND_BARRIER_BIT` barrier that happens on every call.
This PR adds a `GPU_storagebuf_sync_as_indirect_buffer` function that
can be used to place the barrier only once after filling the indirect
buffer content.
This function is a no-op in Vulkan and Metal since they don't need the
barrier.
Pull Request: https://projects.blender.org/blender/blender/pulls/117561
The test uses a none points shader to draw points, which is incorrect
and asserts when using Vulkan. It also didn't test the gpu part of the
pipeline (PassMain).
When using PassMain the order of the resources are expected to be
different as the draw calls are ordered based on the primitive type and
handles.
Pull Request: https://projects.blender.org/blender/blender/pulls/117714
When drawing curves or particle hair, the hair is refined using GPU
shaders. See eParticleRefineShaderType. OpenGL since Blender 4.0
always uses compute shaders. Metal since Blender 4.1 always uses
compute shaders. Vulkan will only uses compute shaders.
The transform feedback isn't used and not supported by our vulkan backend.
Transform feedback workaround was a Apple specific solution as they didn't
support transform feedback. Metal didn't use Compute shaders in
EEVEE-Legacy for performance reasons. Since EEVEE-Next/Workbench-Next
Metal uses compute shaders.
Fixes: #117497
Pull Request: https://projects.blender.org/blender/blender/pulls/117507
Remove transparency weight from other closure weights.
Since closure weights take transparency into account,
scaling closure colors by their weight applies alpha pre-multiplication to them,
causing dithered transparency materials to be darker than they should be.
Pull Request: https://projects.blender.org/blender/blender/pulls/117675
This avoid the following error
`Unknown NIR alu instr: div 32 %17 = ineg %16`
This is a debug shader so cost isn't important.
A bug report will be done upstream.
Part of overall "improve filtering situation" (#116980): replace Subsampled3x3
(added for blender 3.5 in f210842a72 et al.) strip scaling filter with a
general Box filter.
Subsampled3x3 is really a Box filter ("average pixel values over NxM region"),
hardcoded to 3x3 size. As such, it works pretty well when downscaling images by
3x on each axis. But starts to break down and introduce aliasing at other
scaling factors. Also when scaling up or scaling down by less than 3x, using
total of 9 samples is a bit of overkill and hurts performance.
So instead, calculate the amount of NxM samples needed by looking at scaling
factors on X/Y axes. Note: use at least 2 samples on each axis, so that when
rotation is present, the result edges will get some anti-aliasing, just like it
was happening in previous filter implementation.
Images in PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/117584
The problem was that `grease_pencil_edit_batch_ensure` would not return early if the buffers already exist, meaning that multiple buffers could be create but only the last ones would be freed.
Pull Request: https://projects.blender.org/blender/blender/pulls/117580
Fixes issue where motion blur would not display for
certain objects intermittently due to uninitialized
parameters in the ObjectKey struct causing the
motion object map look-up to fail and for motion
parameters to be reset to default, disabling the
effect for the given objects.
Authored by Apple: Michael Parkin-White
Co-authored-by: Michael Parkin-White <mparkinwhite@apple.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/117560
EEVEE uses an HiZ buffer. The size of the HiZ buffer is based on the render extent.
Probes assume that the render extent is always bigger than needed for rendering
probes. This assumption is incorrect.
Although this PR fixes this by allocating the required size, it is still renders with
artifacts. These artifacts originate from the lighting module and also needs to be
fixed.
Pull Request: https://projects.blender.org/blender/blender/pulls/117502
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
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
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
