OpenGL render bugs with JACK #65584

Closed
opened 2019-06-07 01:56:42 +02:00 by Casey Connor · 8 comments

Operating system: Kubuntu 18.10, 4.18.0-20-generic #21-Ubuntu SMP Mon May 6 18:45:52 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Graphics card: NVIDIA Corporation GP106 [GeForce GTX 1060 6GB] (rev a1)
Broken: 2.80, 8fa65ed31b June 05, 23:41:04

  • start 2.80 with fresh config directory
  • open default cube scene
  • change audio system to JACK in preferences
  • in properties, change render "Output" settings to disable the "overwrite" option
  • in the timeline, under the "Playback" drop down, enable AV Sync
  • skip to a frame in the middle of the timeline (e.g. 105)
  • in the viewport, in View menu, choose "Viewport Render Animation"

Bug 1: observe that it delays for a while before beginning (maybe not a bug, but seemed pretty long)
Bug 2: an error pops up saying "skipping existing frame /tmp/0105"; this error occasionally appears again for subsequent frames, but usually not
Bug 3: rendering is very slow (1-2 fps, and my /tmp is a ram disk; this is true regardless of JACK/no-JACK, AV Sync or No Sync, etc)
Bug 4: (maybe just a UI paper cut?) without changing the start/end of the animation range, there appears to be no way to start an OpenGL render from a given frame unless "AV Sync" and JACK are both used?
Bug 5: (not sure if bug?) enabling/disabling AV Sync, or switching to/from JACK, often causes play cursor to change frames

Operating system: Kubuntu 18.10, 4.18.0-20-generic #21-Ubuntu SMP Mon May 6 18:45:52 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux Graphics card: NVIDIA Corporation GP106 [GeForce GTX 1060 6GB] (rev a1) Broken: 2.80, 8fa65ed31b7f June 05, 23:41:04 * start 2.80 with fresh config directory * open default cube scene * change audio system to JACK in preferences * in properties, change render "Output" settings to disable the "overwrite" option * in the timeline, under the "Playback" drop down, enable AV Sync * skip to a frame in the middle of the timeline (e.g. 105) * in the viewport, in View menu, choose "Viewport Render Animation" Bug 1: observe that it delays for a while before beginning (maybe not a bug, but seemed pretty long) Bug 2: an error pops up saying "skipping existing frame /tmp/0105"; this error occasionally appears again for subsequent frames, but usually not Bug 3: rendering is very slow (1-2 fps, and my /tmp is a ram disk; this is true regardless of JACK/no-JACK, AV Sync or No Sync, etc) Bug 4: (maybe just a UI paper cut?) without changing the start/end of the animation range, there appears to be no way to start an OpenGL render from a given frame unless "AV Sync" and JACK are both used? Bug 5: (not sure if bug?) enabling/disabling AV Sync, or switching to/from JACK, often causes play cursor to change frames
Author

Added subscriber: @clepsydrae

Added subscriber: @clepsydrae

Added subscribers: @neXyon, @mano-wii

Added subscribers: @neXyon, @mano-wii
Joerg Mueller was assigned by Germano Cavalcante 2019-07-01 19:41:47 +02:00

I don't see that JACK option on my end.
@neXyon, Audio seems to be your area.

I don't see that `JACK` option on my end. @neXyon, `Audio` seems to be your area.
Joerg Mueller removed their assignment 2019-07-07 14:56:15 +02:00
Member

Added subscriber: @Sergey

Added subscriber: @Sergey
Member

After spending some time playing around with this I can make the following observations:

  • With the overwrite option disabled, it only renders the first time. As soon as the files exist nothing happens and I get a "blank", i.e. gray grid window. I guess this is expected since files exist and blender was disallowed to overwrite them, so why should it render something? Both rendering and in the second case non-rendering start immediately, so I can't reproduce bug 1. Do you have the JACK server running before you do that? Does it only happen the first time? It might be that starting jack the first time you run this takes a while.
  • I also didn't encounter bug 2, neither during the first nor subsequent runs. If that bug (still?) exists it sounds like it starts rendering at the current frame, then goes back to 1 and incrementally goes from there, encountering the already rendered frame again.
  • Rendering being slow may be a bug, but I have no idea how fast it should be? Also that's independent even of any audio settings, so not really my area.
  • Regarding bug 4, I'm not sure what you mean. I tried to not touch the start/end of the animation range and start the rendering with JACK and "No Sync" and it works just fine, so I also can't reproduce this one.
  • Finally, the last bug 5 is not a bug but expected behaviour. When JACK + AV Sync is used, blender synchronizes via JACK transport which has its own timing. When you thus switch both these options on the cursor position synchronizes with JACK's and that's what you're observing.

May I also ask, what is your reason to use JACK?

