When performing an undo in Sculpt Mode with Dyntopo enabled, it is
possible that the active color attribute exists in the original mesh but
not on the BMesh used by Dyntopo. When attempting to extract this color
data, this can then lead to a crash.
To prevent this, use the BMesh as the source of truth for existence of
generic attributes when mode inside Sculpt Mode when Dyntopo is enabled.
Pull Request: https://projects.blender.org/blender/blender/pulls/137828
It's safer to pass a type so that it can be checked if delete should be
used instead. Also changes a few void pointer casts to const_cast so that
if the data becomes typed it's an error.
Pull Request: https://projects.blender.org/blender/blender/pulls/137404
The goal here is to avoid having to cast to and from `ID` when getting the
evaluated or original ID using the depsgraph API, which is often verbose and not
type safe. To solve this, there are now `DEG_get_original` and
`DEG_get_evaluated` methods which are templated on the type and use a new
`is_ID_v` static type check to make sure it's only used with valid types.
This allows removing quite some verbosity on all the call sites. I also removed
`DEG_get_original_object`, because that does not have to be a special case
anymore.
Pull Request: https://projects.blender.org/blender/blender/pulls/137629
Tests were calling the submission mutex without
init. Adding functions to expose only setting
up the submission mutex instead of the full
DRW context (which is uneeded here).
This makes no sense to have in the draw namespace.
Also take the opportunity for making the coordinates
a float2 and rename them to something more descriptive.
This unify the C++ and GLSL codebase style.
The GLSL types are still in the backend compatibility
layers to support python shaders. However, the C++
shader compilation layer doesn't have them to enforce
correct type usage.
Note that this is going to break pretty much all PRs
in flight that targets shader code.
Rel #137261
Pull Request: https://projects.blender.org/blender/blender/pulls/137369
They are actually already some literals with the `f` suffix
that are in our shader codebase and we never had problem in
the past 5 years (or even 8 years).
So I think it is safe to do and improves convergence of codestyles.
Pull Request: https://projects.blender.org/blender/blender/pulls/137352
- Make the module global and allow usage from anywhere.
- Remove the matrix API for thread safety reason
- Add lifetime management
- Make display linked to the overlays for easy toggling
## Notes
- Lifetime is in redraw. If there is 4 viewport redrawing, the lifetime decrement by 4 for each window redraw. This allows one viewport to be producer and another one being the consumer.
- Display happens at the start of overlays. Any added visuals inside of the overlays drawing functions will be displayed the next redraw.
- Redraw is not given to happen. It is only given if there is some scene / render update which tags the viewport to redraw.
- Persistent lines are not reset on file load.
Rel #137006
Pull Request: https://projects.blender.org/blender/blender/pulls/137106
Allow detecting passes that can be skipped without side-effects and
don't submit them.
Eases debugging and profiling, and may provide a performance
improvement.
Pull Request: https://projects.blender.org/blender/blender/pulls/135875
Caused by 9b70851d91.
That commit inadvertently switched the order of these definitions. Because the
vertex buffers created by GPU subdivision still have a different format than regular
mesh drawing (the position buffer also includes vertex normals), the order of these
VBOs in the batch matters, since "lnor" attribute can override another.
Pull Request: https://projects.blender.org/blender/blender/pulls/137000
**Problem**
When using Texture Paint mode, the Image Editor will show a UV Wireframe
to display the active object's UVs. In every other mode, this wireframe
is absent. This is currently a big problem for Sculpt Mode since the
Experimental Texture Paint system is a part of that mode, meaning that
the user can't see their UVs while they paint in Sculpt Mode. This is
also troublesome for users that would like to quickly view an object's
UVs without using Texture Paint Mode.
**Solution**
Since it's useful to be able to view an object's UVs at all times, the
Image Editor should display UV Wireframes in all Object Modes regardless
of the Image Editor's mode. This is the best solution since it means
that future Blender features, that would benefit from having a preview
of an object's UV Wireframes, will automatically have that option since
UV Wireframes are supported in all modes. Also, if a user doesn't want
to see UV Wireframes for any reason, it can be disabled with an Overlay
option.
Additionally, when multiple objects are selected, each object should
have its UV Wireframe drawn in the Image Editor. The selected objects
that aren't active should have less opaque wireframes to indicate which
wireframe belongs to the active object. This is the best approach for
having multiple objects selected since it allows the user to quickly
view the UV layout for all selected objects to troubleshoot UV problems,
like texture mapping. This is especially helpful when using a material
for multiple different objects.
An alternative solution would be to only show the UV Wireframe for the
active object, but this would be undesirable because it would make
troubleshooting UV positions tedious when working with multiple objects
since the user would need to select objects individually.
Co-authored-by: T0MIS0N <50230774+T0MIS0N@users.noreply.github.com>
Co-authored-by: Sean Kim <SeanCTKim@protonmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/135102
Add a "dumb vector" storage option for custom normals, with the
"custom_normal" attribute. Adjust the mesh normals caching to
provide this attribute if it's available, and add a geometry node to
store custom normals.
## Free Normals
They're called "free" in the sense that they're just direction vectors
in the object's local space, rather than the existing "smooth corner
fan space" storage. They're also "free" in that they make further
normals calculation very inexpensive, since we just use the custom
normals instead. That's a big improvement from the existing custom
normals storage, which usually significantly decreases
viewport performance. For example, in a simple test file just storing
the vertex normals on a UV sphere, using free normals gives 25 times
better playback performance and 10% lower memory usage.
Free normals are adjusted when applying a transformation to the entire
mesh or when realizing instances, but in general they're not updated for
vertex deformations.
## Set Mesh Normal Node
The new geometry node allows storing free custom normals as well as
the existing corner fan space normals. When free normals are chosen,
free normals can be stored on vertices, faces, or face corners. Using
the face corner domain is necessary to bake existing mixed sharp and
smooth edges into the custom normal vectors.
The node also has a mode for storing edge and mesh sharpness, meant
as a "soft" replacement to the "Set Shade Smooth" node that's a bit
more convenient.
## Normal Input Node
The normal node outputs free custom normals mixed to whatever domain is
requested. A "true normal" output that ignores custom normals and
sharpness is added as well.
Across Blender, custom normals are generally accessed via face and
vertex normals, when "true normals" are not requested explicitly.
In many cases that means they are mixed from the face corner domain.
## Future Work
1. There are many places where propagation of free normals could be
improved. They should probably be normalized after mixing, and it
may be useful to not just use 0 vectors for new elements. To keep
the scope of this change smaller, that sort of thing generally isn't
handled here. Searching `CD_NORMAL` gives a hint of where better
propagation could be useful.
2. Free normals are displayed properly in edit mode, but the existing
custom normal editing operators don't work with free normals yet.
This will hopefully be fairly straightforward since custom normals
are usually converted to `float3` for editing anyway. Edit mode
changes aren't included here because they're unnecessary for the
procedural custom normals use cases.
3. Most importers can probably switch to using free normals instead,
or at least provide an option for it. That will give a significant
import performance improvement, and an improvement of Blender's
FPS for imported scenes too.
Pull Request: https://projects.blender.org/blender/blender/pulls/132583
This was caused by the manager being in sync phase only
between `begin_sync` an `end_sync`. The drawcalls sync
inside `begin_sync` like the lookdev sphere were given
bogus handles.
This also remove some uneeded functions wrappers.
This happened because the viewport was drawn after
the UV editor when some update occur (e.g. canceling an
operator). The requested UV edit batch would require only
one specific UV channel. The viewport, in need of a different
UV channel, requested a VBO rebuild (freing the old UV VBO)
but did not correctly clear the UV batches that were referencing
the said VBO. This lead to use after free which would sometime
works because the same memory would be reused for a random new
batch.
Pull Request: https://projects.blender.org/blender/blender/pulls/136780
Followup to 9b70851d91.
Return buffers by value rather than creating an empty/uninitialized
buffer first, then initializing it in an extraction function. This generally
makes the code easier to follow. And avoiding these half-created buffers
is an essential step to adding some sort of more global cache.
Pull Request: https://projects.blender.org/blender/blender/pulls/136570
The initial goal of this PR is to avoid creating vertex and index
buffers as part of the "request" phase of the drawing loop. Conflating
requesting and creating index buffers might not sound so bad, but it
ends up significantly complicating the whole process. It is also
incompatible with a future buffer cache that would allow avoiding
re-uploading mesh buffers.
Specifically, this means removing the use of `DRW_vbo_request` and
`DRW_ibo_request` from the mesh batch extraction process. Instead, a
list of buffer types is gathered based on the requested batches. Then
that list is filtered to find the batches that haven't been requested
yet. Overall I find the new process much easier to understand.
A few examples of simplifications this allows are avoiding allocating
`MeshRenderData` on the heap, and the removal of its `use_final_mesh`
member. That's just replaced by passing the necessary information
through the call stack.
Another notable difference is that for meshes, EEVEE's velocity module
now requests a batch that contains the buffer rather than just requesting
the buffer itself. This is just simpler to get working since it doesn't require
a separate code path.
The task graph argument for extraction is unused after this change. It wasn't
used effectively anyway; a simpler method of multithreading extractions is
used in this PR. I didn't remove it completely because it will probably be
repurposed in the next step of this project.
The next step in this project is to replace `MeshBufferList` with a
global cache that's keyed based on the mesh data that compromises each
batch, when possible (i.e. for non edit-mode meshes). This changes above
should be applied to other object types too.
Pull Request: https://projects.blender.org/blender/blender/pulls/135699
This was caused by the select_id not being flushed to
the armature object.
This is because the selection code uses `FOREACH_OBJECT_IN_MODE_BEGIN`
to iterate over the objects. This doesn't call the depsgraph
which would, in normal circumstances, flush the select_id value
to the evaluated object.
Also fix#136141
Pull Request: https://projects.blender.org/blender/blender/pulls/136320
Regression from 583e2b7240
`DRW_shader_init()` calls `GPU_context_create` before having a valid
GHOST context active (`WM_system_gpu_context_activate(system_gpu_context)`).
Swap the calling order to fix the issue.
Pull Request: https://projects.blender.org/blender/blender/pulls/136270
GPU subdivision shaders can read out of bound when evaluating
the last face. This seems to be always been the case, but Metal + Vulkan
has validation to detect these mis-usages.
Binary search was initialized with out of bound values so the last
face could select out of bound index due to rounding.
Pull Request: https://projects.blender.org/blender/blender/pulls/136242
This makes it possible for Cycles adaptive subdivision to always get the
base mesh, and will enable the same for other external renderers as well.
Metal and Vulkan now support GPU subdivision, so by default the wrapper
will be used most of the time. However this can be disabled in the
preferencesas well. For those cases, the subdiv wrapper is still created
but cached immediately as part of modifier evaluation. This way it can
take advantage of multithreaded depsgraph evaluation, which is not
guaranteed for other cases.
The draw code access the object data through a wrapper that will return
either the base mesh or subdivided mesh depending if GPU subdivision is
enabled or not. Previously Object.data would have the appropriate mesh
already, but now that Cycles may do adaptive subdivision while GPU
subdivision is disabled this is no longer possible.
Pull Request: https://projects.blender.org/blender/blender/pulls/135895
