World aov output nodes dont work unless background node's colour is >= 0.0001 #112062

New Issue

Open

opened 2023-09-07 00:25:27 +02:00 by michael campbell · 13 comments

michael campbell commented

2023-09-07 00:25:27 +02:00

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 536.99

Blender Version
Broken: version: 3.6.3 Release Candidate, branch: blender-v3.6-release, commit date: 2023-09-05 15:07, hash: d371c3c09fa8
Worked: Unknown

Short description of error
World aov output nodes dont work unless background node's colour is >= 0.0001

Exact steps for others to reproduce the error

Open attached file
go to the compositor of 'scene' and render still image
the custom world aov is blank
go to scene.001 and render
the world aov now outputs correctly

Both scene's are identical, the only difference is scene.001's world background node's colour is set to 0.0001. The custom AOV is of type Value rather than colour. This is problematic because it breaks compositor setups that check for values > 0 etc.

**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 536.99 **Blender Version** Broken: version: 3.6.3 Release Candidate, branch: blender-v3.6-release, commit date: 2023-09-05 15:07, hash: `d371c3c09fa8` Worked: Unknown **Short description of error** World aov output nodes dont work unless background node's colour is >= 0.0001 **Exact steps for others to reproduce the error** 1. Open attached file 2. go to the compositor of 'scene' and render still image 3. the custom world aov is blank 4. go to scene.001 and render 5. the world aov now outputs correctly Both scene's are identical, the only difference is scene.001's world background node's colour is set to 0.0001. The custom AOV is of type Value rather than colour. This is problematic because it breaks compositor setups that check for values > 0 etc.

word aov wont output unless background col set to 0.0001.blend

1.0 MiB

michael campbell added the

labels 2023-09-07 00:25:28 +02:00

YimingWu commented

2023-09-07 05:27:27 +02:00

Member

Can confirm on 3.6, but it seems to be working correctly in 4.0.

Can confirm on 3.6, but it seems to be working correctly in 4.0.

YimingWu added

Render & Cycles

Render Pipeline

and removed

labels 2023-09-07 05:27:44 +02:00

michael campbell commented

2023-09-07 05:47:24 +02:00

Author

awesome. Any chance the fix could be backported to 3.6? For addon purposes.

awesome. Any chance the fix could be backported to 3.6? For addon purposes.

michael campbell commented

2023-09-08 03:10:58 +02:00

Author

@ChengduLittleA I've just tried today's build of 4.0 alpha, and the bug is still there for me. Perhaps you used the wrong scene in the file by accident? One of them works because it's background node's colour has been set to rgb 0.0001

It's almost as though there's a bit of code that says, if all pixels are black, then consider there to be no background, so AOV nodes fail to output. Although in 4.0, if the background strength is zero and colour is > (0,0,0.00001,1), then it will work, so it's not just a case of Blender deciding there's no world if all pixels are black. Super strange one.

@ChengduLittleA I've just tried today's build of 4.0 alpha, and the bug is still there for me. Perhaps you used the wrong scene in the file by accident? One of them works because it's background node's colour has been set to rgb 0.0001 It's almost as though there's a bit of code that says, if all pixels are black, then consider there to be no background, so AOV nodes fail to output. Although in 4.0, if the background strength is zero and colour is > (0,0,0.00001,1), then it will work, so it's not just a case of Blender deciding there's no world if all pixels are black. Super strange one.

Jesse Yurkovich commented

2023-09-10 00:49:27 +02:00

Member

It works fine for me on many 4.0 builds including the most recent build.

Going back to previous builds I have locally, it seems it was "fixed" at some point between:
Broken: version: 4.0.0 Alpha, branch: main, commit date: 2023-06-22 00:22, hash: 4d1593c4ad73
Works: version: 4.0.0 Alpha, branch: main, commit date: 2023-07-14 17:03, hash: d8e4fe320784

Someone would have to try and find what was fixed between 2023-06-22 and 2023-07-14 in order to backport it to LTS.

It works fine for me on many 4.0 builds including the most recent build. Going back to previous builds I have locally, it seems it was "fixed" at some point between: Broken: version: 4.0.0 Alpha, branch: main, commit date: 2023-06-22 00:22, hash: `4d1593c4ad73` Works: version: 4.0.0 Alpha, branch: main, commit date: 2023-07-14 17:03, hash: `d8e4fe320784` Someone would have to try and find what was fixed between 2023-06-22 and 2023-07-14 in order to backport it to LTS.

michael campbell commented

2023-09-10 01:46:28 +02:00

Author

Wierd it was still happening for me using a later build:

but I've just retried, and this time it did output the aov. I'm not sure if I was going mad or I had some other setting enabled that was interfering with it. Probably going mad.