In summary: I can't reproduce 1, 2 and 4. Bug 5 is not a bug and bug 3, if it is one is not related to audio, so I'm putting this report up for grabs. Maybe some of the stuff is related to recent changes in the dependency graph and its working with the audio system, so @Sergey might be the person to ask here.

After spending some time playing around with this I can make the following observations: - With the overwrite option disabled, it only renders the first time. As soon as the files exist nothing happens and I get a "blank", i.e. gray grid window. I guess this is expected since files exist and blender was disallowed to overwrite them, so why should it render something? Both rendering and in the second case non-rendering start immediately, so I can't reproduce bug 1. Do you have the JACK server running before you do that? Does it only happen the first time? It might be that starting jack the first time you run this takes a while. - I also didn't encounter bug 2, neither during the first nor subsequent runs. If that bug (still?) exists it sounds like it starts rendering at the current frame, then goes back to 1 and incrementally goes from there, encountering the already rendered frame again. - Rendering being slow may be a bug, but I have no idea how fast it should be? Also that's independent even of any audio settings, so not really my area. - Regarding bug 4, I'm not sure what you mean. I tried to not touch the start/end of the animation range and start the rendering with JACK and "No Sync" and it works just fine, so I also can't reproduce this one. - Finally, the last bug 5 is not a bug but expected behaviour. When JACK + AV Sync is used, blender synchronizes via JACK transport which has its own timing. When you thus switch both these options on the cursor position synchronizes with JACK's and that's what you're observing. May I also ask, what is your reason to use JACK? In summary: I can't reproduce 1, 2 and 4. Bug 5 is not a bug and bug 3, if it is one is not related to audio, so I'm putting this report up for grabs. Maybe some of the stuff is related to recent changes in the dependency graph and its working with the audio system, so @Sergey might be the person to ask here.

Not sure why any of the observed issues will be related on the audio + dependency graph changes.

@clepsydrae, does any of the issues you're reported happen when you set audio system to None/Null?
What if you switch Eevee to Cycles and change number of samples/bounces to 1? Will it affect render performance?

It is also very confusing to have 5 different bugs reported in a single report. Those doesn't seem to belong to the same area, and handling such reports is tricky. It's usually a good idea to report separate issues separately.

Not sure why any of the observed issues will be related on the audio + dependency graph changes. @clepsydrae, does any of the issues you're reported happen when you set audio system to None/Null? What if you switch Eevee to Cycles and change number of samples/bounces to 1? Will it affect render performance? It is also very confusing to have 5 different bugs reported in a single report. Those doesn't seem to belong to the same area, and handling such reports is tricky. It's usually a good idea to report separate issues separately.
Author

Changed status from 'Open' to: 'Archived'

Changed status from 'Open' to: 'Archived'
Casey Connor self-assigned this 2019-07-09 00:32:07 +02:00
Author

I came to respond to all the questions, and I find that I am unable to reproduce most of these issues now, either with the version I was on at the time or the current version. I have no explanation. Sorry for the confusion. I'll post again if I can. (Oddly, rendering is also faster now, perhaps 3-5 fps, and unaffected by JACK.)

I will split the reports out next time; I didn't know if they were large enough issues to merit their own report, especially since the repro steps were identical.

Re: bug #4 -- if I want to start the viewport rendering at e.g. frame 105, it appears that I can not do that unless I change the start position of the animation ("Frame Start / End"). Meaning, the position of the play cursor is irrelevant to the start position of the animation. In my report, I was referring to the fact that having AV Sync enabled and using JACK seemed to "fix" this "bug", because rendering would start where the cursor was. But again, I cannot reproduce this now: now it starts at the beginning (Frame Start) no matter what the settings are.

May I also ask, what is your reason to use JACK?

Last I dealt with my audio config, JACK was necessary to use my audio interface as my OS default interface. (It may no longer be true.)

I came to respond to all the questions, and I find that I am unable to reproduce most of these issues now, either with the version I was on at the time or the current version. I have no explanation. Sorry for the confusion. I'll post again if I can. (Oddly, rendering is also faster now, perhaps 3-5 fps, and unaffected by JACK.) I will split the reports out next time; I didn't know if they were large enough issues to merit their own report, especially since the repro steps were identical. Re: bug #4 -- if I want to start the viewport rendering at e.g. frame 105, it appears that I can not do that unless I change the start position of the animation ("Frame Start / End"). Meaning, the position of the play cursor is irrelevant to the start position of the animation. In my report, I was referring to the fact that having AV Sync enabled and using JACK seemed to "fix" this "bug", because rendering would start where the cursor was. But again, I cannot reproduce this now: now it starts at the beginning (Frame Start) no matter what the settings are. > May I also ask, what is your reason to use JACK? Last I dealt with my audio config, JACK was necessary to use my audio interface as my OS default interface. (It may no longer be true.)
Sign in to join this conversation.
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
No Milestone
No project
No Assignees
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#65584
No description provided.