OBJECT_BAKE flag is true in object_bake_complete handler #119622

New Issue

Open

opened 2024-03-18 13:21:19 +01:00 by Marko Tatalovic · 9 comments

Marko Tatalovic commented

2024-03-18 13:21:19 +01:00

System Information
Operating system: Windows 10
Graphics card: GeForce 2080 TI

Blender Version
Broken: 4.0.2, 9be62e85b7, master, 2023-12-05
Worked: Never afaik (tested on 3.6.8 as well)

Short description of error
bpy.app.is_job_running('OBJECT_BAKE') returns true inside on_bake_completed handler, making it hard to start new bake afterwards, or do anything else.

Exact steps for others to reproduce the error

Open up provided blender file
Run the script
Toogle system console to see the prints.

**System Information** Operating system: Windows 10 Graphics card: GeForce 2080 TI **Blender Version** Broken: 4.0.2, 9be62e85b7, master, 2023-12-05 Worked: Never afaik (tested on 3.6.8 as well) **Short description of error** bpy.app.is_job_running('OBJECT_BAKE') returns true inside on_bake_completed handler, making it hard to start new bake afterwards, or do anything else. **Exact steps for others to reproduce the error** 1. Open up provided blender file 2. Run the script 3. Toogle system console to see the prints.

921 KiB

Marko Tatalovic added the

labels 2024-03-18 13:21:20 +01:00

Germano Cavalcante commented

2024-03-19 00:05:09 +01:00

Member

I can confirm, but I don't think it's a bug.
bpy.app.is_job_running('OBJECT_BAKE') is not necessarily an indication that the image is being baked.
It indicates that the job is running. And since the Bake callbacks are part of the job, it seems to be expected that the job is running when the callbacks are called.

But in any case, I'm tagging the report as Needs Info from Developers.

@Sergey, maybe you can shed some light here?

I can confirm, but I don't think it's a bug. `bpy.app.is_job_running('OBJECT_BAKE')` is not necessarily an indication that the image is being baked. It indicates that the job is running. And since the Bake callbacks are part of the job, it seems to be expected that the job is running when the callbacks are called. But in any case, I'm tagging the report as `Needs Info from Developers`. @Sergey, maybe you can shed some light here?

Germano Cavalcante added

Render & Cycles

Needs Info from Developers

Render Pipeline

and removed

labels 2024-03-19 00:05:33 +01:00

Sergey Sharybin commented

2024-03-19 14:45:37 +01:00

Owner

And since the Bake callbacks are part of the job, it seems to be expected that the job is running when the callbacks are called.

I am a bit confused about this statement. Job's completion/cancellation callback is called from main thread, via wm_job_end, which has BLI_assert_msg(BLI_thread_is_main(), "wm_job_end should only be called from the main thread");.

Probably we can solve the expected behavior in this case by moving wm_job->running = false; prior to the wm_job_end(wm, wm_job); in the wm_jobs_timer. At that point the job is ready, so it is no longer running, and is_job_running shouldn't be returning that the job is running.

> And since the Bake callbacks are part of the job, it seems to be expected that the job is running when the callbacks are called. I am a bit confused about this statement. Job's completion/cancellation callback is called from main thread, via `wm_job_end`, which has `BLI_assert_msg(BLI_thread_is_main(), "wm_job_end should only be called from the main thread");`. Probably we can solve the expected behavior in this case by moving `wm_job->running = false;` prior to the `wm_job_end(wm, wm_job);` in the `wm_jobs_timer`. At that point the job is ready, so it is no longer running, and `is_job_running` shouldn't be returning that the job is running.

Germano Cavalcante commented

2024-03-19 14:54:12 +01:00

Member

For me, the confusion would be in defining what is part of the job: {callbacks before running in multithread; running in multithread; callbacks after running in multithread}.

If, even in the main thread, the callback is part of the job, the job is running... no?

For me, the confusion would be in defining what is part of the job: {callbacks before running in multithread; running in multithread; callbacks after running in multithread}. If, even in the main thread, the callback is part of the job, the job is running... no?

Sergey Sharybin commented

2024-03-19 14:56:43 +01:00

Owner

The callback is called "completed". So it is not very intuitive that something is both "completed" and "running".

The callback is called "completed". So it is not very intuitive that something is both "completed" and "running".

Germano Cavalcante added

and removed

Needs Info from Developers

labels 2024-03-19 15:01:32 +01:00