Wierd it was still happening for me using a later build: ![image](/attachments/e9d8bd45-5a17-426e-8006-0430010f70b2) but I've just retried, and this time it did output the aov. I'm not sure if I was going mad or I had some other setting enabled that was interfering with it. Probably going mad.

35 KiB

michael campbell commented

2023-09-10 02:01:06 +02:00

Author

I'd like my addon to take a different approach in versions prior to the fix than it does afterwards. The problem is I can't use

if bpy.app.version >= (4,0,0):

because 4.0 versions with and without the bug, will both return 4,0,0. I noticed this the other day when fixing the new group input node creation methods. Had to use hassattr instead, which wont work in this case. How can I get around that? Perhaps the daily builds could start having the correct app version embedded?

I'd like my addon to take a different approach in versions prior to the fix than it does afterwards. The problem is I can't use ```py if bpy.app.version >= (4,0,0): ``` because 4.0 versions with and without the bug, will both return 4,0,0. I noticed this the other day when fixing the new group input node creation methods. Had to use hassattr instead, which wont work in this case. How can I get around that? Perhaps the daily builds could start having the correct app version embedded?

Jesse Yurkovich commented

2023-09-10 02:07:04 +02:00

Member

That version is the correct app version. You can also attempt to use bpy.app.version_file which tracks the raw blend file format but that is not incremented each build. It will be (4, 0, 7) for the 2023-06-22 build and (4, 0, 10) for the 2023-07-14 builds in my example. Or you can look at bpy.app.build_date and use that.

That version is the correct app version. You can also attempt to use `bpy.app.version_file` which tracks the raw blend file format but that is not incremented each build. It will be `(4, 0, 7)` for the 2023-06-22 build and `(4, 0, 10)` for the 2023-07-14 builds in my example. Or you can look at `bpy.app.build_date` and use that.

michael campbell commented

2023-09-10 02:17:52 +02:00

Author

so bpy.app.version should be incrememnted? The reason I ask is because Lukas said to use bpy.app.version(4,0.20) when checking for the new node group input creation method, but all versions show (4,0,0). Even the Sep 7th build is still showing showing (4,0,0):

so bpy.app.version should be incrememnted? The reason I ask is because Lukas said to use bpy.app.version(4,0.20) when checking for the new node group input creation method, but all versions show (4,0,0). Even the Sep 7th build is still showing showing (4,0,0): ![image](/attachments/35adf6a5-28d5-4e41-a105-0030c0a9d91f)

275 KiB

michael campbell commented

2023-09-10 02:20:58 +02:00

Author

I guess version file is the one to always use then? Although you say that isn't incremented each build?

Although I guess that's no use if the user hasn't saved the file in the current version?

I guess version file is the one to always use then? Although you say that isn't incremented each build? ![image](/attachments/7b558159-8b04-4ed7-8556-e2cfd4de324c) Although I guess that's no use if the user hasn't saved the file in the current version?

14 KiB

Jesse Yurkovich commented

2023-09-10 02:22:56 +02:00

Member

bpy.app.version is the "public" version so 4.0.0 is correct. Lukas most probably meant bpy.app.version_file as that would have been (4, 0, 20) recently -- but again that's the .blend file version and user's don't see it really it's only an internal concept which is used to do backward compat versioning. It is only incremented when a change requires some sort of active versioning to occur when loading files.

`bpy.app.version` is the "public" version so 4.0.0 is correct. Lukas most probably meant `bpy.app.version_file` as that would have been (4, 0, 20) recently -- but again that's the .blend file version and user's don't see it really it's only an internal concept which is used to do backward compat versioning. It is only incremented when a change requires some sort of active versioning to occur when loading files.

michael campbell commented

2023-09-10 02:29:57 +02:00

Author

Thanks for your help. I guess build_date is the only safe option then. Do you know why the about blender date and bpy.app.build_date differ?

If a bug fix is implemented on the 07-09-2023, should I always check a day ahead?

Thanks for your help. I guess build_date is the only safe option then. Do you know why the about blender date and bpy.app.build_date differ? ![image](/attachments/65ebd7cf-24c1-4604-b470-f0554332d8db) If a bug fix is implemented on the 07-09-2023, should I always check a day ahead?

195 KiB

Jesse Yurkovich commented

2023-09-10 02:33:42 +02:00

Member

The date in the about dialog box is bpy.app.build_commit_date The commit used in your example is from the 8th, but by the time the build occurred and was released it was the 9th (bpy.app.build_date).

The date in the about dialog box is `bpy.app.build_commit_date` The commit used in your example is from the 8th, but by the time the build occurred and was released it was the 9th (bpy.app.build_date).

michael campbell commented

2023-09-10 02:41:15 +02:00

Author

got ya, thanks.

got ya, thanks.

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

3 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#112062

No description provided.