| Age | Commit message (Collapse) | Author |
|---|
|
|
|
weird file system issues
|
|
This patch allows Asset Browser previews to be made regardless
of the setting of the (unrelated) "File Preview Type" Preference.
See D12484 for more details.
Differential Revision: https://developer.blender.org/D12484
Reviewed by Julian Eisel
|
|
|
|
This code path is not yet used so no harm, but that was a fairly nasty
potential crash-generator.
|
|
Use C++ version of C headers, and avoid static function call on instance.
No functional changes.
|
|
|
|
Use the inverse of the grease pencil object. This patch fixes the issue for bones and objects.
Maniphest Tasks: T91481
Differential Revision: https://developer.blender.org/D12539
|
|
Add `BLI_uuid` and `DNA_uuid_types.h` with a UUID implementation
following RFC4122 (https://datatracker.ietf.org/doc/html/rfc4122.html).
The following features are implemented:
- A struct of 128 bits that can be used in DNA definitions.
- Generation of version 4 UUIDs, that is, purely random ones.
- UUID equality function.
- String to UUID and UUID to string conversion functions that are
compatible with RFC4122.
- C++ stream operator that outputs the UUID as string.
This UUID will be used by the asset system, to uniquely identify asset
catalogs.
Reviewed By: Severin, jacqueslucke
Differential Revision: https://developer.blender.org/D12475
|
|
The simplify was hardcode to be disabled in render.
|
|
When using FModifier `Restrict Frame Range`, the resulting influence was
zero being exactly on `Start` / `End` range borders (so borders were
**exclusive**).
This made it impossible to chain FModifers together (forcing the user to
specify values slightly below the desired border in following
FModifiers).
This is now corrected to be **inclusive** on Start / End range borders.
Before
{F10234864}
After
{F10234865}
Testfile
{F10234866}
In the case of touching open borders (so [frame A frame B] followed by
[frame B frame C]) both modifiers are evaluated (in stack order).
If the later modifier has full influence (and is not additive) this simply
means the result is the same as the later modifier's value.
If influences below 1 are used (or modifiers are additive) both modifier's
values are interpolated/added accordingly.
technical notes:
- this was caused by the introduction of FModifier Influence/BlendIn-Out
in rB185663b52b61.
- for comparison, see other occurrences of
`FMODIFIER_FLAG_RANGERESTRICT`.
- the following conditions in `eval_fmodifier_influence` for blend in/
out have been changed accordingly.
Maniphest Tasks: T85564
Differential Revision: https://developer.blender.org/D10401
|
|
Change KeyMapItem.alt/ctrl/shift/oskey to integer types,
where -1 is used to ignore the modifier when matching key-map items.
It was only possible to set all modifiers to -1 at once from RNA
using the 'any' property.
Afterwards individual modifiers could be set back to true/false.
Although these key-map items could not be exported/imported.
Exposing the values directly avoids the need for cumbersome workarounds.
|
|
Command Lists
* The new system will be based on command lists
generated by (eventually) a node editor.
* For now, the lists will be hardcoded.
* Idea is to make a minimal viable
brush engine that won't cause file breakage
when the upgrade to node-based brushes happen.
Brush Channels
* Wrote new structures and API to wrange
brush parameters: BrushChannel.
* Supports, floats, ints, enums, bitmasks,
with plans for vec3 and vec4.
* This will replace UnifiedPaintStruct,
most of the members of Brush and the
DynTopoSettings struct.
* Brush channels can
be mapped to various input device
channels (e.g. pen pressure); each
mapping has its own associated curve
(CurveMapping instance) and bounds.
Brush channel inheritence chaining
* Brush channels can form inheritence chains
* Channel sets are stored in three places:
in the scene toolsettings, in Brush, and in
individual brush commands.
* Node groups will also have a channel set.
* Channels in each set can be flagged to
inherit from the parent set.
* Inheritence happens in seperate merged
channel sets at runtime. The final
Brush channels live in Brush->channels_final,
while the final command channels live in
BrushCommand->params_final.
|
|
These were added in a1c8543f2acd7086d412cb794b32f96794b00659 (2007)
but never used.
Nor did they have any meaning in practice.
Note that versioning keymap items isn't needed as these values were
never set. The code-paths that set these values also set KM_MOD_FIRST
causing `keymap_event_set` to only ever assign values of 0 or 1.
These flags complicate further exposing KM_ANY (-1)
which is also a valid value for modifiers.
|
|
- Show "Lasso Select" in menus (along with Box & Circle select)
- Show "Extrude to Cursor" (along with other extrude actions).
- Rename operators that add/extrude on Ctrl-Click
since their names were inconsistent.
This is mainly for discoverability.
|
|
- Bend (Transform).
- Extrude to Cursor.
- Lasso Select (related operators such as node-cut links, mask.. etc).
- Rip Mesh / UV's.
- Vertex/Edge Slide.
|
|
While the screenshot operator showed an "Area" option,
it wasn't usable from the main menu (unless accessed via menu search).
Split screenshot area into an operator that depends on cursor.
|
|
Support waiting for input so operators that depend on the
cursor location are usable from menus / buttons.
Use an operator type flag which the user interface code checks for,
waiting for input when run from a menu item.
This patch only supports this feature, there are no functional changes.
The motivation for this change is discoverability since some actions
were either hidden or broken when accessed from menus
(where the behavior of the operator depended on the menu location).
In general, waiting for input is *not* an efficient way to access tools,
however there are over 50 operators with a "wait_for_input" property
so this isn't introducing a new kind of interaction,
rather exposing this in a way that does not need to be hard-coded into
each operator, or having modal callbacks added for the sole purpose
of waiting for input.
Besides requiring boiler plate code using a "wait_for_input" property
has the added down-side of preventing key shortcuts from showing.
Only the menu items will enable the property,
causing them not to match key-map items.
Reviewed By: Severin
Ref D12255
|
|
An issue with the previous commit-- the default value of the type was
used instead of the property value when the "use_attribute" property
was missing.
|
|
This adds a toggle to node group inputs exposed in the modifier to use
an attribute instead of a single value. When the toggle is pressed, the
button switches to a text button to choose an attribute name. Attribute
search isn't implemented here yet.
One confusing thing is that some values can't be driven by attributes
at all, like the size of a primitive node. In that case, we should have
a node warning, but that will be separate since it's more general.
We can also have an option to turn off this toggle in node group
input settings.
The two new properties for each input are stored with the same name
as the value, but with `"_use_attribute"` and `"_attribute_name"``
suffixes. The properties are not added for socket types that don't
support attribute input, like object sockets.
Differential Revision: https://developer.blender.org/D12504
|
|
Adds an "Auto" option to blend thumbnail types that will automatically
use Screenshot if there is no camera and 3dview, or workbench render
with shading settings from the largest 3dview.
See D12407 for more details.
Differential Revision: https://developer.blender.org/D12407
Reviewed by Campbell Barton
|
|
Also remove unnecessary parantheses.
|
|
This should allow easier changes when it's helpful to use C++ types.
The diff is for a test on the buildbot.
Differential Revision: https://developer.blender.org/D12528
|
|
|
|
When saving blend files close any menus that might be open, show
"waiting" mouse cursor right away, before creating preview.
See D12507 for more details.
Differential Revision: https://developer.blender.org/D12507
Reviewed by Campbell Barton
|
|
|
|
Turns out this isn't actually necessary.
|
|
This patch allows point and spline attributes to be transferred to the
mesh generated by the curve to mesh node. All dynamic named and
anonymous attributes are transferred. So a user-created attribute will
be transferred, but "radius", "tilt" or the handle position attributes
won't be transferred by default and will need to be copied first.
This trade-off is made for performance, since most of the time, users
won't need these attributes copied.
Generally, attributes are transferred to the point/vertex domain.
However, if they have the same name as a built-in mesh attribute that
only exists on a different domain, like "shade_smooth", then they can
be transferred directly to that domain as well. Conversion directly to
the face corner domain is not necessary because there are no builtin
face corner attributes. I see this conversion directly to other domains
as an optimization we could use behind the scenes in the future as well,
when named attributes are less common.
For performance, I haven't tested which of the following is better:
```
for each spline combination:
for each attribute:
for each attribute:
for each spline combination:
```
For now I used the existing loop to avoid more threading overhead.
Differential Revision: https://developer.blender.org/D12363
|
|
Store the optional temporary span storage as a unique_ptr and move
it in the move constructor, to avoid the need to add a special move
constructor that clears the "show_warning" fields from it. Maybe this
is very slightly slower, but we'll need this class less often in the future
anyway.
|
|
|
|
"App" is a name reserved for the application templates at the moment.
It may become its own term in the near future if Templates are separated
from "Apps".
So since this is a name not exposed to the users we should renamed it
sooner than later.
Note that this will require scripts to update since the name of the
class is renamed here.
This also requires an update in the User Manual.
Differential Revision: https://developer.blender.org/D12523
|
|
With this, asset libraries can be directory structures and all assets in
sub-directories will show up in an Asset Browser.
With complex directory structures and many .blend files inside, asset
library reading will be quite slow for now. There's initial work being
done to introduce indexing for this (T82979), other optimizations are
being discussed as well.
Addresses T91406.
Differential Revision: https://developer.blender.org/D12139
|
|
|
|
This prevents both editor resize as well as regions (e.g., the toolbar).
Note: This option is not visible in the UI.
Differential Revision: D12516
|
|
The toggle that allow users to "show" the region (header, toolbar, ...)
when it is collapsed can now be configured for the apps.
Note: This option is not visibile in the UI.
Differential Revision: D12516
|
|
This breaks API compatibility. However we are now grouping this setting
in the proper section (preferences.apps), so scripts had to update anyways.
So they may as well do it for the final name.
The reason to remove from the UI is that this is intended for app setup,
and as such it should not be exposed to final users until we have apps
better presented (for 3.1 hopefully).
Differential Revision: D12516
|
|
There will be other settings that lock other aspects of the
UI layout (e.g., resizing of editors). So better to name
this setting what it actually handles (the corners).
New name: USER_APP_LOCK_CORNER_SPLIT
Differential Revision: D12516
|
|
|
|
Add needed extra flag and utils to IDType to mark and check an ID type
as only appendable.
Note that this is only a loose user-level enforcement currently, in any
case you need to be able to link an ID to append it currently, so for
low-level code this does not really matter.
Currently only WorkSpace and Screen ID types are marked with the new
`IDTYPE_FLAGS_ONLY_APPEND` flag.
|
|
While likely harmless, this code was doing extremely bad thing,
by-passing the whole lower-level `BKE_lib_id_make_local` call in case it
would fail and deciding by itself to forcefully make the given ID local.
Bad. Very, very, very bad.
|
|
a single ID local.
|
|
`BKE_id_newptr_and_tag_clear`.
|
|
Callbacks in IDTypeInfo should never affect other IDs if they are not
embedded.
We break this rule in some cases, at least each of those should be
clearly commented about and get some security checks to try to avoid
unexpected issues as much as possible.
|
|
|
|
Those were not clearing embdeed IDs flags and `newid` pointers at all...
|
|
Mixing testing and actual action in a single function is just not a good
way to do things, and the 'testing' feature is not used anywhere
anymore, time to get rid of it.
|
|
This is the same as `BKE_idtype_idcode_is_linkable` currently, used only
in one place in UI code of IDtemplate.
|
|
This flag became a full duplicate of `IDTYPE_FLAGS_NO_LIBLINKING`, which
is a good thing (don't think we ever want to be able to link some data,
without being able to make it local...).
So we can now remove it and use `IDTYPE_FLAGS_NO_LIBLINKING` instead.
|
|
|
|
Don't reset these flags when loading a file (or undoing)
rely on BPY_python_reset to reset the flags.
|
