blender
/
blender
131
398
Fork 575
Code Issues 6.2k Pull Requests 748 Projects 19 Wiki Activity

Motion tracking marker's search area is not expanding with tracker, requiring constant manual scaling up. #107487

New Issue
Open
opened 2023-04-30 23:32:01 +02:00 by michael campbell · 13 comments
michael campbell commented 2023-04-30 23:32:01 +02:00
Copy Link

System Information
Operating system: Windows-10-10.0.19044-SP0 64 Bits
Graphics card: NVIDIA GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 526.98

Blender Version
Broken: version: 3.5.1 Release Candidate, branch: blender-v3.5-release, commit date: 2023-04-21 11:31, hash: 93dac7da2c6a
Worked: Unsure

Short description of error
motion tracking marker's search area is shrinking during tracking, requiring constant pause and manual scale back up.

Exact steps for others to reproduce the error

  • Open blender, go to motion tracking workspace
  • load attached clip
    • check why first one loads in upside down too if you can
  • set global motion model to loc rot scale
  • add some trackers with the detect features operator
  • make sure search is enabled in the clip display settings (can't paste images here for some reason)
  • set tracking speed to realtime so you can see it happening.
  • track forward

The search area shrinks until it's touching the pattern area, resulting in less accuracy and requirement for manual re-scaling. This is exceptionally problematic with many markers, particularly as there's no way to re-scale the search area of multiple markers simultaneously, and it means you always have to track in realtime to ensure the problem is recognised.

The first thought might be this is expected because it's supposed to scale in this mode, but this seems unrelated to the expected scaling, because it happens when patterns are increasing in size, so if anything it should be expanding. Also if that were the case, then it would retain it's relative scale to the shrinking pattern area. I wonder if in the code perhaps the search area has accidentally been set to contract when the pattern areas grows and vice versa.

**System Information** Operating system: Windows-10-10.0.19044-SP0 64 Bits Graphics card: NVIDIA GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 526.98 **Blender Version** Broken: version: 3.5.1 Release Candidate, branch: blender-v3.5-release, commit date: 2023-04-21 11:31, hash: `93dac7da2c6a` Worked: Unsure **Short description of error** motion tracking marker's search area is shrinking during tracking, requiring constant pause and manual scale back up. **Exact steps for others to reproduce the error** - Open blender, go to motion tracking workspace - load attached clip - check why first one loads in upside down too if you can - set global motion model to loc rot scale - add some trackers with the detect features operator - make sure search is enabled in the clip display settings (can't paste images here for some reason) - set tracking speed to realtime so you can see it happening. - track forward The search area shrinks until it's touching the pattern area, resulting in less accuracy and requirement for manual re-scaling. This is exceptionally problematic with many markers, particularly as there's no way to re-scale the search area of multiple markers simultaneously, and it means you always have to track in realtime to ensure the problem is recognised. The first thought might be this is expected because it's supposed to scale in this mode, but this seems unrelated to the expected scaling, because it happens when patterns are increasing in size, so if anything it should be expanding. Also if that were the case, then it would retain it's relative scale to the shrinking pattern area. I wonder if in the code perhaps the search area has accidentally been set to contract when the pattern areas grows and vice versa.
IMG_2315.MOV
26 MiB
michael campbell added the
Priority
Normal
Type
Report
Status
Needs Triage
 labels 2023-04-30 23:32:02 +02:00
YimingWu commented 2023-05-01 07:06:13 +02:00
Member
Copy Link

Hi @3di , I could not reproduce "search area shrinks", but when using global motion model to loc rot scale, the patter would grow as the viewpoint moves, and when some patterns grows to fill the search area, it stops tracking. Is that what you are experiencing? As in "search area stays the same size but pattern size grows"?

Hi @3di , I could not reproduce "search area shrinks", but when using `global motion model to loc rot scale`, the patter would grow as the viewpoint moves, and when some patterns grows to fill the search area, it stops tracking. Is that what you are experiencing? As in "search area stays the same size but pattern size grows"?
YimingWu added
Status
Needs Information from User
Interest
Motion Tracking
 and removed
