Reference identifiers instead of "above" in code comments as these
tends to become outdated. Even when declarations are removed it's at
least clear that the reference no longer exists instead of referring to
whatever is currently above the declaration.
It's also straightforward to search history for a removed identifier.
Corrected 4 cases of references to things that were no longer above
the doc-strings. Noticed other references which look to be incorrect
but need further investigation.
Update the batch specializations compilation to allow using it in an
async way.
The implementation has 2 main limitations:
- Only one batch at a time can be processed, extra batches will be
added to a queue.
- Binding a specialization variant that is still being compiled will fail.
Pull Request: https://projects.blender.org/blender/blender/pulls/123015
With selected strips, it is not clear where one of them begins and another
ends since their outlines are right next to each other.
This changes strip look so that:
- All strips have consistent dark 1pt outline at the outer edge.
- Selected strips have 2pt highlight inside said outer edge.
- Selected strips also have a 1pt wide 33% opacity darker line inside the
selection highlight (and inside possible handles). To improve readability
in case strip content happens to be similar to selection/active color.
Images in PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/123431
Current look of VSE timeline view strip transformation handles makes them
somewhat "too narrow", especially after recent changes that made them
more narrow than before (handle tweaking feature) and a strip visual change
that made strip outline not go outside of strip bounds. They are now just
2px wide, effectively.
This changes their look as outlined in #123332 design task:
- The inset dark line is no longer over the handles, but rather "inside"
of them (except when handles are semitransparent, i.e. for strips that
are not selected).
- The handles themselves have rounded corners.
Pull Request: https://projects.blender.org/blender/blender/pulls/123391
Now the strip outline (1 point for unselected strips, 2 point outline +
1 pt dark inset) takes monitor DPI / user preference line width into
account, via the usual U.pixelsize machinery.
Pull Request: https://projects.blender.org/blender/blender/pulls/123369
This was a missing block of the TAA implementation.
TAA jitter and reprojection have a tedency to soften
the texture. Add a 1.5 bias to make them a bit sharper.
Note that this is a bit different than the usual TAA
blurring. In final render we don't do reprojection
so it is only because the texture filter (box filter
from the LOD) is applied at the same time than our pixel
filter (blackmann-harris). It is less noticeable than
the normal TAA blur, but still blurs ~2px instead of
1.5px.
This implement the holdout flag by switching to
the holdout case in the shader. This has a few benefits:
- Doesn't recompile the shaders.
- Makes the object infos mandatory (already the case in
practice)
- Handle transparent materials properly, keeping the
transparency working.
Fix#123284
Pull Request: https://projects.blender.org/blender/blender/pulls/123315
EEVEE Film accumulation workaround for Metal/Intel iGPUs.
On Metal the Intel iGPUs do not support image read write
on array textures. However this limitation doesn't show
any artifacts when using the compute shader.
This PR is a work around that uses the film_comp shader
to process the film samples, but uses a separate film_copy_frag
shader to read the result and copy them to the frame buffer.
I deliberately didn't include the fix to the film_frag shader
as that would change the read/write resources and could lead
to performance issues for other platforms. Writable resources
are typically slower compared to read only resources.
Some code needed to be duplicated (and not added to `*_lib.glsl`)
as compilers would still raise compilation errors due to imageStore/Load
on incompatible resource access.
The Metal/Intel iGPU is also marked to have limited support as
raytracing and probes still produces big artifacts.
This workaround can be tested on any platform just by setting
`use_compute_ = true` in `Film::sync`
Related to #122361
Pull Request: https://projects.blender.org/blender/blender/pulls/123330
The previous code was using matrix multiplication to
get the local thickness to world thickness.
The correct way is to multiply the local thickness
by the scale of the object (length of each columns
of the object_to_world matrix).
Previous commit that made VSE strip controls not be blurry (91fa37fecb)
applied "snap to pixel grid" in a wrong place - the rectangle corners
should be snapped, not the center and half-size of it.
Pull Request: https://projects.blender.org/blender/blender/pulls/123065
Somehow the 16K inside a string is parsed as being an integer, leading
to error messages about the `K` suffix.
```
ERROR (gpu.shader): gpu_shader_icon_multi VertShader:
|
1 | #version 430
|
| Error: C0159: invalid char 'K' in integer constant suffix
```
Fixed by changing the 16K to the actual number.
Related to #122977 With this PR blender will start, but EEVEE will render pink.
Pull Request: https://projects.blender.org/blender/blender/pulls/123071
Strips still have sharp corners when you're dragging them from file browser and
switch to rounded when dropped. Fix by using the same drawing code (and shader)
as regular timeline drawing path.
Pull Request: https://projects.blender.org/blender/blender/pulls/123013
Allow precompiling specialization constants variations in parallel.
Only supported in OpenGL as the rest of the batch compilation API,
on the other backends the function is a no-op.
This also moves the `SpecializationConstant` from
`gpu_shader_create_info` (private API) into`GPU_common_types`
(public API).
Pull Request: https://projects.blender.org/blender/blender/pulls/122796
Previously selected strips in VSE timeline were drawing their outline
1px outside of the strip boundaries. This makes outlines of the strips
overlap each other when neighboring strips are selected.
Now the selected outline is fully within regular strip shape.
Pull Request: https://projects.blender.org/blender/blender/pulls/122890
PR #122576 added rounded corners to VSE timeline strips, but they were not
"snapped" to pixel grid so the outline that is normally 1px was sometimes
falling in between pixels and was blurred out.
Fix by rounding all SDF related coordinates inside the shader to the pixel
grid.
Pull Request: https://projects.blender.org/blender/blender/pulls/122764
This is the first commit of the several required to support
subprocess-based parallel compilation on OpenGL.
This provides the base API and implementation, and exposes the max
subprocesses setting on the UI, but it's not used by any code yet.
More information and the rest of the code can be found in #121925.
This one includes:
- A new `GPU_shader_batch` API that allows requesting the compilation
of multiple shaders at once, allowing GPU backed to compile them in
parallel and asynchronously without blocking the Blender UI.
- A virtual `ShaderCompiler` class that backends can use to add their
own implementation.
- A `ShaderCompilerGeneric` class that implements synchronous/blocking
compilation of batches for backends that don't have their own
implementation yet.
- A `GLShaderCompiler` that supports parallel compilation using
subprocesses.
- A new `BLI_subprocess` API, including IPC (required for the
`GLShaderCompiler` implementation).
- The implementation of the subprocess program in
`GPU_compilation_subprocess`.
- A new `Max Shader Compilation Subprocesses` option in
`Preferences > System > Memory & Limits` to enable parallel shader
compilation and the max number of subprocesses to allocate (each
subprocess has a relatively high memory footprint).
Implementation Overview:
There's a single `GLShaderCompiler` shared by all OpenGL contexts.
This class stores a pool of up to `GCaps.max_parallel_compilations`
subprocesses that can be used for compilation.
Each subprocess has a shared memory pool used for sending the shader
source code from the main Blender process and for receiving the already
compiled shader binary from the subprocess. This is synchronized using
a series of shared semaphores.
The subprocesses maintain a shader cache on disk inside a
`BLENDER_SHADER_CACHE` folder at the OS temporary folder.
Shaders that fail to compile are tried to be compiled again locally for
proper error reports.
Hanged subprocesses are currently detected using a timeout of 30s.
Pull Request: https://projects.blender.org/blender/blender/pulls/122232
VSE timeline strips now have rounded corners. Strip corner rounding radius is
4, 6 or 8px depending on strip height (if strip is too narrow to fit
rounding, then rounding is turned off).
This is achieved with a dedicated GPU shader for drawing most of VSE
strip widget, that it could do proper rounded corner masking.
More details and images in the PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/122576
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
BLF font rendering isn't compatible with render graph as it
rewrites buffers that are not yet drawn. To work around this issue
the vertex buffers should always be created on device and not
directly altered by CPU code.
Pull Request: https://projects.blender.org/blender/blender/pulls/122648
The direct lights are usually much smoother and with
higher dynamic range than indirect lighting. Using
the R11B11G10 float format exhibit color shifts and
banding even in simple setups without a way to mitigate
the issue.
Using RGB9_E5 encoding improve the quality while retaining
the storage benefit of 32bit formats. The added overhead
of the software encoding not perceptible in a full lighting
pass.
This affects direct lights and SSS convolution result.
Fix#121937
Pull Request: https://projects.blender.org/blender/blender/pulls/122515
The setting adds the "Custom Shape Wire Width"
option to the "Viewport Display/Custom Shape" section of a pose bone.
As the setting says, this controls how thick the wire is drawn in the viewport.
This is done by adding a geometry shader that makes two triangles out of a line.
The Anti-Aliasing is controlled by the setting
Viewport->Quality->Smooth Wires->Overlay in the user preferences.
## Artifacts
When increasing the line width, the lines start to separate at their vertices.
This comes from extruding each edge along the normal of its direction.
This could be solved by adding round caps in a later PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/120176
Fix for #121890
The image shows testing results with "green" texture. It is expected that
all vectors are displaced along Y axis.
Cases are "no displacement", "tangent", "object" and "world" spaces.
Results are consistent with Cycles.
Pull Request: https://projects.blender.org/blender/blender/pulls/122376
One of the properties of Perlin noise is that it always evaluates to 0.0
when not normalized (or 0.5 when normalized) when the input consists of
only whole integers in all vector components.
Blender's Perlin noise implementation uses single precision floats with
a machine epsilon of 1.19e-07 meaning that for numbers that are greater
than 1/(1.19e-07) = 8.40e6 there mantissa doesn't have any bits left to
store a rational part of the number, effectively meaning that any number
greater than 8.40e6 is a whole integer as far as Blender is concerned.
Therefore when evaluating Perlin noise for any coordinates greater than
that it always results in 0.0 (or 0.5 when normalized).
This fix works as follows: If the original input number is larger than
1.0e6 it is offset by 0.5 after it underwent modulo, which always outputs
numbers in a [0.0, 1.0e5) range leaving the mantissa room for a rational
part. This way the quantization error still persists however the outputs
are random again instead of a constant 0.0.
Pull Request: https://projects.blender.org/blender/blender/pulls/122112
The goal of this is to make it easier to add more BSDF
support in the future. Avoids code fragmentation and
allows easy entry points to all algorithms using BSDFs.
Pull Request: https://projects.blender.org/blender/blender/pulls/122255
Add fast image writing and reading variants for render passes.
These variants do not perform range checking on values
and should only be used in cases where the written texel is
guaranteed to be in range. This eliminates additional
branching and simplifies shader logic.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/121116