Germano Cavalcante commented

2024-03-19 15:07:05 +01:00

Member

I think it still falls to the question of definition (what is bake completed? What is job running?)
I'm confirming the issue anyway.
The fix can go either to the definition side, or to when setting wm_job->running = false.

I think it still falls to the question of definition (what is bake completed? What is job running?) I'm confirming the issue anyway. The fix can go either to the definition side, or to when setting `wm_job->running = false`.

Sergey Sharybin commented

2024-03-19 15:18:41 +01:00

Owner

The job itself have completed and running states, and the "bake completed" handler is called from job's completed callback. A bit of a details, but it does affect on the quesrtion a little bit.

In any case, I think it is something where @dr.sybren or @ideasman42 would be best to be asked. The job query API Sybren did, and probably has better understanding of what the expectations are.

The job itself have completed and running states, and the "bake completed" handler is called from job's completed callback. A bit of a details, but it does affect on the quesrtion a little bit. In any case, I think it is something where @dr.sybren or @ideasman42 would be best to be asked. The job query API Sybren did, and probably has better understanding of what the expectations are.

Sybren A. Stüvel commented

2024-03-19 15:45:10 +01:00

Member

I agree with Sergey here. The callback is called "completed" (past tense), and not "completing". The purpose for the job query API was to allow scripts to be notified that background work was done, so that something else can be done after it. Ensuring that wm_job->running = false before calling the 'completed' callback seems like the right way to go for me.

From the script in the example blend file (thanks for providing that, clear examples are always much appreciated):

    try:
        bpy.app.timers.unregister(wait)
    except:
        pass

Please never do this, even in simple example code. Having a bare except: that ignores any exception is bound to catch more than you intend, and can hide very nasty errors. Just have a except WhateverTypeYouExpect: here.

I agree with Sergey here. The callback is called "completed" (past tense), and not "completing". The purpose for the job query API was to allow scripts to be notified that background work was done, so that something else can be done after it. Ensuring that `wm_job->running = false` before calling the 'completed' callback seems like the right way to go for me. ----------- From the script in the example blend file (thanks for providing that, clear examples are always much appreciated): ```python try: bpy.app.timers.unregister(wait) except: pass ``` Please never do this, even in simple example code. Having a bare `except:` that ignores any exception is bound to catch more than you intend, and can hide very nasty errors. Just have a `except WhateverTypeYouExpect:` here.

Marko Tatalovic commented

2024-03-19 16:42:30 +01:00

Author

Thank you for taking the time to address this issue, and a thanks to Sybren for the advice on handling exceptions. Noted!

From my POV as an API user, without going into technical details, current behaviour doesn't make much sense. on_bake_completed could make chaining bakes or doing any "post bake" ops much easier , opposed to using macros or any other means. Right now we have to register timer for every on_bake_completed handler, which makes whole thing messy in my oppinion.

Thank you for taking the time to address this issue, and a thanks to Sybren for the advice on handling exceptions. Noted! From my POV as an API user, without going into technical details, current behaviour doesn't make much sense. on_bake_completed could make chaining bakes or doing any "post bake" ops much easier , opposed to using macros or any other means. Right now we have to register timer for every on_bake_completed handler, which makes whole thing messy in my oppinion.

Marko Tatalovic closed this issue

2024-03-19 16:42:34 +01:00

Blender Bot added

and removed

labels 2024-03-19 16:42:37 +01:00

Marko Tatalovic reopened this issue

2024-03-19 16:47:55 +01:00

Blender Bot added

and removed

labels 2024-03-19 16:47:57 +01:00

Marko Tatalovic commented

2024-03-19 16:48:31 +01:00

Author

Sorry I missclicked "Comment and Close"

Sorry I missclicked "Comment and Close"

Iliya Katushenock added

and removed

labels 2024-03-19 17:06:41 +01:00

Sign in to join this conversation.

No Label

Animation & Rigging

Asset Browser Project Overview

Automated Testing

Blender Asset Bundle

Dependency Graph

Development Management

EEVEE & Viewport

Images & Movies

Motion Tracking

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Render Pipeline

Sculpt, Paint & Texture

Video Sequencer

Virtual Reality

Blender 2.8 Project

Milestone 1: Basic, Local Asset Browser

Good First Issue

Animation & Rigging

Development Management

EEVEE & Viewport

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Sculpt, Paint & Texture

Needs Info from Developers

Needs Information from User

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#119622

No description provided.