This is the second time I've needed a function to find an attribute by
name on all attribute domains, with a third time coming soon. It seems
time to put this in a BMesh header.
Pull Request: https://projects.blender.org/blender/blender/pulls/144039
Caused by a compiler issue with function accessing the same SSBO in
different control flow.
Loading the SSBO data before doing the computation fixes the issue.
Candidate for Backporting to 4.5 LTS.
Pull Request: https://projects.blender.org/blender/blender/pulls/143926
Caused by 5f6e94ca58
When there are more than 2^16 points, the GPU index buffer code tries
to compress the indices to uint16 because we passed the incorrect max
index. In general that optimization just isn't worth the complexity
of precalculating the max index in this situation. There are other
potential optimizations here that would be vastly more helpful.
So just pass INT_MAX to disable the compression.
In case an image editor is open in the same window, entering sculpt mode
could crash. The cause is that the 3d viewport can request the sculpt
data vbo and its batch. But the image editor doesn't need it and removes
the sculpt data vbo, but doesn't remove the batch. Next frame the batch
could point to invalid data.
This fix will not keep the batch around so it is always being
reconstructed. A better solution needs to be found as the removal of the
vbo is done in a strange part, and the vbo should be checked against the
cd needed over time.
Pull Request: https://projects.blender.org/blender/blender/pulls/144013
This was caused by a mismatch in the conditions that enabled GPU
subdivision. The mesh normals domain for meshes with no faces was
reported incorrectly, causing the code to think there are auto-smooth
style split normals when there actually aren't.
Also the GPU subdiv normals extraction had a crash binding a vertex
buffer that doesn't exist when there are no faces. Add an early return
for the wire-only mesh case to avoid that.
Pull Request: https://projects.blender.org/blender/blender/pulls/143961
In a58dd0b5c3 sequential overlay segments
writing was replaced by a parallel one. But there was one hidden issue:
each curve knows its number of points and starting offset. If you want
to drop one curves set from domain -- you have to sequentially offset
all other curves. And this was not done. Gap between poly and nurbs
curve ,point indices created for bezier still there. And once it stop
being filled by 0 after 3e8250e60c we meet
all the segments of garbage. Proper fix: lay left handle segments in
space created for bezier segments. This fix: hide issue until proper
fix (non trivial refactor).
Pull Request: https://projects.blender.org/blender/blender/pulls/143858
This makes it so that Grease Pencil Bezier handles use the same colors and shaders as `Curves` Objects.
This also makes the handles follow `handle_display` and add the option the the edit mode overlay.
Pull Request: https://projects.blender.org/blender/blender/pulls/141524
Use MTLPatchShaderSource to provide the patch basis shader source on
all Apple platforms. The immediate advantage of this change is ability
to use GPU subdivision on iOS. Another advantage is that it moves us
further away from frameworks which got deprecated by Apple and it might
save us some headache in the future.
Also tweak backend-specific defines to match definitions from OpenSubdiv.
The annoying difference is that OSD_PATCH_BASIS_METAL is defined by the
OpenSubdiv as 1 in the very beginning of the base code, which is not done
for the OSD_PATCH_BASIS_GLSL is not defined by the OpenSubdiv at all.
Ref #143445
---
TODO:
- [X] Check it works correctly on macOS
- [x] Check it works correctly on Linux
Pull Request: https://projects.blender.org/blender/blender/pulls/143462
Use `BLI_strncpy_utf8` & `BLI_snprintf_utf8` for fixed size buffers in
DNA and screen data structures such as panels, menus & operators.
This could be considered a fix as copying a UTF8 string into a smaller
buffer without proper truncation can create an invalid UTF8 sequence.
However identifying which of these users are likely to run into would
be time consuming and not especially useful.
Caused by b19696c0b8.
I misunderstood the meaning of the vertex buffer allocation size.
Even though the attributes aren't interleaved, the fact that there
are multiple attributes is still included in the "element size" that's
multiplied with the size argument to `GPU_vertbuf_data_alloc`.
Also switch to spans and indices rather than incrementing raw pointers,
which would have made this much faster to debug.
Caused by 7688677e29, which replaced `DRW_draw_depth_object` with
`DRW_draw_depth_loop`.
`DRW_draw_depth_object` simply rendered the object without actually
using the DRW manager capabilities.
Now, with `DRW_draw_depth_loop`, the depth is rendered based on what
the engine sees with overlays disabled, which doesn't hide the
particles.
The solution to this issue is to skip particle rendering in the overlay
engine in `DRW_draw_depth_loop`.
Co-authored-by: Miguel Pozo <pragma37@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/141981
Since 4.5 the point clouds are out of experimental.
The drawing of pointcloud did not allow for correct volume
estimation as the shape are not rendered as closed objects
(i.e. the backfaces were not rendered).
This patch renders the backfaces for the volume occupancy
pass by rendering the pointcloud twice and flipping the
shape alignment matrix. This reverse the winding and
does a backface hit as it would do for a sphere primitive.
This solution even if not perfect avoids adding more
geometry in the Index Buffer. The geometry approach might
be preferable in the future if we find a way to render
the spheres without an IBO or with a JIT generated IBO.
Rel #141490
Pull Request: https://projects.blender.org/blender/blender/pulls/142095
It's simple to skip some work when all the triangles will be rendered
in the UV editor (though theoretically the best option would be to
share the non-UV triangle index buffer in this case).
Avoid function call overhead, add consistency between BMesh
and Mesh, parallelize filling the data and calculating the selection,
and avoid over-allocation in the cases where not all triangles will
be rendered.
Pull Request: https://projects.blender.org/blender/blender/pulls/142880
Caused by a slightly weird API, that has no good way to recieve
the final size of a partially used index buffer. Until this is refactored
more, just assign this data manually.
Pull Request: https://projects.blender.org/blender/blender/pulls/142748
On the Vulkan side, ensure that unbound textures don't result in
accessing uninitialized or out of bounds memory.
On the Draw side, ensure all Hair and Curves attributes have, at least,
a dummy attribute bound.
Pull Request: https://projects.blender.org/blender/blender/pulls/142265
Bounds check material indices since they may exceed the total number of
materials. This looks to be an oversight in [0] which added support
for an OpenGL evaluator.
[0] eed45d2a23
The report's mesh has a material index of -1 on one batch.
The current sanitizing of the index did not take this possibility
into account. Moreover, it was clamping to 1 index too high.
Candidate for 4.5 LTS backport.
Pull Request: https://projects.blender.org/blender/blender/pulls/142337
- Tangent calculation functions no longer use the CustomData struct as
an input and output.
- The "orco" and UV map calculations are exposed as separate API
functions to avoid a confusing internal choice between the two
- Redundancy in the API is removed, function names are clarified
- Code is moved to C++ namespace
- The "orco" case is clarified in the mesh draw tangent VBO extraction
- CD_TANGENT layers are not stored in CustomData anymore, so some of
that infrastructure is removed.
- Broken logic for caching tangents in CustomData is removed. That
hasn't worked for many years, if it every worked. We could investigate
adding caching again later if that's helpful.
Overall the change is motivated by the need to move away from CustomData
for #122398. But the changes should be a general improvement that makes
the code easier to understand either way.
Testing for this PR included using the default render UV in materials,
referencing specific UV tangents by name, using the spherical position-
based tangents in a material, and baking textures (multires and normal
baking).
Pull Request: https://projects.blender.org/blender/blender/pulls/141799
This commit moves the freestyle edge and face mark tags to become
generic attributes, similar to other changes over the past years. The
attributes are called "freestyle_edge" and "freestyle_face", and they're
now propagated like regular boolean attributes.
Compatibility wise, forward and backward blend file compatibility are
maintained (for forward compatibility this is implemented a bit
differently than in the past because of the ongoing `AttributeStorage`
transition). In the Python API, `use_freestyle_mark` has been removed;
the attribute API should be used instead (just like bevel weights).
The BMesh (`freestyle`) accessors are removed too.
The conversions benefit from the fact that bit-wise, the old structs are
the same as `bool`, so we can convert to the old and new formats without
reallocating arrays.
Pull Request: https://projects.blender.org/blender/blender/pulls/141996
Alternative solution to #141392 / #141564.
As a recap, the DST global lock (which prevented running drawing code
from multiple threads concurrently) was removed for 4.5 (#134690).
One unforeseen issue is that Images (and their GPUTextures) are shared
across dependency graphs (and therefore multiple threads), meaning we
are running into data race issues with them.
@fclem did #141392 and I continued it #141564. However, this is only a
partial solution, parts of the GPUTexture API and the whole BKE_image
API are still unsafe.
Trying to solve all the possible underlying issues seems unrealistic for
4.5 given the time frame and that the extension of the code affected by
this issue is quite large.
So this PR just brings the 4.4 locking behavior instead, which, while
risky on its own, seems much safer to me than the alternative.
This effectively undoes the improvements from #134690 by disabling
concurrent rendering, but instead of reverting all the code, it just
ensures we hold the lock in the same places we did in 4.4.
This means there's some redundant code that is not technically needed
anymore, like the `submission_mutex`, but it's probably best to make as
few modifications as possible, given how close we are to release and
that this is only intended as a temporary measure.
Pull Request: https://projects.blender.org/blender/blender/pulls/141618
The feature to display multiple objects in the UV and Image Editor was
added in 24d08e0bae.
This commit did not account the multi-edit mode feature, where there may
be more than one object currently being edited, causing some UVs to
display with a faded opacity.
To fix this, introduce a new `eObjectInfoFlag` flag to indicate this
state, populate it when syncing the object, and use the flag inside the
relevant shaders.
Pull Request: https://projects.blender.org/blender/blender/pulls/141254
Reading from the top-right of the selection buffer could read
past the buffer bounds. Resolve by ensuring the clamped buffer
isn't empty. Relates to #141591.
As noted in [0], locking or atomics are not required for merging
requests for a single mesh, because there is no multithreaded iteration
over objects that will process the same mesh in multiple threads. This
locking was added preemptively over the years and has made code
needlessly complicated, even while the final design for parallel object
iteration isn't completely clear. This PR removes the locks to simplify
some changes necessary for mesh attribute storage refactors.
[0]: b6764e77ef
Pull Request: https://projects.blender.org/blender/blender/pulls/141405