Status
Needs Triage
 labels 2023-05-01 07:07:02 +02:00
YimingWu commented 2023-05-01 07:09:06 +02:00
Member
Copy Link

The video up side down issue is probably blender didn't handle metatag rotation correctly. ffprob -i on that file reported:

  Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 1920x1080, 15603 kb/s, 29.98 fps, 29.97 tbr, 600 tbn, 1200 tbc (default)
    Metadata:
      rotate          : 180
      creation_time   : 2023-04-24T18:38:11.000000Z
      handler_name    : Core Media Video
      vendor_id       : [0][0][0][0]
      encoder         : H.264
    Side data:
      displaymatrix: rotation of -180.00 degrees

This rotation issue could be a similar mechanism of #93588.

The video up side down issue is probably blender didn't handle metatag rotation correctly. `ffprob -i` on that file reported: ``` Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 1920x1080, 15603 kb/s, 29.98 fps, 29.97 tbr, 600 tbn, 1200 tbc (default) Metadata: rotate : 180 creation_time : 2023-04-24T18:38:11.000000Z handler_name : Core Media Video vendor_id : [0][0][0][0] encoder : H.264 Side data: displaymatrix: rotation of -180.00 degrees ``` This rotation issue could be a similar mechanism of #93588.
YimingWu added the
Module
VFX & Video
Interest
Video Sequencer
 labels 2023-05-01 07:09:48 +02:00
michael campbell commented 2023-05-01 09:29:55 +02:00
Author
Copy Link

Hi @3di , I could not reproduce "search area shrinks", but when using global motion model to loc rot scale, the patter would grow as the viewpoint moves, and when some patterns grows to fill the search area, it stops tracking. Is that what you are experiencing? As in "search area stays the same size but pattern size grows"?

ah ok, this could very well be the problem actually yes. So really it needs the search area to grow/shrink in unison with the pattern area, so it maintains it's relative size. Otherwise you have to manually re-scale hundreds of markers.

> Hi @3di , I could not reproduce "search area shrinks", but when using `global motion model to loc rot scale`, the patter would grow as the viewpoint moves, and when some patterns grows to fill the search area, it stops tracking. Is that what you are experiencing? As in "search area stays the same size but pattern size grows"? ah ok, this could very well be the problem actually yes. So really it needs the search area to grow/shrink in unison with the pattern area, so it maintains it's relative size. Otherwise you have to manually re-scale hundreds of markers.
YimingWu commented 2023-05-01 09:37:01 +02:00
Member
Copy Link

@3di In that case I think it's a reasonable issue. I'll confirm it and see if video guys have any input on this.

@3di In that case I think it's a reasonable issue. I'll confirm it and see if video guys have any input on this.
YimingWu added
Status
Confirmed
 and removed
Status
Needs Information from User
 labels 2023-05-01 09:37:11 +02:00
YimingWu changed title from motion tracking marker's search area is shrinking during tracking, requiring constant pause and manual scale back up. to Motion tracking marker's search area is not expanding with tracker, requiring constant manual scaling up. 2023-05-01 09:37:48 +02:00
Sergey Sharybin commented 2023-05-01 11:22:07 +02:00
Owner
Copy Link

This is indeed annoying, but the exact strategy of when and how to scale is not really clear. The search area can not be scaled proportionally to the pattern area: doing so will quickly make the search area unreasonably huge.

A quick quality life improvement could be to ensure some amount of padding between the pattern and search area after tracking step.

@sebastian_k Does this sound reasonable to you?

In a more ideal world the search would need to be scaled according to a detected motion, but this is more in the realms of working on an automated tracker than a bug fix.

This is indeed annoying, but the exact strategy of when and how to scale is not really clear. The search area can not be scaled proportionally to the pattern area: doing so will quickly make the search area unreasonably huge. A quick quality life improvement could be to ensure some amount of padding between the pattern and search area after tracking step. @sebastian_k Does this sound reasonable to you? In a more ideal world the search would need to be scaled according to a detected motion, but this is more in the realms of working on an automated tracker than a bug fix.
Sebastian Koenig commented 2023-05-01 12:52:08 +02:00
Member
Copy Link

