Age | Commit message (Collapse) | Author |
|
The BVHTree was erroneously marked as not cached.
|
|
Pablo and William agreed that the main purpose of the layout should be
to list files in a way that it's easy see which files were
created/modified when. Previously it was set to "Long List" to show the
modification time, now the vertical list is much better suited. The time
is shown anyway.
|
|
|
|
For the default keymap we were only using the regular toolshelf
operator, doing this for the industry compatible keymap too now (we
could even remove it there, we don't use it in other editors).
Since we "now" have proper operators for toggling regions, this specific
one is totally redundant.
|
|
So far the file browser code had some lazy creation for the tool region,
even though it should always be there. The only reason I can see for
this is compatiblity. So I simply added versioning code to add the
region in case it's not there. Now we should be able to savely assume
the tool region to be there, whithout any unusual lazy-creation.
|
|
This makes it so that regions only needed when the file browser is
invoked as an operation (e.g. Ctrl+O rather than a regular editor) are
lazy created then, and removed if the file browser is changed into a
regular editor then (e.g. Ctrl+O over regular file browser editor ->
Cancel).
That should remove some troublesome assumptions and makes versioning
redundant.
It also fixes the issue of an empty execute region at the bottom after
cancelling a file operation invoked from a regular file browser editor.
|
|
Differential Revision: https://developer.blender.org/D5716
|
|
Differential Revision: https://developer.blender.org/D5744
|
|
Adjust empty menu check to skip the menu title.
|
|
|
|
Differential Revision: https://developer.blender.org/D5847
|
|
|
|
This would happen when opening a file browser as regular editor, opening
a temporary file browser from there (e.g. Ctrl+O) and cancelling the
operation.
In some cases this would cause most of the editor to be filled with an
empty operator options region:
* Go to Shading workspace
* File -> Append
* Cancel
|
|
The new paint cursor (introduced in rBe0c792135adf) mixed 3d and 2d
drawing leading to asserts [e.g. when tablet pressure sensitivity was
enabled for size, see D5820 also].
We could get away with always drawing in 3D [using vertformat with
comp_len 3 / GPU_SHADER_3D_UNIFORM_COLOR / imm_draw_circle_wire_3d],
even if in the Image Editor, but this patch clearly separates what is
drawn in 3d and what is in 2d.
part of T69957
Reviewers: jbakker
Differential Revision: https://developer.blender.org/D5836
|
|
When setting an object draw type to Solid it always used the Material
color mode. This change only sets the material color when the viewport
is set to display textures.
|
|
|
|
|
|
|
|
Each node tree type now has it's own quick-favorites.
|
|
|
|
|
|
Resolves T64320
|
|
|
|
|
|
Steps to reproduce were:
* Open Preferences in a new window (Edit -> Preferences)
* Set file browsers to open fullscreen (Interface->Editors->Temporary
Windows)
* Open a file browser in the Preferences (e.g. Add-ons -> Install)
The file browser would be opened in the parent window, rather than the
preferences.
|
|
The problem is that `DST.vmempool->passes` was not cleared, so passes
previously created in another drw function were being reused.
|
|
|
|
If the file browser was opened from an existing file browser editor
(using File -> Append would make the mouse hover the file browser in the
Shading workspace), we need special handling for closing the fullscreen
area.
This change brings back the old way of handling fullscreen closing.
|
|
Changes "Add" to "Construct" to be consistent with the other
primitive mesh add operations.
|
|
This fixes both the attribute and the uvmap node. Some other nodes are not
supported but I think it makes little sense.
|
|
Not exposed to Python API yet, this should get more detailed testing with different
layouts before that happens.
Ref T69652
|
|
I'm not sure how a .blend file could get into this state, but apparently
for some files saved with versions of Blender after the file browser
changes, the execute region would not have been created. File browser
code assumes this region to be there however.
Luckily I found a file with which I could recreate the issue. My guess
is that the error only happens with files that were stored before
certain versioning fixes were done after the file browser redesign.
To fix this, we just let the versioning code for the execute region run
even with newest files. We can run this safely, it only acts if the
execute region actually doesn't exist.
|
|
Creases are stored by the vertex indices of the edges. Sometimes they
were stored with (v1, v2) when the edge itself was stored with (v2, v1).
We now search for both orientations.
Sorting the vertex indices before searching avoids the second search
altogether when loading the example file of T70021.
|
|
|
|
|
|
time change
followup to 815ca2310fb4, this one fixes the RNA_MeshLoopColor case, adds
RNA_VertexGroupElement and RNA_LatticePoint.
coop with @sergey, thx.
Fixes T68666
|
|
Redraw the outliner when text data-blocks are created and unlinked. This
also fixes a crash when unlinking.
|
|
Error was introduced in 34143e45104b.
|
|
The parent hairs were written to Alembic even when the 'Parent Particles'
checkbox (`use_parent_particles`) was disabled. In this case the parent
hairs were not correct in Blender's memory, and thus also not correct in
the exported Alembic file. The Alembic exporter now respects this setting
and doesn't write the parent hairs when 'Parent Particles' is off.
|
|
Do proper segment clamping to a proper value.
Thanks Brecht for pair-coding!
|
|
The problem was the unit matrix was not set in the uniform variable.
|
|
This solution only reuses the performance workaround made for Intel.
But the original problem was not solved.
Not much we can do to solve it.
|
|
Python3.7 is still fairly recent, not all distro use it as system python
yet, fallback to code compatible up to py3.5.
Also, often distro builds of Blender do not have the buildinfo, in that
case fallback to `SOURCE_DATE_EPOCH` envvar, and as last resort to
current time, as in orig patch D5756 (we still use blender builddate
when available).
Issues raised in recent own rBcd5c70630318.
|
|
change
|
|
Importing an Alembic file with a relative path is now also possible.
|
|
Steps to reproduce were:
* Add a new collection
* Put an object into it
* Exclude the selection (the checkbox in front of the name)
* Enable "Local Collections" in any viewport
-> Crash
Did not skip the excluded collections, causing an unsuccessful object
lookup (returned null-pointer).
|
|
This behavior was accidentally changed in 3e6f37b9, now it works compatible
with 2.79 again.
|
|
Units should be explicit, and not left to be guessed by the reader.
The field is only used in a single C file, so it's a relatively low-risk
change.
|
|
The problematic video from T68091 clearly has an invalid stream duration
(it would be 55 centuries long if interpreted at 30 FPS, and given that
it was recorded with an Android 9 device, it's unlikely that recording
started that long ago). I've added a heuristic to check the stream
duration against the container duration; if the stream is more than 4x
longer than the container, Blender now falls back to the container
duration.
We could use MIN(stream duration, container duration), but there might
be video files out there where the container duration is less precise
than the stream duration; they are measured in different units of time
(microseconds for the container vs. frames for the stream).
Includes a unit test for the above heuristic.
Reviewed by: jbakker
Differential revision: https://developer.blender.org/D5853
|
|
This was introduced in FFmpeg lavf 55.1.100 in 2013. For systems that are
still on LibAV or older FFmpeg there is a fallback implementation that
performs the same guess as we did before in `av_get_r_frame_rate_compat()`.
|