This adds a new function to query GPUtexture from an
Image datablock without actually creating them.
This allows to keep track of all the texture that
needs to be loaded and defer their loading in
end_sync. The texture are then only used in the
next sync. This is because we do not want to stage
the texture for drawing as it would require a
valid texture.
Multithreading is used to load the texture from disk
as soon as possible in a threaded way. It is still
blocking, but it is much faster (depending on
hardware).
Before (5.7s):
After (2.5s):
On Linux workstation: 2.28x speedup in texture loading
On M1 Backbook pro: 2.72x speedup in texture loading
This includes redraw overhead but it is not super significant.
Having a vector of all the textures to be loaded
will eventually be helpful in making the
texture uploading multi-threaded. Currently, it is
a bit difficult given the need of a valid GPUContext
per thread.
- [x] Bypass deffered loading on animated textures
- [x] Add throttling to only load a few textures per frame
- [x] Do not delay for viewport render
Pull Request: https://projects.blender.org/blender/blender/pulls/139644
Use the C++ "get_default_hash" instead of the C GHash functions. These
are inlined and also simpler, which is typically good for our open-
addessing hash tables. In a few scenes with many objects/instances,
I observed a 2% improvement in playback FPS.
Also the less than operator was unused. I figured this was probably
used in a `std::map` or another container that required the operator
at some point.
Pull Request: https://projects.blender.org/blender/blender/pulls/139744
With 24d08e0bae, the ability to view UVs
in the Image Editor was introduced in all modes, not just Texture Paint
and Edit Mode. This introduced a new flag that was enabled by default,
causing UVs to be displayed in any of the Image Editor modes.
While this is helpful for some workflows, it is unnecessarily
distracting for many usecases when using the Image and Mask modes of the
Image Editor. To remedy this, this PR adds various polls to ensure
that these are only shown in the Paint Mode of the Image Editor and the
UV Editor. Further thought should be put into the potential separation
between the different usecases of this editor, but that is out of scope
for now.
Pull Request: https://projects.blender.org/blender/blender/pulls/139563
Caused by a67b5f6f63
Since we dont necessarily act with `MeshExtractType::BMesh` (can be
`MeshExtractType::Mesh` as well -- and seems the specific mesh analysis
`statvis_calc` functions are well prepared for this), move access to
`BMesh` to the codepaths specific to `MeshExtractType::BMesh`.
Also remove (non-appropriate) assert in `extract_mesh_analysis`.
Pull Request: https://projects.blender.org/blender/blender/pulls/139717
This implements the "boundary strokes" features (from 4.2 LTS).
To make it a bit more clear, the feature is now called "fill guides".
It uses the same `Alt`+`LMB` shortcut.
Fill guides are denoted by a `".is_fill_guide"` attribute set to `true`.
Otherwise they behave as normal strokes.
There is the `Clean Up` > `Remove Fill Guides` operator to remove
the strokes.
This also adds an option to the Fill tool to automatically remove fill
guides once a fill has been created.
Pull Request: https://projects.blender.org/blender/blender/pulls/139293
This was caused by the volume module not being available in
`begin_sync`.
The fix is to split `modules_init` into `init` and `begin_sync`
to always init the modules when creating the `DRWContext`.
Pull Request: https://projects.blender.org/blender/blender/pulls/139442
The cryptomatte textures where optimized for samplers, but could trigger
UB as they are also used with load/store. This PR will change the
dynamic data type of the cryptomatte to always use RGBA32F.
Detected with Vulkan validation layers.
Pull Request: https://projects.blender.org/blender/blender/pulls/139427
Cleanup and simplification of GPUMaterial and GPUPass compilation.
See #133674 for details/goals.
- Remove the `draw_manage_shader` thread.
Deferred compilation is now handled by the gpu::ShaderCompiler
through the batch compilation API.
Batch management is handled by the `GPUPassCache`.
- Simplify `GPUMaterial` status tracking so it just queries the
`GPUPass` status.
- Split the `GPUPass` and the `GPUCodegen` code.
- Replaced the (broken) `GPU_material_recalc_flag_get` with the new
`GPU_pass_compilation_timestamp`.
- Add the `GPU_pass_cache_wait_for_all` and
`GPU_shader_batch_wait_for_all`, and remove the busy waits from
EEVEE.
- Remove many unused functions, properties, includes...
Pull Request: https://projects.blender.org/blender/blender/pulls/135637
When enabled, this normalize the strength by the light area, to keep
the total output the same regardless of shape or size. This is the
existing behavior.
This is supported in Cycles, EEVEE, Hydra, USD, COLLADA.
For add-ons, an API function to compute the area is added for conversion,
in case there is no native support for normalization.
area = light.area(matrix_world=ob.matrix_world)
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/136958
Similar to other renderers, this adds a temperature property to set the
light color using blackbody emission. This can be more convenient than
using nodes, and can improve interop with other software.
This is supported in Cycles, EEVEE, Hydra, USD, COLLADA and FBX.
Pull Request: https://projects.blender.org/blender/blender/pulls/134303
Similar to other renderers, this adds an exposure property to multiply
the light power by 2^exposure. This can be more convenient to control
a wide range of values.
This is supported in Cycles, EEVEE, Hydra, USD, COLLADA and FBX.
Pull Request: https://projects.blender.org/blender/blender/pulls/134528
This is because the warm_shader_specialization was
not called for the actually used specialization since
the samples_len would be updated right before accumulation.
Fixed by calling update_sample_table before the warm shader
call. Also avoid default filter request 4 sample specialization.
This avoid all stall altogether.
This is mostly a non-functional change except for
* `overlay_armature.cc` was drawing relationship lines to bone
hidden by collection logic (except that doesn't seem to work anyway,
relationship lines are drawn regardless)
* `transform_snap_armature.cc` it was possible to snap to pose bones
hidden by collection logic.
I assumed those to be oversights so I changed them in this PR.
This does *not* remove all usages of `BONE_HIDDEN_P`
and `BONE_HIDDEN_A`. Some direct access is required in
the UI and for cases where we explicitly don't want to check
collection visibility.
Part of #138482
Pull Request: https://projects.blender.org/blender/blender/pulls/139151
Removes the stutters comming from the film shader.
The number of samples used by the film shader is set
throught a specialization constant. Since the number of
effective sample can depend on jitter position, this
number was fluctuating and trigger compilation on
new specialization until all specialization were
encountered.
Rounding the samples up to the most common sample
count fixes the issue.
Pull Request: https://projects.blender.org/blender/blender/pulls/139154
This caused UB in the tests now that tests are all ran
inside the same context.
A shader could be free but its pointer would be dangling
inside the `Context`. A new shader could have the same
address and generate UB after binding.
This is not the best way to solve this issue but at least
we prevent the use of the UB.
Pull Request: https://projects.blender.org/blender/blender/pulls/139109
This allows multiple threads to request different specializations without
locking usage of all specialized shaders program when a new specialization
is being compiled.
The specialization constants are bundled in a structure that is being
passed to the `Shader::bind()` method. The structure is owned by the
calling thread and only used by the `Shader::bind()`.
Only querying for the specialized shader (Map lookup) is locking the shader
usage.
The variant compilation is now also locking and ensured that
multiple thread trying to compile the same variant will never result
in race condition.
Note that this removes the `is_dirty` optimization. This can be added
back if this becomes a bottleneck in the future. Otherwise, the
performance impact is not noticeable.
Pull Request: https://projects.blender.org/blender/blender/pulls/136991
This feature greatly increase depth buffer precision.
This is very noticeable in large view distance scenes.
This is enabled by default on GPUs that supports it (most of the hardware we
support already supports this). This makes rendering different on the GPUs
that do not support that feature (`glClipControl`).
While this give much better depth precision as before, we also have a lot of
imprecision caused by our vertex transformations. This can be improved in
another task.
Pull Request: https://projects.blender.org/blender/blender/pulls/138898
- User visible rename: "Use Armature Setting" -> "Armature Defined"
(just added in 8bf73386f2)
- Internal code only: rename eArmature_Drawtype enum items to have
ARM_DRAW_TYPE_ prefix, instead of just ARM_ (just ARM_ is used in
several unrelated enums, leading to confusion)
This is re-apply of PR !138982 was backed out in cef7cb4534 due to
Win x64 buildbot failure. The error was:
```
view3d_navigate_view_all.cc(321): error C2672: 'blender::bounds::transform_bounds': no matching overloaded function found
view3d_navigate_view_all.cc(322): error C2784: 'blender::Bounds<blender::VecBase<T,3>> blender::bounds::transform_bounds(const blender::MatBase<T,Size,Size,NumCol*NumRow%4==0?4:1*sizeof(T)> &,const blender::Bounds<blender::VecBase<T,3>> &)': could not deduce template argument for 'const blender::MatBase<T,Size,Size,NumCol*NumRow%4==0?4:1*sizeof(T)> &' from 'const blender::float4x4'
```
which has nothing whatsoever to do with the PR. But something
in the PR (i.e. rename of a completely unrelated enum entries)
presumably makes this specific VS2019 compiler version not be
able to resolve template argument type. Again, in completely
unrelated file with completely unrelated types.
So "the fix" is to help VS2019 compiler in that place by explicitly
specifying the template types. What exactly in the original
change triggers the issue, remains a mystery. "It is known" that
VS2019 is quite funky in template argument deduction, maybe this
is one of these cases.
Pull Request: https://projects.blender.org/blender/blender/pulls/138995
- User visible rename: "Use Armature Setting" -> "Armature Defined"
(just added in 8bf73386f2)
- Internal code only: rename eArmature_Drawtype enum items to have
ARM_DRAW_TYPE_ prefix, instead of just ARM_ (just ARM_ is used in
several unrelated enums, leading to confusion)
Pull Request: https://projects.blender.org/blender/blender/pulls/138982
Armature bone display mode (Octahedral, Stick, Envelope, B-Bone,
Wire) could only be set on the whole armature. This adds ability to
override the display mode per-bone (by default bones use the
same display mode as the armature).
Images in the PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/138445
No functional changes intended.
This moves the functions
* ANIM_bone_is_visible
* ANIM_bone_is_visible_ebone
* ANIM_bone_is_visible_pchan
into new files `ANIM_armature.hh`/`armature.cc`.
They were previously in `ANIM_bone_collections.hh` but don't
directly have anything to do with bone collections.
It also puts the functions into the `blender::animrig::` namespace
and removes the `ANIM_` prefix as is the standard for C++ files.
Part of #138482
Pull Request: https://projects.blender.org/blender/blender/pulls/138833
This adds support for the extension and always
set the clip state value to 0..1 to align with vulkan
and metal. Moreover this is needed for the Reverse Z
implementation.
Note that this is a OpenGL 4.5 feature and is not
required to start Blender. So there must still be
a fallback path for now.
Rel #138898
Pull Request: https://projects.blender.org/blender/blender/pulls/138941
Replace `DRW_Attributes` with a VectorSet of std::string. The max number of
attributes is still the same. The inline buffer size is 4, and std::string's inline
buffer is smaller than the previous char array size of 64, but it seems
reasonable to save those optimizations for shorter attribute names and
fewer attributes. In return we significantly decrease the size of the batch
caches, simplify the code, and remove the attribute name length limit.
I observed roughly an 8% increase in the 30k cube objects file, a change from
12 to 13 FPS. I'm guessing this is mostly because `VectorSet<std::string>` is
smaller than `DRW_Attributes`.
Pull Request: https://projects.blender.org/blender/blender/pulls/138946