@Sergey I would actually love this! Especially if the padding is maintained when the pattern shrinks again (or grows). And also, when using perspective or affine the pattern can become extremely long and stretched (often it still tracks fine though). In that case the search should not grow unreasonably large. Maybe some kind of padding average can be used or so?

@Sergey I would actually love this! Especially if the padding is maintained when the pattern shrinks again (or grows). And also, when using perspective or affine the pattern can become extremely long and stretched (often it still tracks fine though). In that case the search should not grow unreasonably large. Maybe some kind of padding average can be used or so?
Blender Bot added
Status
Archived
 and removed
Status
Confirmed
 labels 2023-05-01 12:52:11 +02:00
Sebastian Koenig commented 2023-05-01 12:53:10 +02:00
Member
Copy Link

Oops, I’m sorry, didn’t mean to close this.

Oops, I’m sorry, didn’t mean to close this.
Blender Bot added
Status
Needs Triage
 and removed
Status
Archived
 labels 2023-05-01 12:53:13 +02:00
Pratik Borhade added
Status
Confirmed
 and removed
Status
Needs Triage
 labels 2023-05-01 12:54:20 +02:00
Sergey Sharybin commented 2023-05-01 17:22:53 +02:00
Owner
Copy Link

Especially if the padding is maintained when the pattern shrinks again

Think this is doable. Kind of to maintain previously keyframed search size.

When using perspective or affine the pattern can become extremely long and stretched

Yeah,, this is a concern. Not sure what you mean by padding average though.

A proper solution I think is to constraint the pattern area from becoming collapsing to singularity.

> Especially if the padding is maintained when the pattern shrinks again Think this is doable. Kind of to maintain previously keyframed search size. > When using perspective or affine the pattern can become extremely long and stretched Yeah,, this is a concern. Not sure what you mean by padding average though. A proper solution I think is to constraint the pattern area from becoming collapsing to singularity.
Sergey Sharybin added
Type
Bug
 and removed
Type
Report
 labels 2023-05-01 17:23:39 +02:00
Sergey Sharybin self-assigned this 2023-05-01 17:23:43 +02:00
michael campbell commented 2023-05-01 18:30:40 +02:00
Author
Copy Link

Maybe something like this:

for marker in current_frame.markers:

    max_search = bpy.context.scene.max_search 
    min_search = bpy.context.scene.min_search
    original_pattern_bounds = marker.original_size.bounding_box
    current_pattern_bounds = marker.current_size.bounding_box
    original_search_size = marker.original_search_size
    search_ratio_x = original_search_size[0] / original_pattern_bounds[0]
    search_ration_y = original_search_size[1] / original_pattern_bounds[1]

    current_search_size = marker.current_search.size

    new_search_size_x = current_pattern_bounds[0] * search_ratio_x
    new_search_size_y = current_pattern_bounds [1] * search_ration_y

    if ((new_search_size_x,new_search_size_y) < (max_search[0], max_search[1]) and (new_search_size_x,new_search_size_y) > (min_search[0], min_search[1])):
        marker.current_search_size = (new_search_size_x,new_search_size_y)
    else:
        #pattern is either too large or too small.  if it's too small then there are too few pixels for accuracy, if it's too large then there are more pixels than necessary
        
        #set pattern size to original size at the same point.  so if it's to small, this'll expand the pattern area to sufficient pixels to recognise a new pattern, or if too big, this'll shrink back down to sufficient pixels to recognise a new pattern in the same spot.

        marker.pattern_size = marker.original_size
        marker.search_size = marker.original_search_size

        #update pattern
        marker.update_pattern() #if the new pattern isn't very trackable, then nothing lost, because it would have failed with the old pattern anyway at this point.

Then it'll keep going while it can without any user intervention.

What would also be nice is as soon as one becomes disabled during tracking, then automatically create a new one at the most contrasty point of the previous frame, then track just the new marker from the previous frame to the current, before continuing to track all markers again.

