This wrap some functions as class methods
and rename members to reduce confusion with
the old class meaning.
Rename the old DRWManager to DRWContext.
Also wrap access to DST inside a function
to allow to change it to thread local in a
following PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/135268
Move the `StaticShader` class from Workbench to `GPU_shader` and make
compilation thread-safe (Shader usage is still not thread-safe).
Use `StaticShader`s for all shader caches.
Subdivision shaders are still not ported.
(Part of #134690)
Pull Request: https://projects.blender.org/blender/blender/pulls/134812
This PR migrates the subdiv_patch_evaluation_comp.glsl to use
shader create info.
The part of OSD that is used is included as a typedef source (osd_patch_basis.glsl).
Pull Request: https://projects.blender.org/blender/blender/pulls/134917
This PR migrates the custom_data_interp_comp.glsl to use
shader create info.
During development tests have been conducted to use specialization constants,
but due to limitations inside Metal we didn't use them.
Number of ShaderCreateInfos have been reduced by using macros. Variadic macros
have not been used as they don't support CPP compilation.
Pull Request: https://projects.blender.org/blender/blender/pulls/134932
In this case, the evaluator cache was never referenced and
the subdiv free queue empty. So the freeing of the cache
never happened.
This function is called once per frame and is unlikely
to generate overhead by doing one lock.
Building failed with certain build options disabled, such as in my
extra-lean build.
Bisecting indicates that d0a6189b50 was
the cause, although it's not obvious to me why. But likely some
indirect include that was lost in the refactor.
This uses a fixed point size for selection, so that point selection is always visible
regardless of radius size.
The radius size is used to offset the selection point, so it is always visible, even when the radius is too large.
Co-authored by Hans Goudey.
---
Pull Request: https://projects.blender.org/blender/blender/pulls/134908
This cleanup naming convention and code clarity. There
is no functional change.
- `elem_ranges` is changed to a `Map` to avoid relying on
`sel_data->drawn_index`.
- `select_draw_utils.cc` is merged with `select_engine.cc`
- `index_drawn_len` is renamed to `max_index_drawn_len`
- Remove the usage of `DrawData`
Rel #134690
Pull Request: https://projects.blender.org/blender/blender/pulls/134940
Move the code dealing with converting float3 to GPU normals
out of the vertex format header into a separate header. Use a
proper C++ namespace and remove duplication by only using
the more recently added C++ templated conversions.
Most of the diff comes from the removal of the indirect includes
from GPU_vertex_format.hh. A lot of files ended up mistakenly
depending on that.
Pull Request: https://projects.blender.org/blender/blender/pulls/134873
This was caused by 91de4a50ab refactor which replaced
the evaluator cache singleton by local variable.
It was unknown that the evaluators in the cache
are actually referenced by the modifier data.
To fix this and fix the thread-unsafety of the global
variable, a mutex is introced around a reduced critical
section inside `draw_subdiv_create_requested_buffers`.
The global evaluator cache is now also refcounted to allow
freeing of the cache when no evaluator is referenced
anymore.
Pull Request: https://projects.blender.org/blender/blender/pulls/134926
This happend for meshes without UVs.
The call to `texpaint_request_active_uv` in
`DRW_mesh_batch_cache_get_surface_edges` is from 9c010c44f4.
Looks like this is not needed (assumed to be copy paste error).
Pull Request: https://projects.blender.org/blender/blender/pulls/134856
Subdiv shader library contains an optional part that shaders can include.
As we are migrating each shader at a time there are now multiple PRs doing
the same thing. Best to add the changes to main already so it doesn't add
confusion during review.
Pull Request: https://projects.blender.org/blender/blender/pulls/134906
This change migrates the first 2 subdiv shaders to use the ShaderCreateInfo.
Other shaders will follow in separate PRs.
- Should compile when using `WITH_GPU_SHADER_CPP_COMPILATION`
- A `subdiv_` prefix is added only to the functions related to `PosNorLoop`.
But eventually the prefix should also be added to other lib functions.
- Due to Metal restrictions `subdiv_set_vertex_*` is implemented using a
functional paradigma. Our Metal backend only supports `inout` qualifier
on thead local data structures.
Pull Request: https://projects.blender.org/blender/blender/pulls/134218
The main goal of these changes are to improve static (i.e. build-time)
checks on whether a given data can be allocated and freed with `malloc`
and `free` (C-style), or requires proper C++-style construction and
destruction (`new` and `delete`).
* Add new `MEM_malloc_arrayN_aligned` API.
* Make `MEM_freeN` a template function in C++, which does static assert on
type triviality.
* Add `MEM_SAFE_DELETE`, similar to `MEM_SAFE_FREE` but calling
`MEM_delete`.
The changes to `MEM_freeN` was painful and useful, as it allowed to fix a bunch
of invalid calls in existing codebase already.
It also highlighted a fair amount of places where it is called to free incomplete
type pointers, which is likely a sign of badly designed code (there should
rather be an API to destroy and free these data then, if the data type is not fully
publicly exposed). For now, these are 'worked around' by explicitly casting the
freed pointers to `void *` in these cases - which also makes them easy to search for.
Some of these will be addressed separately (see blender/blender!134765).
Finally, MSVC seems to consider structs defining new/delete operators (e.g. by
using the `MEM_CXX_CLASS_ALLOC_FUNCS` macro) as non-trivial. This does not
seem to follow the definition of type triviality, so for now static type checking in
`MEM_freeN` has been disabled for Windows. We'll likely have to do the same
with type-safe `MEM_[cm]allocN` API being worked on in blender/blender!134771
Based on ideas from Brecht in blender/blender!134452
Pull Request: https://projects.blender.org/blender/blender/pulls/134463
Though "Point Cloud" written as two words is technically correct and should be used in the UI, as one word it's typically easier to write and parse when reading. We had a mix of both before this patch, so better to unify this as well.
This commit also renames the editor/intern/ files to remove pointcloud_ prefix.
point_cloud was only preserved on the user facing strings:
* is_type_point_cloud
* use_new_point_cloud_type
Pull Request: https://projects.blender.org/blender/blender/pulls/134803
