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: blender/blender#105560
This patch re-implement the whole C rotation API into a more type
oriented C++ API. See the #104444 design task for more details about
the goals.
The list of C to C++ equivalent syntax can be found attached.
This adds `AngleRadian`, `AngleCartesian` and `AngleFraction` as
different angle types with the same interface. Each of them have
specific benefits / cons. See inline documentation for detail.
This adds `Axis` and `AxisSigned` class wrapped enums to increase type
safety with axes selection.
This adds `CartesianBasis` to represent orthonormal orientations.
Added a weight accumulation to dual-quaternions to make normalization
error proof. Creates the overhead of summing the total weight twice
(which I think is negligible) and add an extra float.
Named the dual-quaternion `DualQuaternion` to avoid naming ambiguity
with `DualQuat` which come up quite often (even with namespace).
Pull Request: blender/blender#104941
For mesh primitives, the bounds can be calculated trivially in advance
with negligible cost. In case they are needed later on, setting them
eagerly can save the calculation later on. For large meshes, this can
save tens of milliseconds before drawing.
Pull Request: blender/blender#105266
The shader libraries were not hooked up yet in cmake for windows since
when the shaderc libs landed there was no code yet that used it.
It's required now, so this change adds the missing bits.
Some checks here are really critical and should assert, but that one is
more an indication that something is not going right, though data itself
should still be mostly valid, so better warn the user with a LOG
warning, than be silent in release builds, and crash in debug ones.
Fix seam bleeding of non-manifold sections of the mesh, by copying pixels
that are covered by the brush stroke.
As manifold parts are already handled, the pixel copying solution can be
very straight forward.
* Pixels are copied from the same tile. So we don't need a mechanism that
copies and merges pixels from other tiles.
* Pixels are copied from the closest pixel that is being painted on. We
don't need to consider that that pixel can be in different areas of the
tile.
When we copy a pixel, we find the closest pixel in UV space that is being
directly influenced by a paint brush. We also look for the second closest
pixel, which is still a neighbor from the closest pixel. We can mix both
pixels together and store it in the destination. A mix factor is calculated
using the closest non manifold edge as a guidance.
The result of this step is a list of copy and mix commands that can be
executed to fix the seam bleeding for non-manifold sections of the mesh.
| Destination | Source 1 | Source 2 | Mix factor |
| ----------- | -------- | -------- | ---------- |
| 1780,1811 | 1780,1810| 1779,1810| 0.000000 |
| 1781,1811 | 1781,1810| 1782,1811| 0.168627 |
| 1828,1811 | 1828,1810| 1827,1811| 0.156863 |
| 1829,1811 | 1829,1810| 1828,1810| 0.188235 |
| 1830,1811 | 1830,1810| 1829,1810| 0.188235 |
| 1831,1811 | 1831,1810| 1830,1810| 0.188235 |
| 1832,1811 | 1832,1810| 1831,1810| 0.188235 |
| 1833,1811 | 1832,1810| 1832,1810| 0.000000 |
In the end we go over this list mix the sources and store the result at
the destination.
```
tile_buffer[destination] = mix(tile_buffer[source_1],
tile_buffer[source_2],
mix_factor);
```
**Encoding**
When using a large textures or large seam margins this table can grow
large and reduce performance as data retrieval is slower, than the
operations it has to perform. To improve the performance we encode the
table so less data retrieval needs to be done.
* first `DeltaCopyPixelCommand` is delta encoded from
`CopyPixelGroup#start_destination` and `start_source_1`. The others
are delta encoded from the previous `DeltaCopyPixelCommand`.
* For performance reasons PixelCopyGroup#pixels are ordered from
destination (left to right) for each row a new group would be created
as the delta encoding most likely doesn't fit. When pixels cannot be
delta encoded a new group will also be created.
**Compression rate**
When using Suzanne the compression rate is around 36% when using a seam
margin of 4 pixels. The compression rate may vary depending on seam
margin and model. For Suzanne the compression rate was around 36% for
various resolutions.
| Resolution | Margin | Decoded size | Encoded size | Compression |
| ---------- | ------ | ------------ | ------------ | ----------- |
| 2048x2048 | 4 px | 353.052 | 128.101 | 36% |
| 4096x4096 | 4 px | 700.140 | 255.137 | 36% |
| 8192x8192 | 4 px | 1.419.320 | 513.802 | 36% |
| 2048x2048 | 8 px | 721.084 | 193.629 | 26% |
| 4096x4096 | 8 px | 1.444.968 | 388.110 | 26% |
Pull Request: blender/blender#105336
The C4100 warning is related to unused formal parameters in functions.
Enabling it better aligns with "-Wunused-parameter" option in other
compilers.
While suppressing it with `__pragma(warning(suppress:4100))` is not the
same as using `__attribute__((__unused__))` in GCC or Clang, it is
still preferable to use it over completely hiding the warning.
This ensures consistent warning behavior across compilers and improves
code quality by addressing unused function parameters.
(Note that some warnings in Windows-specific code have already been
silenced in 7fcb262dfd)
Pull Request: blender/blender#105534
These functions will be useful to speed up the edit mode to object
mode conversion too, move them above that so they can easily be
used for that case later.
Currently a developer that starts blender with `--debug-gpu` or
runs the GPU test cases can receive an error when not the full
VulkanSDK is installed.
The VulkanSDK isn't required for normal developement and
therefore it is better to show it as a warning.
NOTE: VulkanSDK is adviced to use when developing in the Vulkan
backend as it contains tools that helps/speed up the development
and validation during development.
Pull Request: blender/blender#105599
Decorator buttons would be skipped when setting the tooltip data for all
buttons in the layout, but the duplicated data would still be marked as
used, so not freed.
Move two settings that were previously in the "View" menu of the Graph Editor into User Preferences.
It has been mentioned in the meeting by Luciano Muñoz Sessarego that it would be good to move that to the preferences so you can set it once and then forget about it.
The Settings moved are:
Only Selected Curve Keyframes
Use High Quality Display
Pull Request: blender/blender#104532
The traversable handle of a BLAS may be zero when the relevant geometry
is empty (no triangles/curves/points/...), as no BLAS is built in such cases.
It is not correct to attach a zero handle to a TLAS, so filter out such instances.
Invalid nodes are not added to the lazy-function graph. Therefore, their
outgoing links are also not added, which implies that the targets need
some default value.
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
It is recommended to map buffers once and not each time the
mapped memory is needed. This patch will map the buffer when
created and unmap the buffer when the buffer is freed.
This patch will reduce the overhead where the Vulkan driver or
the virtual memory manager needs to be accessed.
Pull Request: blender/blender#105588
The correction bbc6bb3468 was still wrong because there it was
disregarded that `vert_ctx_len` does not necessarily indicate merges in
the same polygon.
Therefore, it is not safe to rely on `vert_ctx_len` to count possible
new polygons.
NOTE: It might be worth preempting part of the
`weld_poly_split_recursive` logic to identify what the new polygons are
in advance. But this can be left for a future refactor.
- Both success & ok were used for file reading, use the clearer name.
- Paths were single/double quoted, use double quotes for print/reports.
- Rename `path` to `filepath` / `dirpath`.
Add a filepath argument to load/save pre/post.
Also add save_post_failed and load_post_failed handlers so it's always
possible to for the pre handlers to run a matching post action.
This makes it possible to know the filepath of the blend file mean
loaded/saved as well as supporting running an action when load/save
operations fail.
When loading and saving the startup-file, the path argument is set to
an empty string.
Details:
New RNA types were added to support storing primitive values in
PointerRNA. Primitive{String/Int/Float/Boolean}RNA. These will likely
only be used in some limited cases, in the case of BKE_callback_exec it
allows strings to be included as part of the PointerRNA **pointers
argument.
Ref !104769.
Don't allow the hover of mouse to auto-raise another window while you
are entering data into a text or number input.
Pull Request: blender/blender#105446
The attribute, like the other attributes that start with `.` is not
supposed to be displayed in the spreadsheet or the attribute list
by default. This was missing from the commit that added the attribute.
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: blender/blender#104422
Node tree updates can crash if the tree contains a node group that points at an "undefined" tree type.
This can happen if the tree is linked from a library and the path is lost,
or if a custom (python) tree is used and the script is not run.
The fix is to check if the node group type is valid ("registered") and return an empty list otherwise.
Pull Request: blender/blender#105564
The first implementation based the max value on what seemed reasonable.
It was therefore limited it to 5.
I received a request from a user in the first already merged #104741
to allow a higher max value.
Thus I adjusted the max value to be the same as the max value used for
"Vertex Size", 32.
Pull Request: blender/blender#105544
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: blender/blender#104580
