This is an alternative fix to [0] which kept the cursor centrally
located as part of GHOST cursor grabbing which caused T102792.
Now this is done as part of walk mode as it's the operator that most
often ran into this problem although ideally this would be handled by
GHOST - but that's a much bigger project.
[0]: 9fd6dae793
Historically checks for windowing capabilities used platform
pre-processor checks however that doesn't work when Blender is built
with both X11 & Wayland.
Add a capabilities flag which can be used to check which functionality
is supported. This has the advantage of being more descriptive/readable.
This reverts commits
9fd6dae793,
4cac8025f0 (minor cleanup).
Re-introducing T102346, which will be fixed in isolation.
Unfortunately even when the cursor is hidden & grabbed,
the underlying cursor coordinates are still shown in some cases.
This caused bug where dragging a button in the sculpt-context popup
would draw the brush at unexpected locations because internally
the cursor was warping in the middle of the window, reported as T102792.
Resolving this issue with the paint cursor is possible but tend towards
over-complicated solutions.
Revert this change in favor of a more localized workaround for walk-mode
(as was done prior [0] to fix T99021).
[0]: 4c4e8cc926
This was only called once in a situation where such functions
are typically used as a dynamic enum callbacks.
Prefer keeping the items close to the EnumProperty definition &
avoid the need to note why this is a special case that doesn't follow
the common pattern for enum callbacks.
- Follow sphinx conventions for doc-strings.
- Use __slots__ for KeyframesCo as dynamically assigning new members
isn't needed.
- Import from bpy.types instead of assigning.
- Split typing imports across multiple lines as they tend to become
quite large.
This is a solution in response to the issues mentioned in comments on
rBe4f1d719080a and T103088.
Apparently the workaround of checking if the mouse is already inside
the area on the next event doesn't work for some tablets.
Perhaps the order of events or some very small jitter is causing this
issue on tablets. (Couldn't confirm).
Whatever the cause, the solution of checking the timestamp of the event
and thus ignoring the outdated ones is theoretically safer.
It is the same solution seen in MacOS.
Also calling `SendInput` 3 times every warp ensures that at least one
event is dispatched.
This adds a new mirror image extension type for shaders and
geometry nodes (next to the existing repeat, extend and clip
options).
See D16432 for a more detailed explanation of `wrap_mirror`.
This also adds a new sampler flag `GPU_SAMPLER_MIRROR_REPEAT`.
It acts as a modifier to `GPU_SAMPLER_REPEAT`, so any `REPEAT`
flag must be set for the `MIRROR` flag to have an effect.
Differential Revision: https://developer.blender.org/D16432
The `render_color_index` skips attributes with different types
and domains in order to give the proper order for the UI list.
That is a different than an index in the group of all attributes.
The most solid solution I could think of is exposing the name of
the default color attribute. It's "solid" because we always address
attributes by name internally. Doing something different is bound
to create problems. It's also aligned with the design in T98366 and
D15169.
Another option would be to change the way the "attribute index"
is incremented in Cycles. That would be a valid solution, but would
be more complex and annoying.
For consistency, I also exposed the name of the active color attribute
the same way, though it isn't necessary to fix this particular bug.
The properties aren't editable, that can come in 3.5 as part of D15169.
Differential Revision: https://developer.blender.org/D16769
This is essentially a left-over from the initial transition to fields where this was
forgotten. The mesh primitive nodes used to create a named uv map attribute
with a hard-coded name. The standard way to deal with that in geometry nodes
now is to output the attribute as a socket instead. The user can then decide
to store it as a named attribute or not.
The benefits of not always storing the named attribute in the node are:
* Improved performance and lower memory usage when the uv map is not
used.
* It's more obvious that there actually is a uv map.
* The hard-coded name was inconsistent.
The versioning code inserts a new Store Named Attribute node that
stores the uv map immediatly. In many cases, users can probably just
remove this node without affecting their final result, but we can't
detect that.
There is one behavior change which is that the stored uv map will be
a 3d vector instead of a 2d vector which is what the nodes originally created.
We could store the uv map as 2d vector inthe Store Named Attribute node,
but that has the problem that older Blender versions don't support this
and would crash immediately. Users can just change this to 2d vector
manually if they don't care about forward compatibility.
There is a plan to support 2d vectors more natively in geometry nodes: T92765.
This change breaks forward compatibility in the case when the uv map
was used.
Differential Revision: https://developer.blender.org/D16637
This is done based on the render sample count so that it doesn't impact
sampling quality. It's similar in spirit to the adaptive table size in D16561,
but in this case for performance rather than memory usage.
Differential Revision: https://developer.blender.org/D16726
The first two dimensions of scrambled, shuffled Sobol and shuffled PMJ02 are
equivalent, so this makes no real difference for the first two dimensions.
But Sobol allows us to naturally extend to more dimensions.
Pretabulated Sobol is now always used, and the sampling pattern settings is now
only available as a debug option.
This in turn allows the following two things (also implemented):
* Use proper 3D samples for combined lens + motion blur sampling. This
notably reduces the noise on objects that are simultaneously out-of-focus
and motion blurred.
* Use proper 3D samples for combined light selection + light sampling.
Cycles was already doing something clever here with 2D samples, but using
3D samples is more straightforward and avoids overloading one of the
dimensions.
In the future this will also allow for proper sampling of e.g. volumetric
light sources and other things that may need three or four dimensions.
Differential Revision: https://developer.blender.org/D16443
While it helps on many scenes, it can be disruptive for existing scenes and
for benchmarks the differences in timing can be confusing. So be a bit more
conservative and only it enable it for new scenes.
This allows choosing the 2d vector type in the Store Named Attribute
node. Similar to byte-colors, there is not a special socket type for this
(currently). In geometry nodes itself, vectors are all still 3d.
The "Loading Asset Libraries" label in the menu would already disappear
before the asset libraries are done loading. It only queried if the
loading was started, not if it was finished. Especially notable when the
asset library was slow to load, e.g. because it is not yet in the asset
index.
The use of a struct for device strings caused the CUDA compiler to
generate byte arrays as the argument type, whereas OSL generated
primitive integer types (for the hash). Fix that by using a typedef
instead so that the CUDA compiler too will use an integer type in the
PTX it generates.
Maniphest Tasks: T101222
This is because OB_MODE_SCULPT_CURVES is not part of OB_MODE_ALL_PAINT
(yet). While there is some chance it ends up there, there are a lot of
more places that need checking and so patch only fixes the report very
isolated.
NOTE: T93501 is related (since the option to show these should also be
hidden in sculptmode)
Maniphest Tasks: T101765
Differential Revision: https://developer.blender.org/D16764