Maybe something like this: ```Py for marker in current_frame.markers: max_search = bpy.context.scene.max_search min_search = bpy.context.scene.min_search original_pattern_bounds = marker.original_size.bounding_box current_pattern_bounds = marker.current_size.bounding_box original_search_size = marker.original_search_size search_ratio_x = original_search_size[0] / original_pattern_bounds[0] search_ration_y = original_search_size[1] / original_pattern_bounds[1] current_search_size = marker.current_search.size new_search_size_x = current_pattern_bounds[0] * search_ratio_x new_search_size_y = current_pattern_bounds [1] * search_ration_y if ((new_search_size_x,new_search_size_y) < (max_search[0], max_search[1]) and (new_search_size_x,new_search_size_y) > (min_search[0], min_search[1])): marker.current_search_size = (new_search_size_x,new_search_size_y) else: #pattern is either too large or too small. if it's too small then there are too few pixels for accuracy, if it's too large then there are more pixels than necessary #set pattern size to original size at the same point. so if it's to small, this'll expand the pattern area to sufficient pixels to recognise a new pattern, or if too big, this'll shrink back down to sufficient pixels to recognise a new pattern in the same spot. marker.pattern_size = marker.original_size marker.search_size = marker.original_search_size #update pattern marker.update_pattern() #if the new pattern isn't very trackable, then nothing lost, because it would have failed with the old pattern anyway at this point. ``` Then it'll keep going while it can without any user intervention. What would also be nice is as soon as one becomes disabled during tracking, then automatically create a new one at the most contrasty point of the previous frame, then track just the new marker from the previous frame to the current, before continuing to track all markers again.
👍 1
Sergey Sharybin commented 2023-05-01 18:44:06 +02:00
Owner
Copy Link

See my initial reply here. It is not ideal to scale search area proportionally to the pattern. The amount of movement of a feature is not linearly dependent on the size of the feature. Overestimating the size of the search area at a best will cause considerable performance drop, and in average it will degrade quality of track. That is why I was talking about padding and not scaling.

See my initial reply here. It is not ideal to scale search area proportionally to the pattern. The amount of movement of a feature is not linearly dependent on the size of the feature. Overestimating the size of the search area at a best will cause considerable performance drop, and in average it will degrade quality of track. That is why I was talking about padding and not scaling.
michael campbell commented 2023-05-01 18:55:38 +02:00
Author
Copy Link

that's what the user definable max_search_size would be for. If it fails due to too much movement, then it would fail anyway. The above is if it's failing unnecessarily due to the search size being insufficient for the expanded pattern size rather than movement beyond the bounds of the search size.

that's what the user definable max_search_size would be for. If it fails due to too much movement, then it would fail anyway. The above is if it's failing unnecessarily due to the search size being insufficient for the expanded pattern size rather than movement beyond the bounds of the search size.
michael campbell commented 2023-05-01 19:01:49 +02:00
Author
Copy Link

it basically keeps the search size relative to the pattern until unfeasable (either because the pattern and search size have grown too big for good performance, or if the pattern has shrunk to too few pixels for a recognisable pattern), then sets the marker pattern and search back to the original dimensions and registers a new pattern in the same location for the following frames, to ensure performance. It's doing what otherwise has to be done manually.

I guess it's similar to what happens with match set to previous frame, except it always ensures the pattern doesn't have too many or too few pixels. Always keeping the search area relative within the bounds of good performance.

it basically keeps the search size relative to the pattern until unfeasable (either because the pattern and search size have grown too big for good performance, or if the pattern has shrunk to too few pixels for a recognisable pattern), then sets the marker pattern and search back to the original dimensions and registers a new pattern in the same location for the following frames, to ensure performance. It's doing what otherwise has to be done manually. I guess it's similar to what happens with match set to previous frame, except it always ensures the pattern doesn't have too many or too few pixels. Always keeping the search area relative within the bounds of good performance.
michael campbell commented 2023-05-01 19:24:52 +02:00
Author
Copy Link

imagine if you have 10 markers whose pattern has grown to the bounds of the search area. Currently you have to select all markers and scale them back down to register the new pattern, but the horrible bit is, you then have to re-expand the search area one marker at a time by dragging the little triangle. With a hundred markers, it's tear inducing.

You can't use the alt enter method in the search size textbox, because not all markers search areas have changed by the same amount.

imagine if you have 10 markers whose pattern has grown to the bounds of the search area. Currently you have to select all markers and scale them back down to register the new pattern, but the horrible bit is, you then have to re-expand the search area one marker at a time by dragging the little triangle. With a hundred markers, it's tear inducing. You can't use the alt enter method in the search size textbox, because not all markers search areas have changed by the same amount.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
main
brush-assets-project
fix-121021
blender-v4.1-release
blender-v3.3-release
blender-v3.6-release
universal-scene-description
blender-v3.6-temp_wmoss_animrig_public
temp-sculpt-dyntopo
gpencil-next
anim/animation-id-113594
blender-v4.0-release
blender-projects-basics
bridge-curves
sculpt-blender
asset-browser-frontend-split
asset-shelf
tmp-usd-python-mtl
tmp-usd-3.6
blender-v3.5-release
blender-v2.93-release
realtime-clock
sculpt-dev
bevelv2
xr-dev
v4.1.1
v3.6.11
v3.3.18
v4.1.0
v3.3.17
v3.6.10
v3.6.9
v3.3.16
v3.6.8
v3.6.7
v3.3.14
v4.0.2
v4.0.1
v4.0.0
v3.6.5
v3.3.12
v3.6.4
v3.6.3
v3.3.11
v3.6.2
v3.3.10
v3.6.1
v3.3.9
v3.6.0
v3.3.8
v3.3.7
v2.93.18
v3.5.1
v3.3.6
v2.93.17
v3.5.0
v2.93.16
v3.3.5
v3.3.4
v2.93.15
v2.93.14
v3.3.3
v2.93.13
v2.93.12
v3.4.1
v3.3.2
v3.4.0
v3.3.1
v2.93.11
v3.3.0
v3.2.2
v2.93.10
v3.2.1
v3.2.0
v2.83.20
v2.93.9
v3.1.2
v3.1.1
v3.1.0
v2.83.19
v2.93.8
v3.0.1
v2.93.7
v3.0.0
v2.93.6
v2.93.5
v2.83.18
v2.93.4
v2.93.3
v2.83.17
v2.93.2
v2.93.1
v2.83.16
v2.93.0
v2.83.15
v2.83.14
v2.83.13
v2.92.0
v2.83.12
v2.91.2
v2.83.10
v2.91.0
v2.83.9
v2.83.8
v2.83.7
v2.90.1
v2.83.6.1
v2.83.6
v2.90.0
v2.83.5
v2.83.4
v2.83.3
v2.83.2
v2.83.1
v2.83
v2.82a
v2.82
v2.81a
v2.81
v2.80
v2.80-rc3
v2.80-rc2
v2.80-rc1
v2.79b
v2.79a
v2.79
v2.79-rc2
v2.79-rc1
v2.78c
v2.78b
v2.78a
v2.78
v2.78-rc2
v2.78-rc1
v2.77a
v2.77
v2.77-rc2
v2.77-rc1
v2.76b
v2.76a
v2.76
v2.76-rc3
v2.76-rc2
v2.76-rc1
v2.75a
v2.75
v2.75-rc2
v2.75-rc1
v2.74
v2.74-rc4
v2.74-rc3
v2.74-rc2
v2.74-rc1
v2.73a
v2.73
v2.73-rc1
v2.72b
2.72b
v2.72a
v2.72
v2.72-rc1
v2.71
v2.71-rc2
v2.71-rc1
v2.70a
v2.70
v2.70-rc2
v2.70-rc
v2.69
v2.68a
v2.68
v2.67b
v2.67a
v2.67
v2.66a
v2.66
v2.65a
v2.65
v2.64a
v2.64
v2.63a
v2.63
v2.61
v2.60a
v2.60
v2.59
v2.58a
v2.58
v2.57b
v2.57a
v2.57
v2.56a
v2.56
v2.55
v2.54
v2.53
v2.52
v2.51
v2.50
v2.49b
v2.49a
v2.49
v2.48a
v2.48
v2.47
v2.46
v2.45
v2.44
v2.43
v2.42a
v2.42
v2.41
v2.40
v2.37a
v2.37
v2.36
v2.35a
v2.35
v2.34
v2.33a
v2.33
v2.32
v2.31a
v2.31
v2.30
v2.28c
v2.28a
v2.28
v2.27
v2.26
v2.25
Labels
Clear labels   
Interest
Alembic

  
Interest
Animation & Rigging

  
Interest
Asset Browser

  
Interest
Asset Browser Project Overview

  
Interest
Audio

  
Interest
Automated Testing

  
Interest
Blender Asset Bundle

  
Interest
BlendFile

  
Interest
Collada

  
Interest
Compatibility
This issue affects/is about backward or forward compatibility

  
Interest
Compositing

  
Interest
Core

  
Interest
Cycles

  
Interest
Dependency Graph

  
Interest
Development Management

  
Interest
EEVEE

  
Interest
EEVEE & Viewport

  
Interest
Freestyle

  
Interest
Geometry Nodes

  
Interest
Grease Pencil

  
Interest
ID Management

  
Interest
Images & Movies

  
Interest
Import Export

  
Interest
Line Art

  
Interest
Masking

  
Interest
Metal

  
Interest
Modeling

  
Interest
Modifiers

  
Interest
Motion Tracking

  
Interest
Nodes & Physics

  
Interest
OpenGL

  
Interest
Overlay

  
Interest
Overrides

  
Interest
Performance

  
Interest
Physics

  
Interest
Pipeline, Assets & IO

  
Interest
Platforms, Builds & Tests

  
Interest
Python API

  
Interest
Render & Cycles

  
Interest
Render Pipeline

  
Interest
Sculpt, Paint & Texture

  
Interest
Text Editor

  
Interest
Translations

  
Interest
Triaging

  
Interest
Undo

  
Interest
USD

  
Interest
User Interface

  
Interest
UV Editing

  
Interest
VFX & Video

  
Interest
Video Sequencer

  
Interest
Virtual Reality

  
Interest
Vulkan

  
Interest
Wayland
Issues relating to Wayland windowing support.

  
Interest
Workbench

  
Interest: X11

