Cycles is not rendering the background light in the batch render, but renders in the interactive render #5234
Comments
|
Just a wild guess, this seems like it is related to the problematic reset code: |
|
Unit-test for it: https://github.com/boberfly/gaffer/blob/fixes/cyclesParamsBeforeRender/python/GafferCyclesTest/IECoreCyclesPreviewTest/RendererTest.py#L1884 The auto tile option causes a change in the Cycles session which is an option that can only be set before rendering starts, thus it triggers some buggy codepaths from when we tried supporting these as interactive edits. I'd say that the batch render would succeed if auto-tile is off (and of course smaller than 2k so it doesn't run into #5233). |
4 tasks
johnhaddon
added a commit
to johnhaddon/gaffer
that referenced
this issue
Mar 4, 2024
This reintroduces support for `cycles:device` and other session-affecting options, with the constraint that all such options much be provided before the first call to `object()` or `attributes()`. Due to earlier commits, all important clients are now meeting those constraints. Generally, the approach of storing from all options and pulling from them in the relevant spots seems a bit easier to reason about than the old approach of having `option()` push into various things at times that might not be convenient. But there is one definite downside - `RendererTest.testUnknownOptions` is now failing, because we're not spotting that some options aren't handled at all. This will be fixed in the next commit - I've omitted it from this one in an attempt to keep the changes as bite-sized as possible. The new test case for the background light in batch renders is courtesy of Alex, and shows that this also fixes GafferHQ#5234.
johnhaddon
added a commit
to johnhaddon/gaffer
that referenced
this issue
Mar 7, 2024
This reintroduces support for `cycles:device` and other session-affecting options, with the constraint that all such options much be provided before the first call to `object()` or `attributes()`. Due to earlier commits, all important clients are now meeting those constraints. Generally, the approach of storing from all options and pulling from them in the relevant spots seems a bit easier to reason about than the old approach of having `option()` push into various things at times that might not be convenient. But there is one definite downside - `RendererTest.testUnknownOptions` is now failing, because we're not spotting that some options aren't handled at all. This will be fixed in the next commit - I've omitted it from this one in an attempt to keep the changes as bite-sized as possible. The new test case for the background light in batch renders is courtesy of Alex, and shows that this also fixes GafferHQ#5234.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Version: gaffer-1.2.2.0-linux
Third-party tools: None
Third-party modules: None
Description
When rendering a scene, the interactive render will include the background light, while doing
gaffer execute ...will not render the background light. I've also included an example scene.Steps to reproduce
gaffer execute .... The background light will not affect the scene.backgroundlight.gfr.tar.gz
The text was updated successfully, but these errors were encountered: