Age | Commit message (Collapse) | Author |
|
Newly created objects would not become visible until
another action forced a depsgraph update.
|
|
Mistake in a30a8179331d689c9e599fb9a530c0b6b155f689.
|
|
Reading paths over 512 bytes would cause a buffer overrun.
|
|
This patch improves the positioning of child windows when on monitors
that are arranged vertically (any above any other). When calculating a
window position in Ghost coordinates from GL coordinates we were using
monitor height, which can give incorrect values when desktop is taller
than any single monitor. So use desktop height instead.
See D10637 for more details and examples.
Differential Revision: https://developer.blender.org/D10637
Reviewed by Brecht Van Lommel
|
|
|
|
|
|
selected pass
Caused by {rBebaa3fcedd23}.
Seems this above commit assumed an ImageUser's multi_index is only used
for Multiview/Stereo? This is not the case, multi_index also stores the
index for layer/pass combination.
If we call both BKE_image_multilayer_index and BKE_image_multiview_index
(even though this is not appropriate/needed for multilayer images?), we
might end up overwriting multi_index again.
note: looking at this I was also wondering why we update the ImageUser
in image-buffer-aquiring funnctions [and not from the UI, e.g.
template_image_layers, but that is a whole different story I guess, see
comment in T90772 as well]
note2: this could also use a utility function (this is not the only
place where this is done), this is fo a cleanup commit.
Maniphest Tasks: T90772
Differential Revision: https://developer.blender.org/D12267
|
|
This was working differently in 2.79, tried tracking this down and it
seems this was wrong since the 2.8 beginning in {rB7907dfc40018}.
This would not only crash without an active scene camera, but would also
result in different tracks from different camera's constraints could not
be selected.
So select id depends on corresponding camera, remove the dependency on
scene camera completely.
Maniphest Tasks: T90651
Differential Revision: https://developer.blender.org/D12230
|
|
|
|
|
|
FFMPEG_USE_DURATION_WORKAROUND
|
|
We didn't flush audio after encoding finished which lead to audio
packets being lost.
In addition to this the audio timestamps were wrong because we
incremented the current audio time before using it.
Reviewed By: Richard Antalik
Differential Revision: http://developer.blender.org/D11916
|
|
|
|
Would cause crashes in files that had lingering invalid sound sequences around.
For example our tests/render/volume/fire.blend test file.
|
|
Bug caused by integer overflow in ffmpeg_generic_seek_workaround().
Function max_ii() was used to limit int_64tvalue.
After fixing the issue there was another issue, where near-infinite loop
was caused by requested_pos being very large and stream being cut in a
way, that it was missing keyframe at beginning.
This was fixed by checking if we are reading beyond file content.
Reviewed By: zeddb
Differential Revision: https://developer.blender.org/D11888
|
|
Refactor and improve waveform drawing.
Drawing now can use line strips to draw waveforms instead of only
triangle strips. This makes us able to properly visualize thin waveforms
as they would not be visible before. We now also draw the RMS value of
the waveform.
The waveform drawing is now also properly aligned to the screen pixels
to avoid flickering when transforming the strip.
Reviewed By: Richard Antalik
Differential Revision: https://developer.blender.org/D11184
|
|
The duration and start time for audio strips were not correctly read in
audaspace.
Some video files have a "lead in" section of audio that plays before the
video starts playing back. Before this patch, we would play this lead in
audio at the same time as the video started and thus the audio would not
be in sync anymore.
Now the lead in audio is cut off and the duration should be correctly
calculated with this in mind.
If the audio starts after the video, the audio strip is shifted to
account for this, but it will also lead to cut off audio which might not
be wanted. However we don't have a simple way to solve this at this
point.
Differential Revision: http://developer.blender.org/D11917
|
|
The seek pts was not correctly calculated.
In addition to that we were not seeking in the video pts time base.
Reviewed By: Richard Antalik
Differential Revision: http://developer.blender.org/D11921
|
|
The video duration was not read correctly from the video file.
It would use the global duration of the file which does in some cases
not line up with the actual duration of the video stream.
Now we take the video stream duration and start time into account when
calculating the strip duration.
Reviewed By: Richard Antalik
Differential Revision: http://developer.blender.org/D11920
|
|
If the add strip operator errored out, we wouldn't free custom data allocated
Reviewed By: Richard Antalik
Differential Revision: http://developer.blender.org/D11919
|
|
Before we didn't encode the audio up until the current frame.
This lead to us not encoding the last video frame of audio.
Reviewed By: Richard Antalik
Differential Revision: http://developer.blender.org/D11918
|
|
The original assumption that the `modifyMesh` function is only
called when the modifier is applied was wrong. There are still a
couple of other places calling it through `BKE_modifier_modify_mesh`.
Now there is an extra check that makes sure instances are only
realized when the modifier is actually applied.
|
|
Caused by {rBbbb1936411a5}.
When adding strips via the new SEQ_add_XXX_strip functions, the
`Editing->seqbasep` pointer was passed around.
Following in `seq_add_generic_update` this `seqbasep` pointer was used
to ensure a unique name.
But `seqbasep` is the pointer to the current list of seq's being edited
(**which can be limited to the ones within a meta strip**).
We need unique names across all strips though (since these are used for
RNA paths, FCurves as reported), so now use the scene's `Editing-
>seqbase` (**which is the list of the top-most sequences**) instead.
Unfortunately this might have screwed files to a borked state, not sure
if this could easily be fixed...
Maniphest Tasks: T90737
Differential Revision: https://developer.blender.org/D12256
|
|
|
|
While trying to get Blender 2.93.x LTS to build fine on all release architectures in Debian, I noticed that the misleading use of "mips" as integer variable caused problems when compiling on mips64el. The patch should fix the issue.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D12194
|
|
Some of the dna structs were not properly
aligned for 32 bit builds causing issues
for some of the 32 platforms Debian builds
for.
Reviewed By: sergey, brecht
Differential Revision: https://developer.blender.org/D9389
|
|
Makesdna fails to detect issues in 32 bit code that can
only be resolved by adding a padding pointer.
We never noticed since we ourselves no longer build for
32 bit, but debian's 32 bit builds got bitten by this
A rather extensive explanation on why this is alignment
requirement is there can be found in this comment:
https://developer.blender.org/D9389#233034
Differential Revision: https://developer.blender.org/D12188
Reviewed by: sergey, campbellbarton
|
|
When channels are scrolled to be (partially) behind the search bar,
their widget buttons would still be interactive, preventing the seach
buttons to be usable.
We have to make sure the events are consumed from the search and dont
reach other UI blocks.
We can do so by flagging the block `UI_BLOCK_CLIP_EVENTS` -- but also
have to make sure the bounds are calculated correctly (otherwise the
check relating `UI_BLOCK_CLIP_EVENTS` in `ui_but_find_mouse_over_ex` wont
trigger properly.
Maniphest Tasks: T90364
Differential Revision: https://developer.blender.org/D12103
|
|
The poll for unlinking calls `nla_panel_context` without providing an
adt pointer, and there is a check for this pointer in
`nla_panel_context` leading to never returning true if it is not
provided. (this is fine if there are tracks already, poll would succeed
in this case, `nla_panel_context` goes a different code path then)
Same call to `nla_panel_context` is also done in the beginning of the
corresponding unlink exec function (but this time providing the pointer
because it is used later), so it makes sense to do the same thing in the
poll function. Equal check is also done in the panel poll function, so
now these are all in sync.
Part of T87681.
Maniphest Tasks: T87681
Differential Revision: https://developer.blender.org/D11041
|
|
Clearing the parent from the UI using the X (or from python) clears the
`parsubstr` and set `partype` back to `PAROBJECT`.
Using the Clear Parent operator would leave the `parsubstr` (and thus
`parent_bone`) untouched even though this operator claims to "clear
parenting relationship completely" (it also removes parent deform
modifiers for example).
So now, also clear `parsubstr` and set back to `PAROBJECT` [which is
default].
Maniphest Tasks: T88498
Differential Revision: https://developer.blender.org/D11503
|
|
Was reported for a file which does not have an active track set in
AnimData even though it was in strip twek mode (but this was accessed in
is_nlatrack_evaluatable()).
Root cause for this is not totally clear, but I assume the situation is
described as part T87681 (and is fixed in D11052).
This patch here just prevents the crash for files that are already in the
borked state.
Reviewers: sybren
Maniphest Tasks: T89805
Differential Revision: https://developer.blender.org/D12085
|
|
Those were caused by various tools used on degenerate geometry, see
T79775.
Note that fixes are as low-level as possible, to ensure they cover as
much as possible of unreported issues too.
We still probably have many more of those hidden in BLI_math though.
|
|
It was projecting from the stroke position.
The behavior has changed in {rB5400be9ffee2}.
|
|
Implementation is incorrect compared to Cycles/Eevee.
Reported by @DrDubosc in comments of T88922.
Differential Revision: https://developer.blender.org/D12029
|
|
Resolves T89931
|
|
The crash occurred calling because mesh_get_eval_final in edit-mode
freed all derived mesh data without tagging the object for updating.
However meshes in edit-mode weren't meant to be used as knife-project
source-data, adding support for multi object edit-mode caused this.
|
|
ID data-blocks that could be accessed from Python and weren't freed
using BKE_id_free_ex did not release the Python reference count.
Add BKE_libblock_free_data_py function to clear the Python reference
in this case.
Add asserts to ensure no Python reference is held in situations
when ID's are copied for internal use (not exposed through the RNA API),
to ensure these kinds of leaks don't go by unnoticed again.
|
|
Disable wrapping when "scale to fit" is used, assert the error is
small so an invalid scale-to-fit value wont go by unnoticed.
|
|
|
|
The problem was introduced with Bezier modification because the selection code was using the original stroke and not the evaluated version.
|
|
|
|
It wasn't obvious this didn't free the memory of the mesh it's self
leading to memory leaks.
|
|
|
|
Error in 2788b0261cb7d33a2f6f2978ff4f55bb4987edae.
|
|
|
|
Backporting this fixes T90599.
|
|
|
|
Originally this was caused by {rBc71a8e837616}.
Above commit wasnt renaming RNA definitions, but not the occurances were
RNA values were set.
In 3.0, we had improvements to pose-sliding tools (D9054) where this was
somewhat ironed out (only partially, see D12187).
But since the pose-sliding improvements are not part of 2.93, we have to
correct this in 2.93 ONLY.
Maniphest Tasks: T89027
Differential Revision: https://developer.blender.org/D12191
|
|
Code freeing the array would not properly reset its length value to
zero.
Note that this corrupted data could also be saved in .blend files, so
had to bump fileversion and add some doversion code too.
Fix T90166: crash when creating a liboverride.
|
|
cases.
This was apparently done in two places only, with a very cryptic comment
(`/* for raw_access, untested */`), and... I cannot see how returning a
non-zero length value for an array that does not exist or is not
accessible at least, would be anything but an obvious source of issues.
Note that both commits adding those lines are from stone ages (2009):
rBcbc2c1886dee and rB50e3bb7f5f34.
|