Issues relating to Xorg/X11 support.

  
Legacy
Blender 2.8 Project

  
Legacy
Milestone 1: Basic, Local Asset Browser

  
Legacy
OpenGL Error

  
Meta
Good First Issue

  
Meta
Papercut

  
Meta
Retrospective

  
Meta
Security
Issues relating to security: https://wiki.blender.org/wiki/Process/Vulnerability_Reports

  
Module
Animation & Rigging

  
Module
Core

  
Module
Development Management

  
Module
EEVEE & Viewport

  
Module
Grease Pencil

  
Module
Modeling

  
Module
Nodes & Physics

  
Module
Pipeline, Assets & IO

  
Module
Platforms, Builds & Tests

  
Module
Python API

  
Module
Render & Cycles

  
Module
Sculpt, Paint & Texture

  
Module
Triaging

  
Module
User Interface

  
Module
VFX & Video

  
Platform
FreeBSD

  
Platform
Linux

  
Platform
macOS

  
Platform
Windows

  
Priority
High

  
Priority
Low

  
Priority
Normal

  
Priority
Unbreak Now!

  
Status
Archived

  
Status
Confirmed

  
Status
Duplicate

  
Status
Needs Info from Developers

  
Status
Needs Information from User

  
Status
Needs Triage

  
Status
Resolved

  
Type
Bug

  
Type
Design

  
Type
Known Issue

  
Type
Patch

  
Type
Report

  
Type
To Do

No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
Sergey Sharybin
4 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#107487
No description provided.
Delete Branch "%!s(<nil>)"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?