Only if I switch the backdrop to solid and back to 360° than the transparent color is shown like in the full rendering.
Here an other example:
default after start
after switch to solid color and back
Also confusing that the raytraced viewport doesn’t look like the final output.
Is the tone mapping not synchronized?
I am unable to reproduce the background change not sticking. Steps I followed:
- open a model
- switch to Raytraced
- check 360° is showing
- set background to solid black
- set background back to 360° enviroment
Along these steps the background changes as per selection. I tested this with current service release candidate of 7.5
Regarding tonemapping: that is work by @johnc and @lars, I’ll let them reply on that part.
Please set a 360° env and enable transparent background and than start the raytraced mode. We should see a solid black background, but I still see the 360° env.
Transparency is in the viewport undefined for Raytraced.
It’s ok, but it works like expected if also other options are changed. For example you can force to show the right background (like at the full render output) also by changing the environment intensity.
My impression is that not only the wrong background is shown, also I got the impression the wrong env is be used sometimes. It was easier for me to report the update issue by this example.
Also, if you forced to show the black backround and you turn off/on the raytraced mode than you are back to the unstable initial state. It’s not good working with the unstable output.
@nathanletwory My understanding is that the ‘Transparent background’ check box is being ignored by Cycles, and I can repeat this here. If you check that box, Cycles does not restart the viewport rendering. But if you change the Backdrop settings, Cycles will restart and then the Transparent background option will be used.
FYI: This doesn’t have anything to do with Tone Mapping which is working as expected.
John
@johnc I’m glad you are able to confirm the backdrop issue. This is issue (a) for @nathanletwory .
The other issue (b) is for you - the tone mapping settings of the frame buffer need to be used for the raytraced viewport too or the user can’t use the raytrace mode for fine adjusting the output. For example V-Ray for Rhino is using the frame buffer adjustment also for the interactive viewport.
Also I miss an interactive raytracing per frame buffer. VfR allow to use interactive rendering per viewport and frame buffer.
That indicates that Rhino ChangeQueue mechanism doesn’t tell Cycles the checkbox was clicked on. Just checked, ProRender doesn’t get notified either. Logged this as RH-63516 Toggling transparent checkbox in background settings doesn’t trigger change through changequeue.
Make sure you adjust these in the viewport settings.
I am not sure what you mean by framebuffer, the render window maybe? The render window is the offline/production render method. While it is active no other part of Rhino is accessible. V-Ray most likely is using windows and widgets of their own, not our render window.
To synchronize settings between the render window and the viewport you have to press the save button in the render window, the one at the bottom of the post effects panel
Then in the viewport with Raytraced (or Pro Render for instance) active press in the viewport post effects panel the load button (folder with the green arrow)
Great, thank you very much for the detailed info.
(At VfR the tone mapping of the render window is used for the real time viewport rendering too. So expect a connection here too.)
@nathanletwory Here an example what I mean that the issue is more than the visible backdrop.
After a fresh restart of the raytraced viewport - wrong product look, not only the backdrop.
After switch to solid and back to 360° Env - now the product looks like expected and the distracting unwanted backdrop is gone. Interesting is - the blue light over the word “Made …” is from a point light and not the environment. So, the backdrop issue affect the lighting. Quite unstable workflow.
The transparency toggle handling has been fixed by @andy. It’ll be in the next service release candidate (7.6).
- render channels? pls pls