This commit changes the behavior of the Clay Strips brush so that
it aligns more with expectations.
* Tilt is applied consistently to the sculpt plane instead of only being
applied if the brush is both using the calculated Sculpt plane and not
using the original normal.
* The sampled normal is used for the subsequent brush plane check
instead of being incorrect when alternate sculpt planes are used.
Pull Request: https://projects.blender.org/blender/blender/pulls/136965
**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
This fixes most "One Definition Rule" violations inside blender proper
resulting from duplicate structures of the same name. The fixes were
made similar to that of !135491. See also #120444 for how this has come
up in the past.
These were found by using the following compile options:
-flto=4 -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing
Note: There are still various ODR issues remaining that require
more / different fixes than what was done here.
Pull Request: https://projects.blender.org/blender/blender/pulls/136371
My version "4.6.14760 Core Profile Context 21.2.3 27.20.14535.3005"
was not caught by the spot-check. This change replaces the check with
a parser and range check.
Pull Request: https://projects.blender.org/blender/blender/pulls/136803
When resizing area, outline flickering is caught occassionally. Border edge
is not identified sometimes which doesn't set `active_area` to null.
This eventually draws outline with `TH_EDITOR_OUTLINE_ACTIVE` color.
When moving editors, always set `active_area` ptr as null to eliminate
jumping between two theme colors.
Pull Request: https://projects.blender.org/blender/blender/pulls/136487
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
Implements a crash dialog for Windows.
The crash popup provides the following actions:
- Restart: reopen Blender from the last saved or auto-saved time
- Report a Bug: forward to Blender bug tracker
- View Crash Log: open the .txt file with the crash log
- Close: Closes without any further action
Pull Request: https://projects.blender.org/blender/blender/pulls/129974
Current implementation uses a CPU roundtrip to transfer render result
to the Xr Swapchain. This PR adds support for sharing the render result
on Linux systems by using file descriptors.
To extend this solution to win32 or dx handles can be done by extending
the data transfer modes, register the correct extensions. When not
using the same GPU between Blender and OpenXR the CPU roundtrip
will still be used.
Solution has been validated with monado simulator and seems to be as
fast as OpenGL.
Performance can be improved by using GPU based synchronization.
Current API is limited as we cannot chain the different renders and
swapchains.
Pull Request: https://projects.blender.org/blender/blender/pulls/136933
When the collection is disabled and was only referenced by a node tree, it was
missing from the depsgraph. The Geometry Nodes modifier tried to add a relation
to it, but it couldn't because the collection was not in the depsgraph in the first place.
Now, the collection is always added to the depsgraph when it's referenced by a
node tree that's in the depsgraph too. This makes the existing code that adds the
relation from the collection to the Geometry Nodes modifier work.
Pull Request: https://projects.blender.org/blender/blender/pulls/136328
This is getting in the way of making the
GPUShader API more threadsafe.
This getter already doesn't work for vulkan
and Metal, and has very limited usage.
Keeping the python function to avoid errors
and display a deprecation warning.
Pull Request: https://projects.blender.org/blender/blender/pulls/136983
The GPU compositor crashes if 1D Voronoi is used. That's because the
vector input is unavailable in that mode, but the GPU material compiler
considers all inputs, even unavailable ones. So we need to link those
sockets to some arbitrary constant value.
The Merge Animation operator assumed that when a keyframe strip exists,
it always has a channelbag for the to-be-moved slot. This isn't
necessarily the case, so now it only moves the channelbag if it exists.
Pull Request: https://projects.blender.org/blender/blender/pulls/136978
In `lineart_geometry_check_visible` it could recieve a valid mesh
without any vertices, this causes `bounds` below to be invalid.
Now return early if encountered such situation.
Pull Request: https://projects.blender.org/blender/blender/pulls/136819
Some nodes like the Math and Mix Color node are duplicated when looking
at the link add search menu. That's because all nodes are considered in
that operation, even ones that are not listed in the menu. To fix this,
just disable the functionality for those legacy nodes.
Pull Request: https://projects.blender.org/blender/blender/pulls/136979
The Denoise node crashes if used in the viewport compositor. That's
because OIDN uses the compositor context in a different thread, which
does not have access to the DRW context. To fix this, we assign relevant
context data to the compositor context from the DRW context before
running the evaluator, then make the compositor context return those
data instead of accessing the DRW context.
This patch supports GPU OIDN denoising in the compositor. A new
compositor performance option was added to allow choosing between CPU,
GPU, and Auto device selection. Auto will use whatever the compositor is
using for execution.
The code is two folds, first, denoising code was adapted to use buffers
as opposed to passing in pointers to filters directly, this is needed to
support GPU devices. Second, device creation is now a bit more involved,
it tries to choose the device is being used by the compositor for
execution.
Matching GPU devices is done by choosing the OIDN device that matches
the UUID or LUID of the active GPU platform. We need both UUID and LUID
because not all platforms support both. UUID is supported on all
platforms except MacOS Metal, while LUID is only supported on Window and
MacOS metal.
If there is no active GPU device or matching is unsuccessful, we let
OIDN choose the best device, which is typically the fastest.
To support this case, UUID and LUID identifiers were added to the
GPUPlatformGlobal and are initialized by the GPU backend if supported.
OpenGL now requires GL_EXT_memory_object and GL_EXT_memory_object_win32
to support this use case, but it should function without it.
Pull Request: https://projects.blender.org/blender/blender/pulls/136660
Currently, tools like the sculpt tools or vertex paint tools don't do
any viewport culling of points. Meaning that when the screen space
positions are calculated, points that are very far away off-screen,
don't get discarded.
This lead to an issue in `brush_point_influence` because the coordinates
and the distance function were using 32-bit integers. When a point
was far enough away from the mouse position, this caused an overflow
to happen and the distance as well as the influence returned was negative.
To fix the immediate issue, do the distance calculation using floating
point to avoid the calculation from overflowing.
Note that we should still perform viewport culling of points to avoid
this computation alltogether.
Pull Request: https://projects.blender.org/blender/blender/pulls/136976
The current naming of the Hide Collection operator is counterintuitive.
Hide collection implies that it hides the selected collection, but it hides
all the collections that are not selected.
Pull Request: https://projects.blender.org/blender/blender/pulls/129682
Replace use of the UvVertMap table with checks using the existing
connectivity data.
This has the advantage that it's simpler to extend to support
for other kinds of connectivity checks - such as flushing
the selection to edges.
Introduced in de1c911d49
As noted in the comments of this commit, early returning in the
calculation of the Clay Strips brush prior to the plane being calculated
causes the initial value to be unset, which causes the brush to have no
effect even in the initial radius.
Pull Request: https://projects.blender.org/blender/blender/pulls/136962
This commit extracts the statements that calculate a brush's relevant
paint BVH node `IndexMask` into a dedicated method. A helper return
`struct` is introduced for the `optional` `plane_center` and
`plane_normal` values that are only relevant for the Plane brush
currently.
Pull Request: https://projects.blender.org/blender/blender/pulls/136859
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.
Fixes: #136842, #136645
Caused by 76d6d169ba
When multiple objects are selected to mark as assets, preview generation
job of previous ID in the for loop is cleared by `ED_preview_kill_jobs`
inside `generate_preview`. To fix this, check if `id->preview` exists then
clear the preview job if exists inside the new function
`ED_preview_kill_jobs_for_id`.
Solution proposed by @JulianEisel. I came up with idea to use `wm_job_find`
Pull Request: https://projects.blender.org/blender/blender/pulls/136918
Similar to eae60bc3e6.
The performance improvement depends on the attribute type, domain size,
and whether the cached vert to face map is used for something else like
vertex normal calculation during evaluation. In a simple test with a
large cube, I observed a 6.7x improvement in overall FPS for a 4x4
matrix attribute, a 1.12x improvement for a float attribute, and
roughly equivalent performance for booleans.
Pull Request: https://projects.blender.org/blender/blender/pulls/136941
In several nodes such as the capture attribute, bake, simulation, repeat,
and For Each nodes, we already use alignment of input and output sockets
to show when they correspond, make better use of space, and simplify
the UI. This PR extends that change to many more nodes. Sockets are
aligned when they have the same name and data propagates between
them. For now the various "sampling" nodes like Raycast and Sample
Nearest Surface are left out since their interface is a bit more complex.
Backward and forward compatibility aren't affected by this change;
it's just visual.
Pull Request: https://projects.blender.org/blender/blender/pulls/135876
One of the push constant was not set and was thus
in the last state is was in. This is because
we are not using the Batch or IMM API to draw
the batch, and thus, this push constant has to be
set manually upfront.
This commit parallelizes attribute domain interpolation for meshes from
the face corner to vertex domain. Parallel iteration is implemented
using the vertex to face topology map. The same map is used for mesh
normal computations and benefits from potential cost amortization in
its shared cache. This approach then tries to maximize cache usage
while minimizing potential memory consumption by avoiding caching
multiple topology maps.
The performance gain is dependent on the attribute type and domain size.
For a mesh with 16M vertices and 4x4 matrix attribute interpolation,
a 4.5x performance improvement was observed (from 10.7s to 2.38s).
Pull Request: https://projects.blender.org/blender/blender/pulls/135372
This adds a new more accurate antialiasing to the Grease Pencil
render engine. This is only available for render.
This Accumulation AA doesn't replace the SMAA. SMAA is still
used by the viewport and for removing aliasing from the
depth buffer. However, using both at the same time can lead
to overblurred result.
Here are some measurements for how much the render time
increases compared to the baseline with different (SSAA) sample
counts (using an example production file, rendered at 1080p,
results might vary depending on the scene complexity):
* 8 samples: +0.14 s
* 16 samples +0.36 s
* 32 samples: +0.58 s
Co-authored-by: Falk David <falk@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/136551
This patch adds a new interpolation option to the Scale node to control
how pixels are sampled during scaling. For constant sizes, this stores
the interpolation for later realization, while for variable sizes, the
interpolation takes effect immediately.
Pull Request: https://projects.blender.org/blender/blender/pulls/135989
This implements bundles and closures which are described in more detail in this
blog post: https://code.blender.org/2024/11/geometry-nodes-workshop-october-2024/
tl;dr:
* Bundles are containers that allow storing multiple socket values in a single
value. Each value in the bundle is identified by a name. Bundles can be
nested.
* Closures are functions that are created with the Closure Zone and can be
evaluated with the Evaluate Closure node.
To use the patch, the `Bundle and Closure Nodes` experimental feature has to be
enabled. This is necessary, because these features are not fully done yet and
still need iterations to improve the workflow before they can be officially
released. These iterations are easier to do in `main` than in a separate branch
though. That's because this patch is quite large and somewhat prone to merge
conflicts. Also other work we want to do, depends on this.
This adds the following new nodes:
* Combine Bundle: can pack multiple values into one.
* Separate Bundle: extracts values from a bundle.
* Closure Zone: outputs a closure zone for use in the `Evaluate Closure` node.
* Evaluate Closure: evaluates the passed in closure.
Things that will be added soon after this lands:
* Fields in bundles and closures. The way this is done changes with #134811, so
I rather implement this once both are in `main`.
* UI features for keeping sockets in sync (right now there are warnings only).
One bigger issue is the limited support for lazyness. For example, all inputs of
a Combine Bundle node will be evaluated, even if they are not all needed. The
same is true for all captured values of a closure. This is a deeper limitation
that needs to be resolved at some point. This will likely be done after an
initial version of this patch is done.
Pull Request: https://projects.blender.org/blender/blender/pulls/128340
