This was a design decision, but now we have decided to change it using the active material for the strokes using deleted material.
If the material slot is empty a new material is created to keep the strokes visible.
The issue was that the valid color modes was checked on the old image
format, not the new one. So if you switched formats it would not
correctly check if the settings were valid.
When they are occluded or when the snap is done for the generated meshes vertices, it was inconvenient.
An ideal solution needs to be discussed, but for now, for vertices, keep the behavior similar to the pre 2.8 versions.
The behavior for loading factory settings wasn't clear for users.
This commit changes the behavior:
- Loading factory settings always disables auto-save
for the current session.
- The internal setting to skip saving on exit is now exposed
in the preferences (when enabled).
- The menu item "Load Factory Settings (Temporary)" has been removed
since it's always temporary.
This way users can always reset factory settings without
having to consider the combination of options that might cause their
preferences to be overwritten at exit.
If they want to enable auto-save for the current session
this can be done from the preferences.
Cheap tip: anything that is not "Camel Case" and/or that is more than
a few words long should use `TIP_` translation, not `IFACE_` one.
Also added several missing strings (including the one reported in D5056
by Jean First (@robbott), thanks).
Collections are a tad annoying with all their caching of objects... When
we modify content of a children collection, we need to tag DeG for CoW
update of all of the ancestors.
For now keeping that recursive tagging helper private, but would not be
surprised if we found more similar cases and needed to expose it to more
code...
`IFACE_` is for short strings always shown in UI (like labels of buttons,
menu entries...). Every thing else, especially when more than a couple
of words, must use `TIP_`.
Note that there are probably many other similar cases... This code is
really legacy, should use library_query helpers and other modern
BKE_library code instead of doing its own dirty cooking...
This was due to a double offset of the wireframe. We also reduce
the wireframe offset. The look of the wireframe overlay changes
a little with on distant wires.
FFmpeg uses a fraction of integers to indicate the frame rate, whereas
Blender uses `int / float`. When a custom frame rate is used with
non-integer base, the FPS and Base settings were multiplied with 100000
before passing to FFmpeg as `int`. This could overflow when a high
enough FPS setting was used, which is the case when importing a video of
almost-but-not-quite-integer frame rate into the VSE. The overflow
caused FFmpeg to return an error "The encoder timebase is not set",
which is rather cryptic for users.
The new solution is to take the max int and divide that by the frame
rate, and use that ratio to pass to FFmpeg. This won't overflow, and
thus allows exporting arbitrary frame rates.
Was very easy to reproduce by rendering sequencer with sound strip.
Need to use evaluated scene to open movie handle, since that is the only
scene which has proper sound handle with everything else attached to it.
A lot of areas were querying sound information directly using audio handle
which does not exist on an original sound IDs.
This change basically makes it so it's possible to query information about
given sound ID, without worrying about whether it's loaded or not: if it is
needed to load it first it happens automatically (no automatically-opened
handles are left behind though).
While this seems a bit extreme to open files on such queries it is still
better than the old situation when all sound handles were opened on file
load, no matter if it's needed or not. Besides, none of the changed code
paths are performance critical, just handful of tools.
Fixes T65696: Sequencer fails to create a new sound sequence strip via Python
Fixes T65656: Audio strip - SHIFT K crashes Blender
Reviewers: brecht
Reviewed By: brecht
Subscribers: ISS
Maniphest Tasks: T65696, T65656
Differential Revision: https://developer.blender.org/D5061
Apparently the `rna_Armature_editbone_transform_update` function was incomplete because it didn't copy all mirrored transform values.
I also noticed that the same logic seen in `rna_Armature_editbone_transform_update` is also seen in `ED_armature_edit_transform_mirror_update`.
So the solution is expose and use that logic that updates a mirrored bone. Thus deduplicating and fixing T65671.
Reviewers: brecht, zeddb
Differential Revision: https://developer.blender.org/D5058
It could be argued this was correct behavior, since auto-save
defaults to 'on' nevertheless, auto-saving settings once
the user has disabled auto-save can lead to accidents.
Don't reset the preferences flag when resetting preferences.
Improvements to behavior for gizmo tool-tips.
- 2D gizmos no longer cancel tool-tips on cursor motion
(matching the behavior of UI widgets).
- 3D gizmos still close on motion since 3D gizmos may have a large
on-screen area which would cause them to stay visible even after the
cursor has been moved a large distance. The motion threshold is used
so they don't close on unintended cursor motion.
- Changing highlighted gizmo now cancels the tool-tip & resets the timer.
This code now expects to wrok from fully evaluated data, however when we
keep original, we are actually working from data just copied from orig
one.
Ideally, we'd do a single depsgraph update/eval *after* we have created
all new required data, but that is tricky to do properly in that code
without risking breaking one thing or another.
So for now, just going for the simple, if not optimal solution, and just
repeatedly re-evaluating whole deg every time we duplicate an object to
be converted. Yep, dummy, but simple and... safe. ;)
Redo panel would be hidden (when 'keep original' was not set), due to
same kind of (un)selected issue as in T65301 (see previous commit).
Further more, not all MBall objects of the family were properly removed.
We need to properly select new objects (and deselect 'source' ones) when
converting to another type while keeping original ones. Otherwise poll
check of the operator fails, and redo panel cannot be shown.
Note that this is actually a design flaw in redo system currently, since
*new* state has to still allow last operator to be ran, when it should
actually be previous step in history that matters here...
