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: https://projects.blender.org/blender/blender/pulls/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: https://projects.blender.org/blender/blender/pulls/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.
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: https://projects.blender.org/blender/blender/pulls/104532
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: https://projects.blender.org/blender/blender/pulls/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.
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: https://projects.blender.org/blender/blender/pulls/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: https://projects.blender.org/blender/blender/pulls/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: https://projects.blender.org/blender/blender/pulls/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: https://projects.blender.org/blender/blender/pulls/104580
