Refactoring mesh code, it has become clear that local cleanups and
simplifications are limited by the need to keep a C public API for
mesh functions. This change makes code more obvious and makes further
refactoring much easier.
- Add a new `BKE_mesh.hh` header for a C++ only mesh API
- Introduce a new `blender::bke::mesh` namespace, documented here:
https://wiki.blender.org/wiki/Source/Objects/Mesh#Namespaces
- Move some functions to the new namespace, cleaning up their arguments
- Move code to `Array` and `float3` where necessary to use the new API
- Define existing inline mesh data access functions to the new header
- Keep some C API functions where necessary because of RNA
- Move all C++ files to use the new header, which includes the old one
In the future it may make sense to split up `BKE_mesh.hh` more, but for
now keeping the same name as the existing header keeps things simple.
Pull Request: https://projects.blender.org/blender/blender/pulls/105416
The function to upload the normals uses an optimization to avoid
checking the smooth status or face normal of the triangle is part
of the same face. The smooth status needs to be initialized before
the loop for that to work.
Also do a bit of cleanup:
- Decrease variable scope
- Fix the reversed incorrect naming of `smooth`
- Retrieve mesh data at the start of the function
The previous API for clearing storage buffers was following the OpenGL
api. OpenGL has many options to support for data conversions, striding
and sizzling. Metal and Vulkan don't have these features and we have to
deal it ourselves.
Blender internally only uses a tiny subset for what is possible in
OpenGL. Making the current API to difficult to implement on our future
platforms as we had to implement all cases, most even not used at all.
By changing the API we make future development easier as we only need
to implement what we are actually using.
**New API**
`GPU_storagebuf_clear(GPUStorageBuf* ssbo, uint32_t clear_value)`
Related issue: #105492
Pull Request: https://projects.blender.org/blender/blender/pulls/105521
Clearing of clipmaps is the only place in Blender that uses non
uniform data (not all components of the cleared data to be exact
the same).
Vulkan has only the possibility to clear buffers using a single
uint32_t. There were two solutions:
- Add compute shader to Vulkan backend.
- Make Eevee-next responsible to clear the clipmaps.
When fixing this in the Vulkan backend it could lead to other issues
as the backend isn't aware what is exactly required and might overwrite
active bindings. We chose to make it a responsibility of Eevee-next
as there it is clear what is needed.
Related issue: #105492
Pull Request: https://projects.blender.org/blender/blender/pulls/105560
Both the shader_builder and existing shader tests eventually
tested the same aspects. shader_builder is more modern and
handles more cases.
The old shader test requires a full backend in order to run
This commit replaces the old tests to just use the
shader builder for validation.
Shader builder can still be run at compile time, this is
just a convenience to have as a test case as well for CI/CD.
Ref: #105482
Currently the shade smooth status for mesh faces is stored as part of
`MPoly::flag`. As described in #95967, this moves that information
to a separate boolean attribute. It also flips its status, so the
attribute is now called `sharp_face`, which mirrors the existing
`sharp_edge` attribute. The attribute doesn't need to be allocated
when all faces are smooth. Forward compatibility is kept until
4.0 like the other mesh refactors.
This will reduce memory bandwidth requirements for some operations,
since the array of booleans uses 12 times less memory than `MPoly`.
It also allows faces to be stored more efficiently in the future, since
the flag is now unused. It's also possible to use generic functions to
process the values. For example, finding whether there is a sharp face
is just `sharp_faces.contains(true)`.
The `shade_smooth` attribute is no longer accessible with geometry nodes.
Since there were dedicated accessor nodes for that data, that shouldn't
be a problem. That's difficult to version automatically since the named
attribute nodes could be used in arbitrary combinations.
**Implementation notes:**
- The attribute and array variables in the code use the `sharp_faces`
term, to be consistent with the user-facing "sharp faces" wording,
and to avoid requiring many renames when #101689 is implemented.
- Cycles now accesses smooth face status with the generic attribute,
to avoid overhead.
- Changing the zero-value from "smooth" to "flat" takes some care to
make sure defaults are the same.
- Versioning for the edge mode extrude node is particularly complex.
New nodes are added by versioning to propagate the attribute in its
old inverted state.
- A lot of access is still done through the `CustomData` API rather
than the attribute API because of a few functions. That can be
cleaned up easily in the future.
- In the future we would benefit from a way to store attributes as a
single value for when all faces are sharp.
Pull Request: https://projects.blender.org/blender/blender/pulls/104422
Render the transparent object bounds to a low-res frame-buffer and ray-march the
bounds volume, tagging shadow tiles along the way.
The bounds volume is inflated by half a pixel as a conservative rasterization
alternative, to ensure the tiles needed by all LOD0 pixels get tagged.
The bounds are rendered with front face culling and then the fragment shader
ray-marches against the bounds volume.
Each ray-marching step size equals the world space size of the pixel at the step
depth.
The step bounding sphere radius is also sent to the shadow usage tagging library
to ensure the whole step volume is tagged.
Pull Request: https://projects.blender.org/blender/blender/pulls/104580
This commit introduces `ConstListBaseWrapper`, to allow easy iteration over
`const ListBase *` in C++ code.
Basically `ListBaseWrapper` was renamed to `ListBaseWrapperTemplate`, and
got a new template parameter `LB`. The new `ListBaseWapper` class has `LB=ListBase`,
whereas `ConstListBaseWrapper` has `LB=const ListBase`.
Also in this commit is one use of `ConstListBaseWrapper` to make sure the
templated code is actually expanded & compiled.
Example use:
```cpp
for (const bDeformGroup *dg : ConstListBaseWrapper<bDeformGroup>(defbase)) {
...
}
```
Pull Request: https://projects.blender.org/blender/blender/pulls/105464
Indicating light colors by coloring the light icons.
Task: #104280
Pull Request: #105236
- Added a checkbox under overlay extra to enable/disable light coloring. Disabled by default.
- The outer ring and the sun rays are colored.
- Only the base color is shown, colors in nodes are not considered.
While developing a new armature draw type, I was switching between
branches and opening the same test file. It would crash Blender because
it assumed that the `else` clause could only mean `(arm->drawtype ==
ARM_OCTA)`. This is now explicitly tested for.
The result is that an armature with unknown draw type is not drawn at
all, but I prefer that over either resetting the draw type to something
valid (thus altering the blend file) or downright crashing.
Similar to the previous commit, this simplifies future refactoring
to change the way edges are stored, and further differentiates
single poly variables from array pointers.
Consistently use edge draw flag instead of original index to determine if an
edge should be drawn or not.
In GPU subdivision the edge original index was used for both edge optimal
display and selection mapping to coarse edges, but they are not the same.
Now match the CPU subdivision logic and use a separate edge draw flag VBO.
For cage display, match Blender 3.3 behavior more in showing/hiding of edges
in wireframe mode. That is edges without a mapping to an original edge are
always hidden when there is no distinct cage, and drawn otherwise. This is
not ideal for e.g. the bevel modifier where it will always show some edges on
corners despite all edges being hidden by the user. But we currently have
no good information to decide if these should be hidden or not, so err on
the side of showing too much as it did before.
Fie #103706: bevel modifier edges not drawn correctly
Fix#103700: optimal display can't be turned of with GPU subdivision
Fix wrong edge display with GPU subdivision preceded by other modifiers
Pull Request #105384
Intel GPUs exhibit a number of rendering artifacts.
The most substantial being incorrect resolve of reflections.
Splitting the reflections_resolve shader into two passes,
one for SSR and one for light probes ensures correct rendering
and optimal performance on this GPU.
Also resolves an artifact with ambient occlusion wherein
the pow(a, b) function causes excessive precision loss.
Using an alternative method for power calculation on these
platforms resolves the issues.
Authored by Apple: Michael Parkin-White
Ref T96261
Pull Request #105240
Metal backed requires HOST_READ texture usage flag
for irradiance grid. This was correctly in place for the
basic grid, but not for grid_prev.
Authored by Apple: Michael Parkin-White
Ref #96261
Pull Request #105312
Add overlay option for retopology, which hides the shaded mesh akin to Hidden Wire, and offsets the edit mesh overlay towards the view.
Related Task #70267
Pull Request #104599
Increase the buffer sizes used for `BLI_str_format_uint64_grouped` to
prevent overflow on strings representing numbers within the uint64
range. Also creates and uses defines for all the formatted string
buffer sizes.
Pull Request #105263
With the goal of clearly differentiating between arrays and single
elements, improving consistency across Blender, and using wording
that's easier to read and say, change variable names for Mesh edges
and polygons/faces.
Common renames are the following, with some extra prefixes, etc.
- `mpoly` -> `polys`
- `mpoly`/`mp`/`p` -> `poly`
- `medge` -> `edges`
- `med`/`ed`/`e` -> `edge`
`MLoop` variables aren't affected because they will be replaced
when they're split up into to arrays in #104424.
This offers overflow checking in debug builds, avoids implicit
conversion to pointers, slicing features for future convenience,
and clarifies ownership. Also switch naming to plural like most
other arrays for further clarification.
This pull request adds a new tipe of resource handles (thin handles).
These are intended for cases where a resource buffer with more than one
entry for each object is needed (for example, one entry per material
slot).
While it's already possible to have multiple regular handles for the
same object, they have a non-trivial overhead in terms of uploaded
data (matrix, bounds, object info) and computation (visibility
culling).
Thin handles store an indirection buffer pointing to their "parent"
regular handle, therefore multiple thin handles can share the same
per-object data and visibility culling computation.
Thin handles can only be used in their own Pass type (PassMainThin),
so passes that don't need them don't have to pay the overhead.
This pull request also includes the update of the Workbench Next
pre-pass to use PassMainThin, which is the main reason for the
implementation of this feature.
The main change from the previous PR is that the thin handles are now
stored directly in the main resource_id_buf, to avoid wasting an extra
bind slot.
Pull Request #105261
Previously [D16255](https://developer.blender.org/D16255)
There is no option to adjust the edge_width like there is in the preferences for vertex_size and face_dot_size.
I only added the option for 3DView and UV/Image Editor, and limited both to a max size of 5 pixel, since the edges do not look very nice with too high values.
In the UV Editor only, there are always black outlines on the edges, I could not find a way to reduce the increasing thickness of these black outlines.
The default edge_width of 1 pixel:
Here the edge_width with a falue of 3:
And here the visible increase of the dark border of the edges and their overlap (even at the maxed size of 5):
Lastly for the 3DView the max edge_width of 5 looks like this:
Pull Request #104741
For every other texture types this is expected to be implicitly
`GPU_DATA_FLOAT`. There is only one case where this is not the case.
I believe this was previously needed because the data type was
conditionning the texture creation. This is not the case anymore.
