griefith/test2
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
fba76712051331ab15272bcf1fe4e654775e4bdc
test2/scripts/startup/bl_ui/properties_view_layer.py

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

350 lines
11 KiB
Python
Raw Normal View History

License Headers: Set copyright to "Blender Authors", add AUTHORS Listing the "Blender Foundation" as copyright holder implied the Blender Foundation holds copyright to files which may include work from many developers. While keeping copyright on headers makes sense for isolated libraries, Blender's own code may be refactored or moved between files in a way that makes the per file copyright holders less meaningful. Copyright references to the "Blender Foundation" have been replaced with "Blender Authors", with the exception of `./extern/` since these this contains libraries which are more isolated, any changed to license headers there can be handled on a case-by-case basis. Some directories in `./intern/` have also been excluded: - `./intern/cycles/` it's own `AUTHORS` file is planned. - `./intern/opensubdiv/`. An "AUTHORS" file has been added, using the chromium projects authors file as a template. Design task: #110784 Ref !110783.
2023-08-16 00:20:26 +10:00
# SPDX-FileCopyrightText: 2012-2023 Blender Authors
License headers: use SPDX-FileCopyrightText in all sources
2023-06-15 13:09:04 +10:00
#
File headers: SPDX License migration Use a shorter/simpler license convention, stops the header taking so much space. Follow the SPDX license specification: https://spdx.org/licenses - C/C++/objc/objc++ - Python - Shell Scripts - CMake, GNUmakefile While most of the source tree has been included - `./extern/` was left out. - `./intern/cycles` & `./intern/atomic` are also excluded because they use different header conventions. doc/license/SPDX-license-identifiers.txt has been added to list SPDX all used identifiers. See P2788 for the script that automated these edits. Reviewed By: brecht, mont29, sergey Ref D14069
2022-02-11 09:07:11 +11:00
# SPDX-License-Identifier: GPL-2.0-or-later
License headers: use SPDX-FileCopyrightText in all sources
2023-06-15 13:09:04 +10:00
UI: add a Custom Properties panel to the View Layer tab of properties. Although view layers aren't ID, they do support custom properties, so not providing the UI to access them seems to be a simple oversight.
2022-09-12 00:32:21 +03:00
from bpy.types import Menu, Panel, UIList, ViewLayer
I18n: disambiguate a few messages - "Lens" can be a transparent object used in cameras, or specifically its property of focal length - "Empty" can be an adjective meaning void, or an object type. The latter is already disambiguated using `ID_ID` - "New" and "Old" are adjectives that can have agreements in some languages - "Modified" is an adjective that can have agreement in some languages - "Clipping" can be a property of a camera, or a behavior of the mirror modifier - "Value" in HSV nodes, see #105113 - "Area" in the Face Area geometry node, can mean a measurement or a window type - "New" is an adjective that can have agreement - "Tab" can be a UI element or a whitespace character - "Volume" can mean a measurement or an object type. The latter is already disambiguated using `ID_ID` These changes introduce the new `BLT_I18NCONTEXT_TIME` translation context. They also remove `BLT_I18NCONTEXT_VIRTUAL_REALITY`, which I added at one point but then couldn't find which messages I wanted to fix with it. Ref #43295 Pull Request: #106718
2023-02-23 22:00:57 +01:00
from bpy.app.translations import contexts as i18n_contexts
UI: add a Custom Properties panel to the View Layer tab of properties. Although view layers aren't ID, they do support custom properties, so not providing the UI to access them seems to be a simple oversight.
2022-09-12 00:32:21 +03:00
from rna_prop_ui import PropertyPanel
EEVEE: Arbitrary Output Variables This patch adds support for AOVs in EEVEE. AOV Outputs can be defined in the render pass tab and used in shader materials. Both Object and World based shaders are supported. The AOV can be previewed in the viewport using the renderpass selector in the shading popover. AOV names that conflict with other AOVs are automatically corrected. AOV conflicts with render passes get a warning icon. The reason behind this is that changing render engines/passes can change the conflict, but you might not notice it. Changing this automatically would also make the materials incorrect, so best to leave this to the user. **Implementation** The patch adds a copies the AOV structures of Cycles into Blender. The goal is that the Cycles will use Blenders AOV defintions. In the Blender kernel (`layer.c`) the logic of these structures are implemented. The GLSL shader of any GPUMaterial can hold multiple outputs (the main output and the AOV outputs) based on the renderPassUBO the right output is selected. This selection uses an hash that encodes the AOV structure. The full AOV needed to be encoded when actually drawing the material pass as the AOV type changes the behavior of the AOV. This isn't known yet when the GLSL is compiled. **Future Developments** * The AOV definitions in the render layer panel isn't shared with Cycles. Cycles should be migrated to use the same viewlayer aovs. During a previous attempt this failed as the AOV validation in cycles and in Blender have implementation differences what made it crash when an aov name was invalid. This could be fixed by extending the external render engine API. * Add support to Cycles to render AOVs in the 3d viewport. * Use a drop down list for selecting AOVs in the AOV Output node. * Give user feedback when multiple AOV output nodes with the same AOV name exists in the same shader. * Fix viewing single channel images in the image editor [T83314] * Reduce viewport render time by only render needed draw passes. [T83316] Reviewed By: Brecht van Lommel, Clément Foucault Differential Revision: https://developer.blender.org/D7010
2020-12-04 08:13:54 +01:00
class VIEWLAYER_UL_aov(UIList):
Cleanup: unused arguments
2021-03-06 18:21:17 +11:00
def draw_item(self, _context, layout, _data, item, icon, _active_data, _active_propname):
EEVEE: Arbitrary Output Variables This patch adds support for AOVs in EEVEE. AOV Outputs can be defined in the render pass tab and used in shader materials. Both Object and World based shaders are supported. The AOV can be previewed in the viewport using the renderpass selector in the shading popover. AOV names that conflict with other AOVs are automatically corrected. AOV conflicts with render passes get a warning icon. The reason behind this is that changing render engines/passes can change the conflict, but you might not notice it. Changing this automatically would also make the materials incorrect, so best to leave this to the user. **Implementation** The patch adds a copies the AOV structures of Cycles into Blender. The goal is that the Cycles will use Blenders AOV defintions. In the Blender kernel (`layer.c`) the logic of these structures are implemented. The GLSL shader of any GPUMaterial can hold multiple outputs (the main output and the AOV outputs) based on the renderPassUBO the right output is selected. This selection uses an hash that encodes the AOV structure. The full AOV needed to be encoded when actually drawing the material pass as the AOV type changes the behavior of the AOV. This isn't known yet when the GLSL is compiled. **Future Developments** * The AOV definitions in the render layer panel isn't shared with Cycles. Cycles should be migrated to use the same viewlayer aovs. During a previous attempt this failed as the AOV validation in cycles and in Blender have implementation differences what made it crash when an aov name was invalid. This could be fixed by extending the external render engine API. * Add support to Cycles to render AOVs in the 3d viewport. * Use a drop down list for selecting AOVs in the AOV Output node. * Give user feedback when multiple AOV output nodes with the same AOV name exists in the same shader. * Fix viewing single channel images in the image editor [T83314] * Reduce viewport render time by only render needed draw passes. [T83316] Reviewed By: Brecht van Lommel, Clément Foucault Differential Revision: https://developer.blender.org/D7010
2020-12-04 08:13:54 +01:00
row = layout.row()
split = row.split(factor=0.65)
icon = 'NONE' if item.is_valid else 'ERROR'
split.row().prop(item, "name", text="", icon=icon, emboss=False)
split.row().prop(item, "type", text="", emboss=False)
Improvements of Freestyle GUI controls - Part 1. This commit makes a set of fixes and improvements based on the results of Freestyle branch review by Brecht. The discussion thread is: http://lists.blender.org/pipermail/bf-committers/2012-October/037927.html * The Layers panel and Freestyle-related panels in the Render tab of the Properties window were moved to the newly created Render Layers tab. The idea is to separate per render layer rendering options into a distinct Properties window tab, and use the existing Render tab to accommodate per scene rendering options. * The new Freestyle panel was added in the Render tab. The panel header contains a toggle button for globally enabling Freestyle, with the aim of making Freestyle easier to find. Those Freestyle options in the Post Processing panel were also moved to the new panel. * GUI code was updated so that UI controls will be greyed out (instead of being hidden) when Freestyle is disabled. Additional UI changes were also made to reduce space consumption. * The list of line sets was moved from the Freestyle panel to the Freestyle: Line Sets panel. * Old ray-casting algorithms were removed from the UI. Now only two algorithms (culled and non-culled cumulative visibility detection algorithms) are available, and the selection is done by the new "Culling" toggle button within the edge detection options.
2012-10-28 16:09:51 +00:00
Rename any instance of scene layer or render layer in code with view layer The RenderResult struct still has a listbase of RenderLayer, but that's ok since this is strictly for rendering. * Subversion bump (to 2.80.2) * DNA low level doversion (renames) - only for .blend created since 2.80 started Note: We can't use DNA_struct_elem_find or get file version in init_structDNA, so we are manually iterating over the array of the SDNA elements instead. Note 2: This doversion change with renames can be reverted in a few months. But so far it's required for 2.8 files created between October 2016 and now. Reviewers: campbellbarton, sergey Differential Revision: https://developer.blender.org/D2927
2017-11-22 10:52:39 -02:00
class ViewLayerButtonsPanel:
Improvements of Freestyle GUI controls - Part 1. This commit makes a set of fixes and improvements based on the results of Freestyle branch review by Brecht. The discussion thread is: http://lists.blender.org/pipermail/bf-committers/2012-October/037927.html * The Layers panel and Freestyle-related panels in the Render tab of the Properties window were moved to the newly created Render Layers tab. The idea is to separate per render layer rendering options into a distinct Properties window tab, and use the existing Render tab to accommodate per scene rendering options. * The new Freestyle panel was added in the Render tab. The panel header contains a toggle button for globally enabling Freestyle, with the aim of making Freestyle easier to find. Those Freestyle options in the Post Processing panel were also moved to the new panel. * GUI code was updated so that UI controls will be greyed out (instead of being hidden) when Freestyle is disabled. Additional UI changes were also made to reduce space consumption. * The list of line sets was moved from the Freestyle panel to the Freestyle: Line Sets panel. * Old ray-casting algorithms were removed from the UI. Now only two algorithms (culled and non-culled cumulative visibility detection algorithms) are available, and the selection is done by the new "Culling" toggle button within the edge detection options.
2012-10-28 16:09:51 +00:00
bl_space_type = 'PROPERTIES'
bl_region_type = 'WINDOW'
Rename any instance of scene layer or render layer in code with view layer The RenderResult struct still has a listbase of RenderLayer, but that's ok since this is strictly for rendering. * Subversion bump (to 2.80.2) * DNA low level doversion (renames) - only for .blend created since 2.80 started Note: We can't use DNA_struct_elem_find or get file version in init_structDNA, so we are manually iterating over the array of the SDNA elements instead. Note 2: This doversion change with renames can be reverted in a few months. But so far it's required for 2.8 files created between October 2016 and now. Reviewers: campbellbarton, sergey Differential Revision: https://developer.blender.org/D2927
2017-11-22 10:52:39 -02:00
bl_context = "view_layer"
Improvements of Freestyle GUI controls - Part 1. This commit makes a set of fixes and improvements based on the results of Freestyle branch review by Brecht. The discussion thread is: http://lists.blender.org/pipermail/bf-committers/2012-October/037927.html * The Layers panel and Freestyle-related panels in the Render tab of the Properties window were moved to the newly created Render Layers tab. The idea is to separate per render layer rendering options into a distinct Properties window tab, and use the existing Render tab to accommodate per scene rendering options. * The new Freestyle panel was added in the Render tab. The panel header contains a toggle button for globally enabling Freestyle, with the aim of making Freestyle easier to find. Those Freestyle options in the Post Processing panel were also moved to the new panel. * GUI code was updated so that UI controls will be greyed out (instead of being hidden) when Freestyle is disabled. Additional UI changes were also made to reduce space consumption. * The list of line sets was moved from the Freestyle panel to the Freestyle: Line Sets panel. * Old ray-casting algorithms were removed from the UI. Now only two algorithms (culled and non-culled cumulative visibility detection algorithms) are available, and the selection is done by the new "Culling" toggle button within the edge detection options.
2012-10-28 16:09:51 +00:00
# COMPAT_ENGINES must be defined in each subclass, external engines can add themselves here
@classmethod
def poll(cls, context):
Workspaces: remove workspace engine, use 3D viewport draw mode instead. ViewRender was removed, which means we can't get the render engine for files saved in 2.8. We assume that any files saved in 2.8 were intended to use Eevee and set the engine to that. A fix included with this is that .blend thumbails now draw with Clay mode, and never Eevee or Cycles. These were drawn with solid mode in 2.7, and should be very fast and not e.g. load heavy image textures. Differential Revision: https://developer.blender.org/D3156
2018-04-17 13:35:05 +02:00
return (context.engine in cls.COMPAT_ENGINES)
Improvements of Freestyle GUI controls - Part 1. This commit makes a set of fixes and improvements based on the results of Freestyle branch review by Brecht. The discussion thread is: http://lists.blender.org/pipermail/bf-committers/2012-October/037927.html * The Layers panel and Freestyle-related panels in the Render tab of the Properties window were moved to the newly created Render Layers tab. The idea is to separate per render layer rendering options into a distinct Properties window tab, and use the existing Render tab to accommodate per scene rendering options. * The new Freestyle panel was added in the Render tab. The panel header contains a toggle button for globally enabling Freestyle, with the aim of making Freestyle easier to find. Those Freestyle options in the Post Processing panel were also moved to the new panel. * GUI code was updated so that UI controls will be greyed out (instead of being hidden) when Freestyle is disabled. Additional UI changes were also made to reduce space consumption. * The list of line sets was moved from the Freestyle panel to the Freestyle: Line Sets panel. * Old ray-casting algorithms were removed from the UI. Now only two algorithms (culled and non-culled cumulative visibility detection algorithms) are available, and the selection is done by the new "Culling" toggle button within the edge detection options.
2012-10-28 16:09:51 +00:00
Workspaces: active view layer now always comes from workspace, not scene. Both the scene and workspace had an active view layer, and it was confusing which settings were being used or displayed where. Now we always have one, so there is no mismatch. The "View Layers" tab in the properties editor is now "View Layer", no longer showing a list of layers. Instead view layers can be added and removed with the workspace view layer selector. They are also listed and selectable in the outliner. Single layer rendering uses the active view layer from the workspace. This fixes bugs where the wrong active view layer was used, but more places remain that are wrong and are now using the first view layer in the scene. These are all marked with BKE_view_layer_context_active_PLACEHOLDER.
2018-04-24 15:20:17 +02:00
class VIEWLAYER_PT_layer(ViewLayerButtonsPanel, Panel):
bl_label = "View Layer"
Cleanup: format
2023-01-24 17:58:58 +01:00
COMPAT_ENGINES = {
'BLENDER_RENDER',
'BLENDER_EEVEE',
'BLENDER_EEVEE_NEXT',
Cleanup: use since quotes for enum values, wrap multi-line brackets
2023-09-29 14:32:54 +10:00
'BLENDER_WORKBENCH',
}
Improvements of Freestyle GUI controls - Part 1. This commit makes a set of fixes and improvements based on the results of Freestyle branch review by Brecht. The discussion thread is: http://lists.blender.org/pipermail/bf-committers/2012-October/037927.html * The Layers panel and Freestyle-related panels in the Render tab of the Properties window were moved to the newly created Render Layers tab. The idea is to separate per render layer rendering options into a distinct Properties window tab, and use the existing Render tab to accommodate per scene rendering options. * The new Freestyle panel was added in the Render tab. The panel header contains a toggle button for globally enabling Freestyle, with the aim of making Freestyle easier to find. Those Freestyle options in the Post Processing panel were also moved to the new panel. * GUI code was updated so that UI controls will be greyed out (instead of being hidden) when Freestyle is disabled. Additional UI changes were also made to reduce space consumption. * The list of line sets was moved from the Freestyle panel to the Freestyle: Line Sets panel. * Old ray-casting algorithms were removed from the UI. Now only two algorithms (culled and non-culled cumulative visibility detection algorithms) are available, and the selection is done by the new "Culling" toggle button within the edge detection options.
2012-10-28 16:09:51 +00:00
def draw(self, context):
layout = self.layout
UI: use property split for motion paths
2018-09-11 16:49:52 +10:00
layout.use_property_split = True
Improvements of Freestyle GUI controls - Part 1. This commit makes a set of fixes and improvements based on the results of Freestyle branch review by Brecht. The discussion thread is: http://lists.blender.org/pipermail/bf-committers/2012-October/037927.html * The Layers panel and Freestyle-related panels in the Render tab of the Properties window were moved to the newly created Render Layers tab. The idea is to separate per render layer rendering options into a distinct Properties window tab, and use the existing Render tab to accommodate per scene rendering options. * The new Freestyle panel was added in the Render tab. The panel header contains a toggle button for globally enabling Freestyle, with the aim of making Freestyle easier to find. Those Freestyle options in the Post Processing panel were also moved to the new panel. * GUI code was updated so that UI controls will be greyed out (instead of being hidden) when Freestyle is disabled. Additional UI changes were also made to reduce space consumption. * The list of line sets was moved from the Freestyle panel to the Freestyle: Line Sets panel. * Old ray-casting algorithms were removed from the UI. Now only two algorithms (culled and non-culled cumulative visibility detection algorithms) are available, and the selection is done by the new "Culling" toggle button within the edge detection options.
2012-10-28 16:09:51 +00:00
scene = context.scene
Fixup for recent workspace changes: Python files I wrongly changed some of these files via sed, and apparently overdid it in some false positives.
2017-10-16 17:59:09 -02:00
rd = scene.render
Cleanup: redundant bpy.context access
2019-03-13 13:13:29 +11:00
layer = context.view_layer
Improvements of Freestyle GUI controls - Part 1. This commit makes a set of fixes and improvements based on the results of Freestyle branch review by Brecht. The discussion thread is: http://lists.blender.org/pipermail/bf-committers/2012-October/037927.html * The Layers panel and Freestyle-related panels in the Render tab of the Properties window were moved to the newly created Render Layers tab. The idea is to separate per render layer rendering options into a distinct Properties window tab, and use the existing Render tab to accommodate per scene rendering options. * The new Freestyle panel was added in the Render tab. The panel header contains a toggle button for globally enabling Freestyle, with the aim of making Freestyle easier to find. Those Freestyle options in the Post Processing panel were also moved to the new panel. * GUI code was updated so that UI controls will be greyed out (instead of being hidden) when Freestyle is disabled. Additional UI changes were also made to reduce space consumption. * The list of line sets was moved from the Freestyle panel to the Freestyle: Line Sets panel. * Old ray-casting algorithms were removed from the UI. Now only two algorithms (culled and non-culled cumulative visibility detection algorithms) are available, and the selection is done by the new "Culling" toggle button within the edge detection options.
2012-10-28 16:09:51 +00:00
UI: Layout changes for new checkbox layout possibilities Follow-up to previous commit. Some examples: {F8473507} {F8473508} {F8473509} {F8473510} For more screenshots, please see D7430. We use column or row headings here to bring more structure, and to give the eye visual anchors which aid eye-scanning. The left-aligned checkboxes likewise help with this. And we keep the adherence to the center line, so the alignment matches up between the various buttons and controls. * Changes the property split percentage from 50/50% to 40/60%. This is needed to give enough space for the checkboxes. But in most cases this looks better anyway - see Transform panel. In some cases it simply fills out the available space more efficently. * Fix various hacks where we previously used manually defined splits. When we did this, the alignment was never quite right, and the layout code was a mess. * Adds column headings to many places where a list of checkboxes all share a common purpose or leading text. * Add checkbox + value configurations various places where a checkbox only serves to enable the value slider * Removes most uses of grid flow layout. The grid flow layouts combine poorly with column headings, and also they would mess alignment up badly. The grid flow layouts also often made buttons and controls jump around on the screen if you would just resize editors slightly, causing visual confusion, making users lose their place. The logic for at what time the list of items would re-flow was often flawed, jumping to multiple columns too fast or too late - and frankly, the grid flow layouts would often just look bad. Maniphest Task: https://developer.blender.org/T65965 Differential Revision: https://developer.blender.org/D7430 Reviewed by: Brecht Van Lommel, Pablo Vazquez. Most work here by William Reynish, few changes by Julian Eisel.
2020-04-17 16:54:03 +02:00
col = layout.column()
UI: use property split for motion paths
2018-09-11 16:49:52 +10:00
col.prop(layer, "use", text="Use for Rendering")
col.prop(rd, "use_single_layer", text="Render Single Layer")
Improvements of Freestyle GUI controls - Part 1. This commit makes a set of fixes and improvements based on the results of Freestyle branch review by Brecht. The discussion thread is: http://lists.blender.org/pipermail/bf-committers/2012-October/037927.html * The Layers panel and Freestyle-related panels in the Render tab of the Properties window were moved to the newly created Render Layers tab. The idea is to separate per render layer rendering options into a distinct Properties window tab, and use the existing Render tab to accommodate per scene rendering options. * The new Freestyle panel was added in the Render tab. The panel header contains a toggle button for globally enabling Freestyle, with the aim of making Freestyle easier to find. Those Freestyle options in the Post Processing panel were also moved to the new panel. * GUI code was updated so that UI controls will be greyed out (instead of being hidden) when Freestyle is disabled. Additional UI changes were also made to reduce space consumption. * The list of line sets was moved from the Freestyle panel to the Freestyle: Line Sets panel. * Old ray-casting algorithms were removed from the UI. Now only two algorithms (culled and non-culled cumulative visibility detection algorithms) are available, and the selection is done by the new "Culling" toggle button within the edge detection options.
2012-10-28 16:09:51 +00:00
Further tweaking of the recent UI changes (new layer context), mostly by splitting the big layers panel in three, and fixing Freestyle's panels poll function to hide them when Freestyle is disabled. Patch contribution by Bastien Montagne, thanks!
2012-10-29 23:11:55 +00:00
EEVEE: Arbitrary Output Variables This patch adds support for AOVs in EEVEE. AOV Outputs can be defined in the render pass tab and used in shader materials. Both Object and World based shaders are supported. The AOV can be previewed in the viewport using the renderpass selector in the shading popover. AOV names that conflict with other AOVs are automatically corrected. AOV conflicts with render passes get a warning icon. The reason behind this is that changing render engines/passes can change the conflict, but you might not notice it. Changing this automatically would also make the materials incorrect, so best to leave this to the user. **Implementation** The patch adds a copies the AOV structures of Cycles into Blender. The goal is that the Cycles will use Blenders AOV defintions. In the Blender kernel (`layer.c`) the logic of these structures are implemented. The GLSL shader of any GPUMaterial can hold multiple outputs (the main output and the AOV outputs) based on the renderPassUBO the right output is selected. This selection uses an hash that encodes the AOV structure. The full AOV needed to be encoded when actually drawing the material pass as the AOV type changes the behavior of the AOV. This isn't known yet when the GLSL is compiled. **Future Developments** * The AOV definitions in the render layer panel isn't shared with Cycles. Cycles should be migrated to use the same viewlayer aovs. During a previous attempt this failed as the AOV validation in cycles and in Blender have implementation differences what made it crash when an aov name was invalid. This could be fixed by extending the external render engine API. * Add support to Cycles to render AOVs in the 3d viewport. * Use a drop down list for selecting AOVs in the AOV Output node. * Give user feedback when multiple AOV output nodes with the same AOV name exists in the same shader. * Fix viewing single channel images in the image editor [T83314] * Reduce viewport render time by only render needed draw passes. [T83316] Reviewed By: Brecht van Lommel, Clément Foucault Differential Revision: https://developer.blender.org/D7010
2020-12-04 08:13:54 +01:00
class VIEWLAYER_PT_layer_passes(ViewLayerButtonsPanel, Panel):
Eevee: Add Z pass render result.
2018-01-29 21:59:34 +01:00
bl_label = "Passes"
Workbench: Remove old implementation
2023-09-04 17:42:04 +02:00
COMPAT_ENGINES = {'BLENDER_EEVEE', 'BLENDER_EEVEE_NEXT'}
Eevee: Add Z pass render result.
2018-01-29 21:59:34 +01:00
def draw(self, context):
EEVEE: Render Passes This patch adds new render passes to EEVEE. These passes include: * Emission * Diffuse Light * Diffuse Color * Glossy Light * Glossy Color * Environment * Volume Scattering * Volume Transmission * Bloom * Shadow With these passes it will be possible to use EEVEE effectively for compositing. During development we kept a close eye on how to get similar results compared to cycles render passes there are some differences that are related to how EEVEE works. For EEVEE we combined the passes to `Diffuse` and `Specular`. There are no transmittance or sss passes anymore. Cycles will be changed accordingly. Cycles volume transmittance is added to multiple surface col passes. For EEVEE we left the volume transmittance as a separate pass. Known Limitations * All materials that use alpha blending will not be rendered in the render passes. Other transparency modes are supported. * More GPU memory is required to store the render passes. When rendering a HD image with all render passes enabled at max extra 570MB GPU memory is required. Implementation Details An overview of render passes have been described in https://wiki.blender.org/wiki/Source/Render/EEVEE/RenderPasses Future Developments * In this implementation the materials are re-rendered for Diffuse/Glossy and Emission passes. We could use multi target rendering to improve the render speed. * Other passes can be added later * Don't render material based passes when only requesting AO or Shadow. * Add more passes to the system. These could include Cryptomatte, AOV's, Vector, ObjectID, MaterialID, UV. Reviewed By: Clément Foucault Differential Revision: https://developer.blender.org/D6331
2020-02-20 14:53:53 +01:00
pass
UI: use property split for motion paths
2018-09-11 16:49:52 +10:00
Eevee: Add Z pass render result.
2018-01-29 21:59:34 +01:00
EEVEE: Render Passes This patch adds new render passes to EEVEE. These passes include: * Emission * Diffuse Light * Diffuse Color * Glossy Light * Glossy Color * Environment * Volume Scattering * Volume Transmission * Bloom * Shadow With these passes it will be possible to use EEVEE effectively for compositing. During development we kept a close eye on how to get similar results compared to cycles render passes there are some differences that are related to how EEVEE works. For EEVEE we combined the passes to `Diffuse` and `Specular`. There are no transmittance or sss passes anymore. Cycles will be changed accordingly. Cycles volume transmittance is added to multiple surface col passes. For EEVEE we left the volume transmittance as a separate pass. Known Limitations * All materials that use alpha blending will not be rendered in the render passes. Other transparency modes are supported. * More GPU memory is required to store the render passes. When rendering a HD image with all render passes enabled at max extra 570MB GPU memory is required. Implementation Details An overview of render passes have been described in https://wiki.blender.org/wiki/Source/Render/EEVEE/RenderPasses Future Developments * In this implementation the materials are re-rendered for Diffuse/Glossy and Emission passes. We could use multi target rendering to improve the render speed. * Other passes can be added later * Don't render material based passes when only requesting AO or Shadow. * Add more passes to the system. These could include Cryptomatte, AOV's, Vector, ObjectID, MaterialID, UV. Reviewed By: Clément Foucault Differential Revision: https://developer.blender.org/D6331
2020-02-20 14:53:53 +01:00
class VIEWLAYER_PT_eevee_layer_passes_data(ViewLayerButtonsPanel, Panel):
bl_label = "Data"
EEVEE: Arbitrary Output Variables This patch adds support for AOVs in EEVEE. AOV Outputs can be defined in the render pass tab and used in shader materials. Both Object and World based shaders are supported. The AOV can be previewed in the viewport using the renderpass selector in the shading popover. AOV names that conflict with other AOVs are automatically corrected. AOV conflicts with render passes get a warning icon. The reason behind this is that changing render engines/passes can change the conflict, but you might not notice it. Changing this automatically would also make the materials incorrect, so best to leave this to the user. **Implementation** The patch adds a copies the AOV structures of Cycles into Blender. The goal is that the Cycles will use Blenders AOV defintions. In the Blender kernel (`layer.c`) the logic of these structures are implemented. The GLSL shader of any GPUMaterial can hold multiple outputs (the main output and the AOV outputs) based on the renderPassUBO the right output is selected. This selection uses an hash that encodes the AOV structure. The full AOV needed to be encoded when actually drawing the material pass as the AOV type changes the behavior of the AOV. This isn't known yet when the GLSL is compiled. **Future Developments** * The AOV definitions in the render layer panel isn't shared with Cycles. Cycles should be migrated to use the same viewlayer aovs. During a previous attempt this failed as the AOV validation in cycles and in Blender have implementation differences what made it crash when an aov name was invalid. This could be fixed by extending the external render engine API. * Add support to Cycles to render AOVs in the 3d viewport. * Use a drop down list for selecting AOVs in the AOV Output node. * Give user feedback when multiple AOV output nodes with the same AOV name exists in the same shader. * Fix viewing single channel images in the image editor [T83314] * Reduce viewport render time by only render needed draw passes. [T83316] Reviewed By: Brecht van Lommel, Clément Foucault Differential Revision: https://developer.blender.org/D7010
2020-12-04 08:13:54 +01:00
bl_parent_id = "VIEWLAYER_PT_layer_passes"
UI: use property split for motion paths
2018-09-11 16:49:52 +10:00
EEVEE: Render Passes This patch adds new render passes to EEVEE. These passes include: * Emission * Diffuse Light * Diffuse Color * Glossy Light * Glossy Color * Environment * Volume Scattering * Volume Transmission * Bloom * Shadow With these passes it will be possible to use EEVEE effectively for compositing. During development we kept a close eye on how to get similar results compared to cycles render passes there are some differences that are related to how EEVEE works. For EEVEE we combined the passes to `Diffuse` and `Specular`. There are no transmittance or sss passes anymore. Cycles will be changed accordingly. Cycles volume transmittance is added to multiple surface col passes. For EEVEE we left the volume transmittance as a separate pass. Known Limitations * All materials that use alpha blending will not be rendered in the render passes. Other transparency modes are supported. * More GPU memory is required to store the render passes. When rendering a HD image with all render passes enabled at max extra 570MB GPU memory is required. Implementation Details An overview of render passes have been described in https://wiki.blender.org/wiki/Source/Render/EEVEE/RenderPasses Future Developments * In this implementation the materials are re-rendered for Diffuse/Glossy and Emission passes. We could use multi target rendering to improve the render speed. * Other passes can be added later * Don't render material based passes when only requesting AO or Shadow. * Add more passes to the system. These could include Cryptomatte, AOV's, Vector, ObjectID, MaterialID, UV. Reviewed By: Clément Foucault Differential Revision: https://developer.blender.org/D6331
2020-02-20 14:53:53 +01:00
COMPAT_ENGINES = {'BLENDER_EEVEE'}
Cleanup: formatting, strip trailing space
2020-03-05 08:05:21 +11:00
EEVEE: Render Passes This patch adds new render passes to EEVEE. These passes include: * Emission * Diffuse Light * Diffuse Color * Glossy Light * Glossy Color * Environment * Volume Scattering * Volume Transmission * Bloom * Shadow With these passes it will be possible to use EEVEE effectively for compositing. During development we kept a close eye on how to get similar results compared to cycles render passes there are some differences that are related to how EEVEE works. For EEVEE we combined the passes to `Diffuse` and `Specular`. There are no transmittance or sss passes anymore. Cycles will be changed accordingly. Cycles volume transmittance is added to multiple surface col passes. For EEVEE we left the volume transmittance as a separate pass. Known Limitations * All materials that use alpha blending will not be rendered in the render passes. Other transparency modes are supported. * More GPU memory is required to store the render passes. When rendering a HD image with all render passes enabled at max extra 570MB GPU memory is required. Implementation Details An overview of render passes have been described in https://wiki.blender.org/wiki/Source/Render/EEVEE/RenderPasses Future Developments * In this implementation the materials are re-rendered for Diffuse/Glossy and Emission passes. We could use multi target rendering to improve the render speed. * Other passes can be added later * Don't render material based passes when only requesting AO or Shadow. * Add more passes to the system. These could include Cryptomatte, AOV's, Vector, ObjectID, MaterialID, UV. Reviewed By: Clément Foucault Differential Revision: https://developer.blender.org/D6331
2020-02-20 14:53:53 +01:00
def draw(self, context):
layout = self.layout
layout.use_property_split = True
layout.use_property_decorate = False
Workspaces: active view layer now always comes from workspace, not scene. Both the scene and workspace had an active view layer, and it was confusing which settings were being used or displayed where. Now we always have one, so there is no mismatch. The "View Layers" tab in the properties editor is now "View Layer", no longer showing a list of layers. Instead view layers can be added and removed with the workspace view layer selector. They are also listed and selectable in the outliner. Single layer rendering uses the active view layer from the workspace. This fixes bugs where the wrong active view layer was used, but more places remain that are wrong and are now using the first view layer in the scene. These are all marked with BKE_view_layer_context_active_PLACEHOLDER.
2018-04-24 15:20:17 +02:00
view_layer = context.view_layer
Eevee: Add Z pass render result.
2018-01-29 21:59:34 +01:00
UI: Layout changes for new checkbox layout possibilities Follow-up to previous commit. Some examples: {F8473507} {F8473508} {F8473509} {F8473510} For more screenshots, please see D7430. We use column or row headings here to bring more structure, and to give the eye visual anchors which aid eye-scanning. The left-aligned checkboxes likewise help with this. And we keep the adherence to the center line, so the alignment matches up between the various buttons and controls. * Changes the property split percentage from 50/50% to 40/60%. This is needed to give enough space for the checkboxes. But in most cases this looks better anyway - see Transform panel. In some cases it simply fills out the available space more efficently. * Fix various hacks where we previously used manually defined splits. When we did this, the alignment was never quite right, and the layout code was a mess. * Adds column headings to many places where a list of checkboxes all share a common purpose or leading text. * Add checkbox + value configurations various places where a checkbox only serves to enable the value slider * Removes most uses of grid flow layout. The grid flow layouts combine poorly with column headings, and also they would mess alignment up badly. The grid flow layouts also often made buttons and controls jump around on the screen if you would just resize editors slightly, causing visual confusion, making users lose their place. The logic for at what time the list of items would re-flow was often flawed, jumping to multiple columns too fast or too late - and frankly, the grid flow layouts would often just look bad. Maniphest Task: https://developer.blender.org/T65965 Differential Revision: https://developer.blender.org/D7430 Reviewed by: Brecht Van Lommel, Pablo Vazquez. Most work here by William Reynish, few changes by Julian Eisel.
2020-04-17 16:54:03 +02:00
col = layout.column()
Eevee: Add Z pass render result.
2018-01-29 21:59:34 +01:00
col.prop(view_layer, "use_pass_combined")
col.prop(view_layer, "use_pass_z")
Eevee: Add mist pass support. Eevee: Render: Fix crash when not enabling mist pass.
2018-02-01 18:09:06 +01:00
col.prop(view_layer, "use_pass_mist")
Eevee: Render: Add Normal pass output.
2018-01-31 01:09:38 +01:00
col.prop(view_layer, "use_pass_normal")
Eevee: Render: Add Subsurface Pass support.
2018-01-31 21:17:27 +01:00
Eevee: Add Z pass render result.
2018-01-29 21:59:34 +01:00
EEVEE-Next: Add back data passes UI and missing passes The `VIEWLAYER_PT_eevee_next_layer_passes_data` class name was re-used by mistake for Workbench Next in ba982119cd, and the actual EEVEE Next class was then removed in 678dc456e3. This adds back the UI as it was, and the missing passes (Vector and Position) it referenced. Pull Request: https://projects.blender.org/blender/blender/pulls/112162
2023-09-11 20:14:04 +02:00
class VIEWLAYER_PT_eevee_next_layer_passes_data(ViewLayerButtonsPanel, Panel):
bl_label = "Data"
bl_parent_id = "VIEWLAYER_PT_layer_passes"
COMPAT_ENGINES = {'BLENDER_EEVEE_NEXT'}
def draw(self, context):
layout = self.layout
layout.use_property_split = True
layout.use_property_decorate = False
scene = context.scene
view_layer = context.view_layer
col = layout.column()
col.prop(view_layer, "use_pass_combined")
col.prop(view_layer, "use_pass_z")
col.prop(view_layer, "use_pass_mist")
col.prop(view_layer, "use_pass_normal")
col.prop(view_layer, "use_pass_position")
sub = col.column()
sub.active = not scene.eevee.use_motion_blur
sub.prop(view_layer, "use_pass_vector")
Workbench: Remove old implementation
2023-09-04 17:42:04 +02:00
class VIEWLAYER_PT_workbench_layer_passes_data(ViewLayerButtonsPanel, Panel):
Workbench Next Rewrite of the Workbench engine using C++ and the new Draw Manager API. The new engine can be enabled in Blender `Preferences > Experimental > Workbench Next`. After that, the engine can be selected in `Properties > Scene > Render Engine`. When `Workbench Next` is the active engine, it also handles the `Solid` viewport mode rendering. The rewrite aims to be functionally equivalent to the current Workbench engine, but it also includes some small fixes/tweaks: - `In Front` rendered objects now work correctly with DoF and Shadows. - The `Sampling > Viewport` setting is actually used when the viewport is in `Render Mode`. - In `Texture` mode, textured materials also use the material properties. (Previously, only non textured materials would) To do: - Sculpt PBVH. - Volume rendering. - Hair rendering. - Use the "no_geom" shader versions for shadow rendering. - Decide the final API for custom visibility culling (Needed for shadows). - Profile/optimize. Known Issues: - Matcaps are not loaded until they’re shown elsewhere. (e.g. when opening the `Viewort Shading` UI) - Outlines are drawn between different materials of the same object. (Each material submesh has its own object handle) Reviewed By: fclem Maniphest Tasks: T101619 Differential Revision: https://developer.blender.org/D16826
2023-01-23 17:59:07 +01:00
bl_label = "Data"
bl_parent_id = "VIEWLAYER_PT_layer_passes"
Workbench: Remove old implementation
2023-09-04 17:42:04 +02:00
COMPAT_ENGINES = {'BLENDER_WORKBENCH'}
Workbench Next Rewrite of the Workbench engine using C++ and the new Draw Manager API. The new engine can be enabled in Blender `Preferences > Experimental > Workbench Next`. After that, the engine can be selected in `Properties > Scene > Render Engine`. When `Workbench Next` is the active engine, it also handles the `Solid` viewport mode rendering. The rewrite aims to be functionally equivalent to the current Workbench engine, but it also includes some small fixes/tweaks: - `In Front` rendered objects now work correctly with DoF and Shadows. - The `Sampling > Viewport` setting is actually used when the viewport is in `Render Mode`. - In `Texture` mode, textured materials also use the material properties. (Previously, only non textured materials would) To do: - Sculpt PBVH. - Volume rendering. - Hair rendering. - Use the "no_geom" shader versions for shadow rendering. - Decide the final API for custom visibility culling (Needed for shadows). - Profile/optimize. Known Issues: - Matcaps are not loaded until they’re shown elsewhere. (e.g. when opening the `Viewort Shading` UI) - Outlines are drawn between different materials of the same object. (Each material submesh has its own object handle) Reviewed By: fclem Maniphest Tasks: T101619 Differential Revision: https://developer.blender.org/D16826
2023-01-23 17:59:07 +01:00
def draw(self, context):
layout = self.layout
layout.use_property_split = True
layout.use_property_decorate = False
view_layer = context.view_layer
col = layout.column()
col.prop(view_layer, "use_pass_combined")
col.prop(view_layer, "use_pass_z")
EEVEE-Next: Display compatible properties panels Only a few are kept not available as their features are not yet supported.
2022-07-25 09:08:54 +02:00
EEVEE: Render Passes This patch adds new render passes to EEVEE. These passes include: * Emission * Diffuse Light * Diffuse Color * Glossy Light * Glossy Color * Environment * Volume Scattering * Volume Transmission * Bloom * Shadow With these passes it will be possible to use EEVEE effectively for compositing. During development we kept a close eye on how to get similar results compared to cycles render passes there are some differences that are related to how EEVEE works. For EEVEE we combined the passes to `Diffuse` and `Specular`. There are no transmittance or sss passes anymore. Cycles will be changed accordingly. Cycles volume transmittance is added to multiple surface col passes. For EEVEE we left the volume transmittance as a separate pass. Known Limitations * All materials that use alpha blending will not be rendered in the render passes. Other transparency modes are supported. * More GPU memory is required to store the render passes. When rendering a HD image with all render passes enabled at max extra 570MB GPU memory is required. Implementation Details An overview of render passes have been described in https://wiki.blender.org/wiki/Source/Render/EEVEE/RenderPasses Future Developments * In this implementation the materials are re-rendered for Diffuse/Glossy and Emission passes. We could use multi target rendering to improve the render speed. * Other passes can be added later * Don't render material based passes when only requesting AO or Shadow. * Add more passes to the system. These could include Cryptomatte, AOV's, Vector, ObjectID, MaterialID, UV. Reviewed By: Clément Foucault Differential Revision: https://developer.blender.org/D6331
2020-02-20 14:53:53 +01:00
class VIEWLAYER_PT_eevee_layer_passes_light(ViewLayerButtonsPanel, Panel):
bl_label = "Light"
EEVEE: Arbitrary Output Variables This patch adds support for AOVs in EEVEE. AOV Outputs can be defined in the render pass tab and used in shader materials. Both Object and World based shaders are supported. The AOV can be previewed in the viewport using the renderpass selector in the shading popover. AOV names that conflict with other AOVs are automatically corrected. AOV conflicts with render passes get a warning icon. The reason behind this is that changing render engines/passes can change the conflict, but you might not notice it. Changing this automatically would also make the materials incorrect, so best to leave this to the user. **Implementation** The patch adds a copies the AOV structures of Cycles into Blender. The goal is that the Cycles will use Blenders AOV defintions. In the Blender kernel (`layer.c`) the logic of these structures are implemented. The GLSL shader of any GPUMaterial can hold multiple outputs (the main output and the AOV outputs) based on the renderPassUBO the right output is selected. This selection uses an hash that encodes the AOV structure. The full AOV needed to be encoded when actually drawing the material pass as the AOV type changes the behavior of the AOV. This isn't known yet when the GLSL is compiled. **Future Developments** * The AOV definitions in the render layer panel isn't shared with Cycles. Cycles should be migrated to use the same viewlayer aovs. During a previous attempt this failed as the AOV validation in cycles and in Blender have implementation differences what made it crash when an aov name was invalid. This could be fixed by extending the external render engine API. * Add support to Cycles to render AOVs in the 3d viewport. * Use a drop down list for selecting AOVs in the AOV Output node. * Give user feedback when multiple AOV output nodes with the same AOV name exists in the same shader. * Fix viewing single channel images in the image editor [T83314] * Reduce viewport render time by only render needed draw passes. [T83316] Reviewed By: Brecht van Lommel, Clément Foucault Differential Revision: https://developer.blender.org/D7010
2020-12-04 08:13:54 +01:00
bl_parent_id = "VIEWLAYER_PT_layer_passes"
EEVEE-Next: UI cleanup of render settings panel - Rename Indirect Lighting panel to Light Probe and split options per probe type. - Rename Probe to Light Probe in the world panel. - Move the Ambient Occlusion distance to view layer. - Rename the Ambient Occlusion tab to Horizon Scan (waiting for a better name). - Split Sampling panel into viewport and render sub-panels. - Rename Volumetrics to Volumes to match Cycles. - Split light threshold to new Lights panel. - Simplify shadow panel option names. - Rename Viewport Denoising in Temporal Reprojection. - Move Motion Blur panel above the film panel. - Use / instead of & in raytracing panel. - Fix graying out of raytracing denoise options. Pull Request: https://projects.blender.org/blender/blender/pulls/113522
2023-10-11 20:27:30 +02:00
COMPAT_ENGINES = {'BLENDER_EEVEE'}
EEVEE: Render Passes This patch adds new render passes to EEVEE. These passes include: * Emission * Diffuse Light * Diffuse Color * Glossy Light * Glossy Color * Environment * Volume Scattering * Volume Transmission * Bloom * Shadow With these passes it will be possible to use EEVEE effectively for compositing. During development we kept a close eye on how to get similar results compared to cycles render passes there are some differences that are related to how EEVEE works. For EEVEE we combined the passes to `Diffuse` and `Specular`. There are no transmittance or sss passes anymore. Cycles will be changed accordingly. Cycles volume transmittance is added to multiple surface col passes. For EEVEE we left the volume transmittance as a separate pass. Known Limitations * All materials that use alpha blending will not be rendered in the render passes. Other transparency modes are supported. * More GPU memory is required to store the render passes. When rendering a HD image with all render passes enabled at max extra 570MB GPU memory is required. Implementation Details An overview of render passes have been described in https://wiki.blender.org/wiki/Source/Render/EEVEE/RenderPasses Future Developments * In this implementation the materials are re-rendered for Diffuse/Glossy and Emission passes. We could use multi target rendering to improve the render speed. * Other passes can be added later * Don't render material based passes when only requesting AO or Shadow. * Add more passes to the system. These could include Cryptomatte, AOV's, Vector, ObjectID, MaterialID, UV. Reviewed By: Clément Foucault Differential Revision: https://developer.blender.org/D6331
2020-02-20 14:53:53 +01:00
def draw(self, context):
layout = self.layout
layout.use_property_split = True
layout.use_property_decorate = False
view_layer = context.view_layer
view_layer_eevee = view_layer.eevee
UI: Layout changes for new checkbox layout possibilities Follow-up to previous commit. Some examples: {F8473507} {F8473508} {F8473509} {F8473510} For more screenshots, please see D7430. We use column or row headings here to bring more structure, and to give the eye visual anchors which aid eye-scanning. The left-aligned checkboxes likewise help with this. And we keep the adherence to the center line, so the alignment matches up between the various buttons and controls. * Changes the property split percentage from 50/50% to 40/60%. This is needed to give enough space for the checkboxes. But in most cases this looks better anyway - see Transform panel. In some cases it simply fills out the available space more efficently. * Fix various hacks where we previously used manually defined splits. When we did this, the alignment was never quite right, and the layout code was a mess. * Adds column headings to many places where a list of checkboxes all share a common purpose or leading text. * Add checkbox + value configurations various places where a checkbox only serves to enable the value slider * Removes most uses of grid flow layout. The grid flow layouts combine poorly with column headings, and also they would mess alignment up badly. The grid flow layouts also often made buttons and controls jump around on the screen if you would just resize editors slightly, causing visual confusion, making users lose their place. The logic for at what time the list of items would re-flow was often flawed, jumping to multiple columns too fast or too late - and frankly, the grid flow layouts would often just look bad. Maniphest Task: https://developer.blender.org/T65965 Differential Revision: https://developer.blender.org/D7430 Reviewed by: Brecht Van Lommel, Pablo Vazquez. Most work here by William Reynish, few changes by Julian Eisel.
2020-04-17 16:54:03 +02:00
col = layout.column(heading="Diffuse", align=True)
col.prop(view_layer, "use_pass_diffuse_direct", text="Light")
col.prop(view_layer, "use_pass_diffuse_color", text="Color")
col = layout.column(heading="Specular", align=True)
col.prop(view_layer, "use_pass_glossy_direct", text="Light")
col.prop(view_layer, "use_pass_glossy_color", text="Color")
I18n: disambiguate a few messages - "Lens" can be a transparent object used in cameras, or specifically its property of focal length - "Empty" can be an adjective meaning void, or an object type. The latter is already disambiguated using `ID_ID` - "New" and "Old" are adjectives that can have agreements in some languages - "Modified" is an adjective that can have agreement in some languages - "Clipping" can be a property of a camera, or a behavior of the mirror modifier - "Value" in HSV nodes, see #105113 - "Area" in the Face Area geometry node, can mean a measurement or a window type - "New" is an adjective that can have agreement - "Tab" can be a UI element or a whitespace character - "Volume" can mean a measurement or an object type. The latter is already disambiguated using `ID_ID` These changes introduce the new `BLT_I18NCONTEXT_TIME` translation context. They also remove `BLT_I18NCONTEXT_VIRTUAL_REALITY`, which I added at one point but then couldn't find which messages I wanted to fix with it. Ref #43295 Pull Request: #106718
2023-02-23 22:00:57 +01:00
col = layout.column(heading="Volume", heading_ctxt=i18n_contexts.id_id, align=True)
Eevee: Add Volume Transmittance to Color Render Passes. In Cycles the volume transmittance is already composited into the color passes. In Eevee the volume transmittance pass was separate and needed to be composited in the compositor. This patch adds the volume transmittance pass direct in the next render passes: * Diffuse Color * Specular Color * Emission * Environment This patch includes the removal of the volume transmittance render pass. It also renames the volume render passes to match Cycles. The setting themselves aren't unified. Maniphest Tasks: T81134
2020-12-14 09:05:16 +01:00
col.prop(view_layer_eevee, "use_pass_volume_direct", text="Light")
UI: Layout changes for new checkbox layout possibilities Follow-up to previous commit. Some examples: {F8473507} {F8473508} {F8473509} {F8473510} For more screenshots, please see D7430. We use column or row headings here to bring more structure, and to give the eye visual anchors which aid eye-scanning. The left-aligned checkboxes likewise help with this. And we keep the adherence to the center line, so the alignment matches up between the various buttons and controls. * Changes the property split percentage from 50/50% to 40/60%. This is needed to give enough space for the checkboxes. But in most cases this looks better anyway - see Transform panel. In some cases it simply fills out the available space more efficently. * Fix various hacks where we previously used manually defined splits. When we did this, the alignment was never quite right, and the layout code was a mess. * Adds column headings to many places where a list of checkboxes all share a common purpose or leading text. * Add checkbox + value configurations various places where a checkbox only serves to enable the value slider * Removes most uses of grid flow layout. The grid flow layouts combine poorly with column headings, and also they would mess alignment up badly. The grid flow layouts also often made buttons and controls jump around on the screen if you would just resize editors slightly, causing visual confusion, making users lose their place. The logic for at what time the list of items would re-flow was often flawed, jumping to multiple columns too fast or too late - and frankly, the grid flow layouts would often just look bad. Maniphest Task: https://developer.blender.org/T65965 Differential Revision: https://developer.blender.org/D7430 Reviewed by: Brecht Van Lommel, Pablo Vazquez. Most work here by William Reynish, few changes by Julian Eisel.
2020-04-17 16:54:03 +02:00
col = layout.column(heading="Other", align=True)
EEVEE: Render Passes This patch adds new render passes to EEVEE. These passes include: * Emission * Diffuse Light * Diffuse Color * Glossy Light * Glossy Color * Environment * Volume Scattering * Volume Transmission * Bloom * Shadow With these passes it will be possible to use EEVEE effectively for compositing. During development we kept a close eye on how to get similar results compared to cycles render passes there are some differences that are related to how EEVEE works. For EEVEE we combined the passes to `Diffuse` and `Specular`. There are no transmittance or sss passes anymore. Cycles will be changed accordingly. Cycles volume transmittance is added to multiple surface col passes. For EEVEE we left the volume transmittance as a separate pass. Known Limitations * All materials that use alpha blending will not be rendered in the render passes. Other transparency modes are supported. * More GPU memory is required to store the render passes. When rendering a HD image with all render passes enabled at max extra 570MB GPU memory is required. Implementation Details An overview of render passes have been described in https://wiki.blender.org/wiki/Source/Render/EEVEE/RenderPasses Future Developments * In this implementation the materials are re-rendered for Diffuse/Glossy and Emission passes. We could use multi target rendering to improve the render speed. * Other passes can be added later * Don't render material based passes when only requesting AO or Shadow. * Add more passes to the system. These could include Cryptomatte, AOV's, Vector, ObjectID, MaterialID, UV. Reviewed By: Clément Foucault Differential Revision: https://developer.blender.org/D6331
2020-02-20 14:53:53 +01:00
col.prop(view_layer, "use_pass_emit", text="Emission")
col.prop(view_layer, "use_pass_environment")
col.prop(view_layer, "use_pass_shadow")
Merge branch 'blender-v2.92-release'
2021-02-12 11:55:42 +01:00
col.prop(view_layer, "use_pass_ambient_occlusion",
text="Ambient Occlusion")
EEVEE: Render Passes This patch adds new render passes to EEVEE. These passes include: * Emission * Diffuse Light * Diffuse Color * Glossy Light * Glossy Color * Environment * Volume Scattering * Volume Transmission * Bloom * Shadow With these passes it will be possible to use EEVEE effectively for compositing. During development we kept a close eye on how to get similar results compared to cycles render passes there are some differences that are related to how EEVEE works. For EEVEE we combined the passes to `Diffuse` and `Specular`. There are no transmittance or sss passes anymore. Cycles will be changed accordingly. Cycles volume transmittance is added to multiple surface col passes. For EEVEE we left the volume transmittance as a separate pass. Known Limitations * All materials that use alpha blending will not be rendered in the render passes. Other transparency modes are supported. * More GPU memory is required to store the render passes. When rendering a HD image with all render passes enabled at max extra 570MB GPU memory is required. Implementation Details An overview of render passes have been described in https://wiki.blender.org/wiki/Source/Render/EEVEE/RenderPasses Future Developments * In this implementation the materials are re-rendered for Diffuse/Glossy and Emission passes. We could use multi target rendering to improve the render speed. * Other passes can be added later * Don't render material based passes when only requesting AO or Shadow. * Add more passes to the system. These could include Cryptomatte, AOV's, Vector, ObjectID, MaterialID, UV. Reviewed By: Clément Foucault Differential Revision: https://developer.blender.org/D6331
2020-02-20 14:53:53 +01:00
EEVEE-Next: UI cleanup of render settings panel - Rename Indirect Lighting panel to Light Probe and split options per probe type. - Rename Probe to Light Probe in the world panel. - Move the Ambient Occlusion distance to view layer. - Rename the Ambient Occlusion tab to Horizon Scan (waiting for a better name). - Split Sampling panel into viewport and render sub-panels. - Rename Volumetrics to Volumes to match Cycles. - Split light threshold to new Lights panel. - Simplify shadow panel option names. - Rename Viewport Denoising in Temporal Reprojection. - Move Motion Blur panel above the film panel. - Use / instead of & in raytracing panel. - Fix graying out of raytracing denoise options. Pull Request: https://projects.blender.org/blender/blender/pulls/113522
2023-10-11 20:27:30 +02:00
class VIEWLAYER_PT_eevee_layer_passes_light(ViewLayerButtonsPanel, Panel):
bl_label = "Light"
bl_parent_id = "VIEWLAYER_PT_layer_passes"
COMPAT_ENGINES = {'BLENDER_EEVEE_NEXT'}
def draw(self, context):
layout = self.layout
layout.use_property_split = True
layout.use_property_decorate = False
view_layer = context.view_layer
view_layer_eevee = view_layer.eevee
col = layout.column(heading="Diffuse", align=True)
col.prop(view_layer, "use_pass_diffuse_direct", text="Light")
col.prop(view_layer, "use_pass_diffuse_color", text="Color")
col = layout.column(heading="Specular", align=True)
col.prop(view_layer, "use_pass_glossy_direct", text="Light")
col.prop(view_layer, "use_pass_glossy_color", text="Color")
col = layout.column(heading="Volume", heading_ctxt=i18n_contexts.id_id, align=True)
col.prop(view_layer_eevee, "use_pass_volume_direct", text="Light")
col = layout.column(heading="Other", align=True)
col.prop(view_layer, "use_pass_emit", text="Emission")
col.prop(view_layer, "use_pass_environment")
col.prop(view_layer, "use_pass_shadow")
col.prop(view_layer, "use_pass_ambient_occlusion",
text="Ambient Occlusion")
col = layout.column()
col.active = view_layer.use_pass_ambient_occlusion
# TODO Move to view layer.
col.prop(context.scene.eevee, "gtao_distance", text="Occlusion Distance")
EEVEE: Render Passes This patch adds new render passes to EEVEE. These passes include: * Emission * Diffuse Light * Diffuse Color * Glossy Light * Glossy Color * Environment * Volume Scattering * Volume Transmission * Bloom * Shadow With these passes it will be possible to use EEVEE effectively for compositing. During development we kept a close eye on how to get similar results compared to cycles render passes there are some differences that are related to how EEVEE works. For EEVEE we combined the passes to `Diffuse` and `Specular`. There are no transmittance or sss passes anymore. Cycles will be changed accordingly. Cycles volume transmittance is added to multiple surface col passes. For EEVEE we left the volume transmittance as a separate pass. Known Limitations * All materials that use alpha blending will not be rendered in the render passes. Other transparency modes are supported. * More GPU memory is required to store the render passes. When rendering a HD image with all render passes enabled at max extra 570MB GPU memory is required. Implementation Details An overview of render passes have been described in https://wiki.blender.org/wiki/Source/Render/EEVEE/RenderPasses Future Developments * In this implementation the materials are re-rendered for Diffuse/Glossy and Emission passes. We could use multi target rendering to improve the render speed. * Other passes can be added later * Don't render material based passes when only requesting AO or Shadow. * Add more passes to the system. These could include Cryptomatte, AOV's, Vector, ObjectID, MaterialID, UV. Reviewed By: Clément Foucault Differential Revision: https://developer.blender.org/D6331
2020-02-20 14:53:53 +01:00
class VIEWLAYER_PT_eevee_layer_passes_effects(ViewLayerButtonsPanel, Panel):
bl_label = "Effects"
EEVEE: Arbitrary Output Variables This patch adds support for AOVs in EEVEE. AOV Outputs can be defined in the render pass tab and used in shader materials. Both Object and World based shaders are supported. The AOV can be previewed in the viewport using the renderpass selector in the shading popover. AOV names that conflict with other AOVs are automatically corrected. AOV conflicts with render passes get a warning icon. The reason behind this is that changing render engines/passes can change the conflict, but you might not notice it. Changing this automatically would also make the materials incorrect, so best to leave this to the user. **Implementation** The patch adds a copies the AOV structures of Cycles into Blender. The goal is that the Cycles will use Blenders AOV defintions. In the Blender kernel (`layer.c`) the logic of these structures are implemented. The GLSL shader of any GPUMaterial can hold multiple outputs (the main output and the AOV outputs) based on the renderPassUBO the right output is selected. This selection uses an hash that encodes the AOV structure. The full AOV needed to be encoded when actually drawing the material pass as the AOV type changes the behavior of the AOV. This isn't known yet when the GLSL is compiled. **Future Developments** * The AOV definitions in the render layer panel isn't shared with Cycles. Cycles should be migrated to use the same viewlayer aovs. During a previous attempt this failed as the AOV validation in cycles and in Blender have implementation differences what made it crash when an aov name was invalid. This could be fixed by extending the external render engine API. * Add support to Cycles to render AOVs in the 3d viewport. * Use a drop down list for selecting AOVs in the AOV Output node. * Give user feedback when multiple AOV output nodes with the same AOV name exists in the same shader. * Fix viewing single channel images in the image editor [T83314] * Reduce viewport render time by only render needed draw passes. [T83316] Reviewed By: Brecht van Lommel, Clément Foucault Differential Revision: https://developer.blender.org/D7010
2020-12-04 08:13:54 +01:00
bl_parent_id = "VIEWLAYER_PT_layer_passes"
EEVEE: Render Passes This patch adds new render passes to EEVEE. These passes include: * Emission * Diffuse Light * Diffuse Color * Glossy Light * Glossy Color * Environment * Volume Scattering * Volume Transmission * Bloom * Shadow With these passes it will be possible to use EEVEE effectively for compositing. During development we kept a close eye on how to get similar results compared to cycles render passes there are some differences that are related to how EEVEE works. For EEVEE we combined the passes to `Diffuse` and `Specular`. There are no transmittance or sss passes anymore. Cycles will be changed accordingly. Cycles volume transmittance is added to multiple surface col passes. For EEVEE we left the volume transmittance as a separate pass. Known Limitations * All materials that use alpha blending will not be rendered in the render passes. Other transparency modes are supported. * More GPU memory is required to store the render passes. When rendering a HD image with all render passes enabled at max extra 570MB GPU memory is required. Implementation Details An overview of render passes have been described in https://wiki.blender.org/wiki/Source/Render/EEVEE/RenderPasses Future Developments * In this implementation the materials are re-rendered for Diffuse/Glossy and Emission passes. We could use multi target rendering to improve the render speed. * Other passes can be added later * Don't render material based passes when only requesting AO or Shadow. * Add more passes to the system. These could include Cryptomatte, AOV's, Vector, ObjectID, MaterialID, UV. Reviewed By: Clément Foucault Differential Revision: https://developer.blender.org/D6331
2020-02-20 14:53:53 +01:00
COMPAT_ENGINES = {'BLENDER_EEVEE'}
def draw(self, context):
layout = self.layout
layout.use_property_split = True
layout.use_property_decorate = False
view_layer = context.view_layer
view_layer_eevee = view_layer.eevee
scene = context.scene
scene_eevee = scene.eevee
UI: Layout changes for new checkbox layout possibilities Follow-up to previous commit. Some examples: {F8473507} {F8473508} {F8473509} {F8473510} For more screenshots, please see D7430. We use column or row headings here to bring more structure, and to give the eye visual anchors which aid eye-scanning. The left-aligned checkboxes likewise help with this. And we keep the adherence to the center line, so the alignment matches up between the various buttons and controls. * Changes the property split percentage from 50/50% to 40/60%. This is needed to give enough space for the checkboxes. But in most cases this looks better anyway - see Transform panel. In some cases it simply fills out the available space more efficently. * Fix various hacks where we previously used manually defined splits. When we did this, the alignment was never quite right, and the layout code was a mess. * Adds column headings to many places where a list of checkboxes all share a common purpose or leading text. * Add checkbox + value configurations various places where a checkbox only serves to enable the value slider * Removes most uses of grid flow layout. The grid flow layouts combine poorly with column headings, and also they would mess alignment up badly. The grid flow layouts also often made buttons and controls jump around on the screen if you would just resize editors slightly, causing visual confusion, making users lose their place. The logic for at what time the list of items would re-flow was often flawed, jumping to multiple columns too fast or too late - and frankly, the grid flow layouts would often just look bad. Maniphest Task: https://developer.blender.org/T65965 Differential Revision: https://developer.blender.org/D7430 Reviewed by: Brecht Van Lommel, Pablo Vazquez. Most work here by William Reynish, few changes by Julian Eisel.
2020-04-17 16:54:03 +02:00
col = layout.column()
EEVEE: Render Passes This patch adds new render passes to EEVEE. These passes include: * Emission * Diffuse Light * Diffuse Color * Glossy Light * Glossy Color * Environment * Volume Scattering * Volume Transmission * Bloom * Shadow With these passes it will be possible to use EEVEE effectively for compositing. During development we kept a close eye on how to get similar results compared to cycles render passes there are some differences that are related to how EEVEE works. For EEVEE we combined the passes to `Diffuse` and `Specular`. There are no transmittance or sss passes anymore. Cycles will be changed accordingly. Cycles volume transmittance is added to multiple surface col passes. For EEVEE we left the volume transmittance as a separate pass. Known Limitations * All materials that use alpha blending will not be rendered in the render passes. Other transparency modes are supported. * More GPU memory is required to store the render passes. When rendering a HD image with all render passes enabled at max extra 570MB GPU memory is required. Implementation Details An overview of render passes have been described in https://wiki.blender.org/wiki/Source/Render/EEVEE/RenderPasses Future Developments * In this implementation the materials are re-rendered for Diffuse/Glossy and Emission passes. We could use multi target rendering to improve the render speed. * Other passes can be added later * Don't render material based passes when only requesting AO or Shadow. * Add more passes to the system. These could include Cryptomatte, AOV's, Vector, ObjectID, MaterialID, UV. Reviewed By: Clément Foucault Differential Revision: https://developer.blender.org/D6331
2020-02-20 14:53:53 +01:00
col.prop(view_layer_eevee, "use_pass_bloom", text="Bloom")
col.active = scene_eevee.use_bloom
EEVEE: Add Transparent Render-Pass option This renderpass pass outputs alpha blender surface to allow combining them with the opaque passes. Limitation: This only supports monochromatic opacity. Colored opacity will show differently than in combined pass. Pull Request: https://projects.blender.org/blender/blender/pulls/107890
2023-05-17 11:57:36 +02:00
col = layout.column()
col.prop(view_layer_eevee, "use_pass_transparent")
Cleanup: pep8, blank lines
2020-10-02 10:10:01 +10:00
Cycles: Use Blender Settings For AOV This patch will share the AOV settings between Cycles and Eevee. It enable using the AOV name conflict detection of Blender. This means that unlike how Cycles used to work it isn't possible to add an AOV with a similar name. Conflicts with internal render pass names will be indicated with an Warning icon. Reviewed By: Brecht van Lommel Differential Revision: https://developer.blender.org/D9774
2021-02-12 11:29:50 +01:00
class ViewLayerAOVPanel(ViewLayerButtonsPanel, Panel):
EEVEE: Arbitrary Output Variables This patch adds support for AOVs in EEVEE. AOV Outputs can be defined in the render pass tab and used in shader materials. Both Object and World based shaders are supported. The AOV can be previewed in the viewport using the renderpass selector in the shading popover. AOV names that conflict with other AOVs are automatically corrected. AOV conflicts with render passes get a warning icon. The reason behind this is that changing render engines/passes can change the conflict, but you might not notice it. Changing this automatically would also make the materials incorrect, so best to leave this to the user. **Implementation** The patch adds a copies the AOV structures of Cycles into Blender. The goal is that the Cycles will use Blenders AOV defintions. In the Blender kernel (`layer.c`) the logic of these structures are implemented. The GLSL shader of any GPUMaterial can hold multiple outputs (the main output and the AOV outputs) based on the renderPassUBO the right output is selected. This selection uses an hash that encodes the AOV structure. The full AOV needed to be encoded when actually drawing the material pass as the AOV type changes the behavior of the AOV. This isn't known yet when the GLSL is compiled. **Future Developments** * The AOV definitions in the render layer panel isn't shared with Cycles. Cycles should be migrated to use the same viewlayer aovs. During a previous attempt this failed as the AOV validation in cycles and in Blender have implementation differences what made it crash when an aov name was invalid. This could be fixed by extending the external render engine API. * Add support to Cycles to render AOVs in the 3d viewport. * Use a drop down list for selecting AOVs in the AOV Output node. * Give user feedback when multiple AOV output nodes with the same AOV name exists in the same shader. * Fix viewing single channel images in the image editor [T83314] * Reduce viewport render time by only render needed draw passes. [T83316] Reviewed By: Brecht van Lommel, Clément Foucault Differential Revision: https://developer.blender.org/D7010
2020-12-04 08:13:54 +01:00
bl_label = "Shader AOV"
def draw(self, context):
layout = self.layout
layout.use_property_split = True
layout.use_property_decorate = False
view_layer = context.view_layer
row = layout.row()
col = row.column()
Merge branch 'blender-v2.92-release'
2021-02-12 11:55:42 +01:00
col.template_list("VIEWLAYER_UL_aov", "aovs", view_layer,
Render: Add operators to add all used or remove all unused lightgroups These operators build a list of all lightgroups that are used by the view layer's scene and either add all used lightgroups that are not part of the view layer yet or remove all lightgroups in the view layer that are not being used. Differential Revision: https://developer.blender.org/D14596
2022-04-08 02:19:55 +02:00
"aovs", view_layer, "active_aov_index", rows=3)
EEVEE: Arbitrary Output Variables This patch adds support for AOVs in EEVEE. AOV Outputs can be defined in the render pass tab and used in shader materials. Both Object and World based shaders are supported. The AOV can be previewed in the viewport using the renderpass selector in the shading popover. AOV names that conflict with other AOVs are automatically corrected. AOV conflicts with render passes get a warning icon. The reason behind this is that changing render engines/passes can change the conflict, but you might not notice it. Changing this automatically would also make the materials incorrect, so best to leave this to the user. **Implementation** The patch adds a copies the AOV structures of Cycles into Blender. The goal is that the Cycles will use Blenders AOV defintions. In the Blender kernel (`layer.c`) the logic of these structures are implemented. The GLSL shader of any GPUMaterial can hold multiple outputs (the main output and the AOV outputs) based on the renderPassUBO the right output is selected. This selection uses an hash that encodes the AOV structure. The full AOV needed to be encoded when actually drawing the material pass as the AOV type changes the behavior of the AOV. This isn't known yet when the GLSL is compiled. **Future Developments** * The AOV definitions in the render layer panel isn't shared with Cycles. Cycles should be migrated to use the same viewlayer aovs. During a previous attempt this failed as the AOV validation in cycles and in Blender have implementation differences what made it crash when an aov name was invalid. This could be fixed by extending the external render engine API. * Add support to Cycles to render AOVs in the 3d viewport. * Use a drop down list for selecting AOVs in the AOV Output node. * Give user feedback when multiple AOV output nodes with the same AOV name exists in the same shader. * Fix viewing single channel images in the image editor [T83314] * Reduce viewport render time by only render needed draw passes. [T83316] Reviewed By: Brecht van Lommel, Clément Foucault Differential Revision: https://developer.blender.org/D7010
2020-12-04 08:13:54 +01:00
col = row.column()
sub = col.column(align=True)
sub.operator("scene.view_layer_add_aov", icon='ADD', text="")
sub.operator("scene.view_layer_remove_aov", icon='REMOVE', text="")
aov = view_layer.active_aov
if aov and not aov.is_valid:
Merge branch 'blender-v2.92-release'
2021-02-12 11:55:42 +01:00
layout.label(
text="Conflicts with another render pass with the same name", icon='ERROR')
EEVEE: Arbitrary Output Variables This patch adds support for AOVs in EEVEE. AOV Outputs can be defined in the render pass tab and used in shader materials. Both Object and World based shaders are supported. The AOV can be previewed in the viewport using the renderpass selector in the shading popover. AOV names that conflict with other AOVs are automatically corrected. AOV conflicts with render passes get a warning icon. The reason behind this is that changing render engines/passes can change the conflict, but you might not notice it. Changing this automatically would also make the materials incorrect, so best to leave this to the user. **Implementation** The patch adds a copies the AOV structures of Cycles into Blender. The goal is that the Cycles will use Blenders AOV defintions. In the Blender kernel (`layer.c`) the logic of these structures are implemented. The GLSL shader of any GPUMaterial can hold multiple outputs (the main output and the AOV outputs) based on the renderPassUBO the right output is selected. This selection uses an hash that encodes the AOV structure. The full AOV needed to be encoded when actually drawing the material pass as the AOV type changes the behavior of the AOV. This isn't known yet when the GLSL is compiled. **Future Developments** * The AOV definitions in the render layer panel isn't shared with Cycles. Cycles should be migrated to use the same viewlayer aovs. During a previous attempt this failed as the AOV validation in cycles and in Blender have implementation differences what made it crash when an aov name was invalid. This could be fixed by extending the external render engine API. * Add support to Cycles to render AOVs in the 3d viewport. * Use a drop down list for selecting AOVs in the AOV Output node. * Give user feedback when multiple AOV output nodes with the same AOV name exists in the same shader. * Fix viewing single channel images in the image editor [T83314] * Reduce viewport render time by only render needed draw passes. [T83316] Reviewed By: Brecht van Lommel, Clément Foucault Differential Revision: https://developer.blender.org/D7010
2020-12-04 08:13:54 +01:00
Cycles: Use Blender Settings For AOV This patch will share the AOV settings between Cycles and Eevee. It enable using the AOV name conflict detection of Blender. This means that unlike how Cycles used to work it isn't possible to add an AOV with a similar name. Conflicts with internal render pass names will be indicated with an Warning icon. Reviewed By: Brecht van Lommel Differential Revision: https://developer.blender.org/D9774
2021-02-12 11:29:50 +01:00
class VIEWLAYER_PT_layer_passes_aov(ViewLayerAOVPanel):
bl_parent_id = "VIEWLAYER_PT_layer_passes"
EEVEE-Next: Display compatible properties panels Only a few are kept not available as their features are not yet supported.
2022-07-25 09:08:54 +02:00
COMPAT_ENGINES = {'BLENDER_EEVEE', 'BLENDER_EEVEE_NEXT'}
EEVEE: Arbitrary Output Variables This patch adds support for AOVs in EEVEE. AOV Outputs can be defined in the render pass tab and used in shader materials. Both Object and World based shaders are supported. The AOV can be previewed in the viewport using the renderpass selector in the shading popover. AOV names that conflict with other AOVs are automatically corrected. AOV conflicts with render passes get a warning icon. The reason behind this is that changing render engines/passes can change the conflict, but you might not notice it. Changing this automatically would also make the materials incorrect, so best to leave this to the user. **Implementation** The patch adds a copies the AOV structures of Cycles into Blender. The goal is that the Cycles will use Blenders AOV defintions. In the Blender kernel (`layer.c`) the logic of these structures are implemented. The GLSL shader of any GPUMaterial can hold multiple outputs (the main output and the AOV outputs) based on the renderPassUBO the right output is selected. This selection uses an hash that encodes the AOV structure. The full AOV needed to be encoded when actually drawing the material pass as the AOV type changes the behavior of the AOV. This isn't known yet when the GLSL is compiled. **Future Developments** * The AOV definitions in the render layer panel isn't shared with Cycles. Cycles should be migrated to use the same viewlayer aovs. During a previous attempt this failed as the AOV validation in cycles and in Blender have implementation differences what made it crash when an aov name was invalid. This could be fixed by extending the external render engine API. * Add support to Cycles to render AOVs in the 3d viewport. * Use a drop down list for selecting AOVs in the AOV Output node. * Give user feedback when multiple AOV output nodes with the same AOV name exists in the same shader. * Fix viewing single channel images in the image editor [T83314] * Reduce viewport render time by only render needed draw passes. [T83316] Reviewed By: Brecht van Lommel, Clément Foucault Differential Revision: https://developer.blender.org/D7010
2020-12-04 08:13:54 +01:00
Fix Cryptomatte panel not visible in EEVEE Caused by {rB5baae026a86f}
2020-12-07 09:31:05 +01:00
class ViewLayerCryptomattePanel(ViewLayerButtonsPanel, Panel):
EEVEE Cryptomatte Cryptomatte is a standard to efficiently create mattes for compositing. The renderer outputs the required render passes, which can then be used in the compositor to create masks for specified objects. Unlike the Material and Object Index passes, the objects to isolate are selected in compositing, and mattes will be anti-aliased. Cryptomatte was already available in Cycles this patch adds it to the EEVEE render engine. Original specification can be found at https://raw.githubusercontent.com/Psyop/Cryptomatte/master/specification/IDmattes_poster.pdf **Accurate mode** Following Cycles, there are two accuracy modes. The difference between the two modes is the number of render samples they take into account to create the render passes. When accurate mode is off the number of levels is used. When accuracy mode is active, the number of render samples is used. **Deviation from standard** Cryptomatte specification is based on a path trace approach where samples and coverage are calculated at the same time. In EEVEE a sample is an exact match on top of a prepared depth buffer. Coverage is at that moment always 1. By sampling multiple times the number of surface hits decides the actual surface coverage for a matte per pixel. **Implementation Overview** When drawing to the cryptomatte GPU buffer the depth of the fragment is matched to the active depth buffer. The hashes of each cryptomatte layer is written in the GPU buffer. The exact layout depends on the active cryptomatte layers. The GPU buffer is downloaded and integrated into an accumulation buffer (stored in CPU RAM). The accumulation buffer stores the hashes + weights for a number of levels, layers per pixel. When a hash already exists the weight will be increased. When the hash doesn't exists it will be added to the buffer. After all the samples have been calculated the accumulation buffer is processed. During this phase the total pixel weights of each layer is mapped to be in a range between 0 and 1. The hashes are also sorted (highest weight first). Blender Kernel now has a `BKE_cryptomatte` header that access to common functions for cryptomatte. This will in the future be used by the API. * Alpha blended materials aren't supported. Alpha blended materials support in render passes needs research how to implement it in a maintainable way for any render pass. This is a list of tasks that needs to be done for the same release that this patch lands on (Blender 2.92) * T82571 Add render tests. * T82572 Documentation. * T82573 Store hashes + Object names in the render result header. * T82574 Use threading to increase performance in accumulation and post processing. * T82575 Merge the cycles and EEVEE settings as they are identical. * T82576 Add RNA to extract the cryptomatte hashes to use in python scripts. Reviewed By: Clément Foucault Maniphest Tasks: T81058 Differential Revision: https://developer.blender.org/D9165
2020-12-04 08:28:43 +01:00
bl_label = "Cryptomatte"
def draw(self, context):
layout = self.layout
layout.use_property_split = True
layout.use_property_decorate = False
view_layer = context.view_layer
col = layout.column()
col.prop(view_layer, "use_pass_cryptomatte_object", text="Object")
col.prop(view_layer, "use_pass_cryptomatte_material", text="Material")
col.prop(view_layer, "use_pass_cryptomatte_asset", text="Asset")
col = layout.column()
Cleanup: trailing space
2020-12-11 14:59:08 +11:00
col.active = any((view_layer.use_pass_cryptomatte_object,
view_layer.use_pass_cryptomatte_material,
EEVEE Cryptomatte Cryptomatte is a standard to efficiently create mattes for compositing. The renderer outputs the required render passes, which can then be used in the compositor to create masks for specified objects. Unlike the Material and Object Index passes, the objects to isolate are selected in compositing, and mattes will be anti-aliased. Cryptomatte was already available in Cycles this patch adds it to the EEVEE render engine. Original specification can be found at https://raw.githubusercontent.com/Psyop/Cryptomatte/master/specification/IDmattes_poster.pdf **Accurate mode** Following Cycles, there are two accuracy modes. The difference between the two modes is the number of render samples they take into account to create the render passes. When accurate mode is off the number of levels is used. When accuracy mode is active, the number of render samples is used. **Deviation from standard** Cryptomatte specification is based on a path trace approach where samples and coverage are calculated at the same time. In EEVEE a sample is an exact match on top of a prepared depth buffer. Coverage is at that moment always 1. By sampling multiple times the number of surface hits decides the actual surface coverage for a matte per pixel. **Implementation Overview** When drawing to the cryptomatte GPU buffer the depth of the fragment is matched to the active depth buffer. The hashes of each cryptomatte layer is written in the GPU buffer. The exact layout depends on the active cryptomatte layers. The GPU buffer is downloaded and integrated into an accumulation buffer (stored in CPU RAM). The accumulation buffer stores the hashes + weights for a number of levels, layers per pixel. When a hash already exists the weight will be increased. When the hash doesn't exists it will be added to the buffer. After all the samples have been calculated the accumulation buffer is processed. During this phase the total pixel weights of each layer is mapped to be in a range between 0 and 1. The hashes are also sorted (highest weight first). Blender Kernel now has a `BKE_cryptomatte` header that access to common functions for cryptomatte. This will in the future be used by the API. * Alpha blended materials aren't supported. Alpha blended materials support in render passes needs research how to implement it in a maintainable way for any render pass. This is a list of tasks that needs to be done for the same release that this patch lands on (Blender 2.92) * T82571 Add render tests. * T82572 Documentation. * T82573 Store hashes + Object names in the render result header. * T82574 Use threading to increase performance in accumulation and post processing. * T82575 Merge the cycles and EEVEE settings as they are identical. * T82576 Add RNA to extract the cryptomatte hashes to use in python scripts. Reviewed By: Clément Foucault Maniphest Tasks: T81058 Differential Revision: https://developer.blender.org/D9165
2020-12-04 08:28:43 +01:00
view_layer.use_pass_cryptomatte_asset))
col.prop(view_layer, "pass_cryptomatte_depth", text="Levels")
Fix Cryptomatte accurate option showing for Cycles, only needed for Eevee
2021-11-18 16:27:21 +01:00
if context.engine == 'BLENDER_EEVEE':
col.prop(view_layer, "use_pass_cryptomatte_accurate",
text="Accurate Mode")
EEVEE Cryptomatte Cryptomatte is a standard to efficiently create mattes for compositing. The renderer outputs the required render passes, which can then be used in the compositor to create masks for specified objects. Unlike the Material and Object Index passes, the objects to isolate are selected in compositing, and mattes will be anti-aliased. Cryptomatte was already available in Cycles this patch adds it to the EEVEE render engine. Original specification can be found at https://raw.githubusercontent.com/Psyop/Cryptomatte/master/specification/IDmattes_poster.pdf **Accurate mode** Following Cycles, there are two accuracy modes. The difference between the two modes is the number of render samples they take into account to create the render passes. When accurate mode is off the number of levels is used. When accuracy mode is active, the number of render samples is used. **Deviation from standard** Cryptomatte specification is based on a path trace approach where samples and coverage are calculated at the same time. In EEVEE a sample is an exact match on top of a prepared depth buffer. Coverage is at that moment always 1. By sampling multiple times the number of surface hits decides the actual surface coverage for a matte per pixel. **Implementation Overview** When drawing to the cryptomatte GPU buffer the depth of the fragment is matched to the active depth buffer. The hashes of each cryptomatte layer is written in the GPU buffer. The exact layout depends on the active cryptomatte layers. The GPU buffer is downloaded and integrated into an accumulation buffer (stored in CPU RAM). The accumulation buffer stores the hashes + weights for a number of levels, layers per pixel. When a hash already exists the weight will be increased. When the hash doesn't exists it will be added to the buffer. After all the samples have been calculated the accumulation buffer is processed. During this phase the total pixel weights of each layer is mapped to be in a range between 0 and 1. The hashes are also sorted (highest weight first). Blender Kernel now has a `BKE_cryptomatte` header that access to common functions for cryptomatte. This will in the future be used by the API. * Alpha blended materials aren't supported. Alpha blended materials support in render passes needs research how to implement it in a maintainable way for any render pass. This is a list of tasks that needs to be done for the same release that this patch lands on (Blender 2.92) * T82571 Add render tests. * T82572 Documentation. * T82573 Store hashes + Object names in the render result header. * T82574 Use threading to increase performance in accumulation and post processing. * T82575 Merge the cycles and EEVEE settings as they are identical. * T82576 Add RNA to extract the cryptomatte hashes to use in python scripts. Reviewed By: Clément Foucault Maniphest Tasks: T81058 Differential Revision: https://developer.blender.org/D9165
2020-12-04 08:28:43 +01:00
Cleanup: don't subclass 'Panel' for mix-in classes This reports warnings with `--debug-python` since all panel sub-classes are expected to be registered.
2021-02-12 15:21:37 +11:00
class VIEWLAYER_PT_layer_passes_cryptomatte(ViewLayerCryptomattePanel, Panel):
Fix Cryptomatte panel not visible in EEVEE Caused by {rB5baae026a86f}
2020-12-07 09:31:05 +01:00
bl_parent_id = "VIEWLAYER_PT_layer_passes"
EEVEE-Next: Cryptomatte render passes. This change adds cryptomatte render passes to EEVEE-Next. Due to the upcoming viewport compositor we also improved cryptomatte so it will be real-time. This also allows viewing the cryptomatte passes in the viewport directly. {F13482749} A surface shader would store any active cryptomatte layer to a texture. Object hash is stored as R, Asset hash as G and Material hash as B. Hashes are only calculated when the cryptomatte layer is active to reduce any unneeded work. During film accumulation the hashes are separated and stored in a texture array that matches the cryptomatte standard. For the real-time use case sorting is skipped. For final rendering the samples are sorted and normalized. NOTE: Eventually we should also do sample normalization in the viewport in order to extract the correct mask when using the viewport compositor. Reviewed By: fclem Maniphest Tasks: T99390 Differential Revision: https://developer.blender.org/D15753
2022-09-13 11:07:30 +02:00
COMPAT_ENGINES = {'BLENDER_EEVEE', 'BLENDER_EEVEE_NEXT'}
Fix Cryptomatte panel not visible in EEVEE Caused by {rB5baae026a86f}
2020-12-07 09:31:05 +01:00
Render: Add operators to add all used or remove all unused lightgroups These operators build a list of all lightgroups that are used by the view layer's scene and either add all used lightgroups that are not part of the view layer yet or remove all lightgroups in the view layer that are not being used. Differential Revision: https://developer.blender.org/D14596
2022-04-08 02:19:55 +02:00
class VIEWLAYER_MT_lightgroup_sync(Menu):
bl_label = "Lightgroup Sync"
def draw(self, _context):
layout = self.layout
layout.operator("scene.view_layer_add_used_lightgroups", icon='ADD')
layout.operator("scene.view_layer_remove_unused_lightgroups", icon='REMOVE')
Cycles: Add support for light groups Light groups are a type of pass that only contains lighting from a subset of light sources. They are created in the View layer, and light sources (lamps, objects with emissive materials and/or the environment) can be assigned to a group. Currently, each light group ends up generating its own version of the Combined pass. In the future, additional types of passes (e.g. shadowcatcher) might be getting their own per-lightgroup versions. The lightgroup creation and assignment is not Cycles-specific, so Eevee or external render engines could make use of it in the future. Note that Lightgroups are identified by their name - therefore, the name of the Lightgroup in the View Layer and the name that's set in an object's settings must match for it to be included. Currently, changing a Lightgroup's name does not update objects - this is planned for the future, along with other features such as denoising for light groups and viewing them in preview renders. Original patch by Alex Fuller (@mistaed), with some polishing by Lukas Stockner (@lukasstockner97). Differential Revision: https://developer.blender.org/D12871
2022-04-02 00:11:11 +02:00
class ViewLayerLightgroupsPanel(ViewLayerButtonsPanel, Panel):
bl_label = "Light Groups"
def draw(self, context):
layout = self.layout
layout.use_property_split = True
layout.use_property_decorate = False
view_layer = context.view_layer
row = layout.row()
col = row.column()
col.template_list("UI_UL_list", "lightgroups", view_layer,
Render: Add operators to add all used or remove all unused lightgroups These operators build a list of all lightgroups that are used by the view layer's scene and either add all used lightgroups that are not part of the view layer yet or remove all lightgroups in the view layer that are not being used. Differential Revision: https://developer.blender.org/D14596
2022-04-08 02:19:55 +02:00
"lightgroups", view_layer, "active_lightgroup_index", rows=3)
Cycles: Add support for light groups Light groups are a type of pass that only contains lighting from a subset of light sources. They are created in the View layer, and light sources (lamps, objects with emissive materials and/or the environment) can be assigned to a group. Currently, each light group ends up generating its own version of the Combined pass. In the future, additional types of passes (e.g. shadowcatcher) might be getting their own per-lightgroup versions. The lightgroup creation and assignment is not Cycles-specific, so Eevee or external render engines could make use of it in the future. Note that Lightgroups are identified by their name - therefore, the name of the Lightgroup in the View Layer and the name that's set in an object's settings must match for it to be included. Currently, changing a Lightgroup's name does not update objects - this is planned for the future, along with other features such as denoising for light groups and viewing them in preview renders. Original patch by Alex Fuller (@mistaed), with some polishing by Lukas Stockner (@lukasstockner97). Differential Revision: https://developer.blender.org/D12871
2022-04-02 00:11:11 +02:00
col = row.column()
sub = col.column(align=True)
sub.operator("scene.view_layer_add_lightgroup", icon='ADD', text="")
sub.operator("scene.view_layer_remove_lightgroup", icon='REMOVE', text="")
Render: Add operators to add all used or remove all unused lightgroups These operators build a list of all lightgroups that are used by the view layer's scene and either add all used lightgroups that are not part of the view layer yet or remove all lightgroups in the view layer that are not being used. Differential Revision: https://developer.blender.org/D14596
2022-04-08 02:19:55 +02:00
sub.separator()
sub.menu("VIEWLAYER_MT_lightgroup_sync", icon='DOWNARROW_HLT', text="")
Cycles: Add support for light groups Light groups are a type of pass that only contains lighting from a subset of light sources. They are created in the View layer, and light sources (lamps, objects with emissive materials and/or the environment) can be assigned to a group. Currently, each light group ends up generating its own version of the Combined pass. In the future, additional types of passes (e.g. shadowcatcher) might be getting their own per-lightgroup versions. The lightgroup creation and assignment is not Cycles-specific, so Eevee or external render engines could make use of it in the future. Note that Lightgroups are identified by their name - therefore, the name of the Lightgroup in the View Layer and the name that's set in an object's settings must match for it to be included. Currently, changing a Lightgroup's name does not update objects - this is planned for the future, along with other features such as denoising for light groups and viewing them in preview renders. Original patch by Alex Fuller (@mistaed), with some polishing by Lukas Stockner (@lukasstockner97). Differential Revision: https://developer.blender.org/D12871
2022-04-02 00:11:11 +02:00
class VIEWLAYER_PT_layer_passes_lightgroups(ViewLayerLightgroupsPanel):
bl_parent_id = "VIEWLAYER_PT_layer_passes"
COMPAT_ENGINES = {'CYCLES'}
UI: add a Custom Properties panel to the View Layer tab of properties. Although view layers aren't ID, they do support custom properties, so not providing the UI to access them seems to be a simple oversight.
2022-09-12 00:32:21 +03:00
class VIEWLAYER_PT_layer_custom_props(PropertyPanel, Panel):
bl_space_type = 'PROPERTIES'
bl_region_type = 'WINDOW'
bl_context = "view_layer"
_context_path = "view_layer"
_property_type = ViewLayer
PyAPI: remove bpy.utils.register_module() In preparation for it being removed, see: T47811
2017-03-18 20:03:24 +11:00
classes = (
Render: Add operators to add all used or remove all unused lightgroups These operators build a list of all lightgroups that are used by the view layer's scene and either add all used lightgroups that are not part of the view layer yet or remove all lightgroups in the view layer that are not being used. Differential Revision: https://developer.blender.org/D14596
2022-04-08 02:19:55 +02:00
VIEWLAYER_MT_lightgroup_sync,
Workspaces: active view layer now always comes from workspace, not scene. Both the scene and workspace had an active view layer, and it was confusing which settings were being used or displayed where. Now we always have one, so there is no mismatch. The "View Layers" tab in the properties editor is now "View Layer", no longer showing a list of layers. Instead view layers can be added and removed with the workspace view layer selector. They are also listed and selectable in the outliner. Single layer rendering uses the active view layer from the workspace. This fixes bugs where the wrong active view layer was used, but more places remain that are wrong and are now using the first view layer in the scene. These are all marked with BKE_view_layer_context_active_PLACEHOLDER.
2018-04-24 15:20:17 +02:00
VIEWLAYER_PT_layer,
EEVEE: Arbitrary Output Variables This patch adds support for AOVs in EEVEE. AOV Outputs can be defined in the render pass tab and used in shader materials. Both Object and World based shaders are supported. The AOV can be previewed in the viewport using the renderpass selector in the shading popover. AOV names that conflict with other AOVs are automatically corrected. AOV conflicts with render passes get a warning icon. The reason behind this is that changing render engines/passes can change the conflict, but you might not notice it. Changing this automatically would also make the materials incorrect, so best to leave this to the user. **Implementation** The patch adds a copies the AOV structures of Cycles into Blender. The goal is that the Cycles will use Blenders AOV defintions. In the Blender kernel (`layer.c`) the logic of these structures are implemented. The GLSL shader of any GPUMaterial can hold multiple outputs (the main output and the AOV outputs) based on the renderPassUBO the right output is selected. This selection uses an hash that encodes the AOV structure. The full AOV needed to be encoded when actually drawing the material pass as the AOV type changes the behavior of the AOV. This isn't known yet when the GLSL is compiled. **Future Developments** * The AOV definitions in the render layer panel isn't shared with Cycles. Cycles should be migrated to use the same viewlayer aovs. During a previous attempt this failed as the AOV validation in cycles and in Blender have implementation differences what made it crash when an aov name was invalid. This could be fixed by extending the external render engine API. * Add support to Cycles to render AOVs in the 3d viewport. * Use a drop down list for selecting AOVs in the AOV Output node. * Give user feedback when multiple AOV output nodes with the same AOV name exists in the same shader. * Fix viewing single channel images in the image editor [T83314] * Reduce viewport render time by only render needed draw passes. [T83316] Reviewed By: Brecht van Lommel, Clément Foucault Differential Revision: https://developer.blender.org/D7010
2020-12-04 08:13:54 +01:00
VIEWLAYER_PT_layer_passes,
Workbench: Remove old implementation
2023-09-04 17:42:04 +02:00
VIEWLAYER_PT_workbench_layer_passes_data,
EEVEE: Render Passes This patch adds new render passes to EEVEE. These passes include: * Emission * Diffuse Light * Diffuse Color * Glossy Light * Glossy Color * Environment * Volume Scattering * Volume Transmission * Bloom * Shadow With these passes it will be possible to use EEVEE effectively for compositing. During development we kept a close eye on how to get similar results compared to cycles render passes there are some differences that are related to how EEVEE works. For EEVEE we combined the passes to `Diffuse` and `Specular`. There are no transmittance or sss passes anymore. Cycles will be changed accordingly. Cycles volume transmittance is added to multiple surface col passes. For EEVEE we left the volume transmittance as a separate pass. Known Limitations * All materials that use alpha blending will not be rendered in the render passes. Other transparency modes are supported. * More GPU memory is required to store the render passes. When rendering a HD image with all render passes enabled at max extra 570MB GPU memory is required. Implementation Details An overview of render passes have been described in https://wiki.blender.org/wiki/Source/Render/EEVEE/RenderPasses Future Developments * In this implementation the materials are re-rendered for Diffuse/Glossy and Emission passes. We could use multi target rendering to improve the render speed. * Other passes can be added later * Don't render material based passes when only requesting AO or Shadow. * Add more passes to the system. These could include Cryptomatte, AOV's, Vector, ObjectID, MaterialID, UV. Reviewed By: Clément Foucault Differential Revision: https://developer.blender.org/D6331
2020-02-20 14:53:53 +01:00
VIEWLAYER_PT_eevee_layer_passes_data,
EEVEE-Next: Add back data passes UI and missing passes The `VIEWLAYER_PT_eevee_next_layer_passes_data` class name was re-used by mistake for Workbench Next in ba982119cd, and the actual EEVEE Next class was then removed in 678dc456e3. This adds back the UI as it was, and the missing passes (Vector and Position) it referenced. Pull Request: https://projects.blender.org/blender/blender/pulls/112162
2023-09-11 20:14:04 +02:00
VIEWLAYER_PT_eevee_next_layer_passes_data,
EEVEE: Render Passes This patch adds new render passes to EEVEE. These passes include: * Emission * Diffuse Light * Diffuse Color * Glossy Light * Glossy Color * Environment * Volume Scattering * Volume Transmission * Bloom * Shadow With these passes it will be possible to use EEVEE effectively for compositing. During development we kept a close eye on how to get similar results compared to cycles render passes there are some differences that are related to how EEVEE works. For EEVEE we combined the passes to `Diffuse` and `Specular`. There are no transmittance or sss passes anymore. Cycles will be changed accordingly. Cycles volume transmittance is added to multiple surface col passes. For EEVEE we left the volume transmittance as a separate pass. Known Limitations * All materials that use alpha blending will not be rendered in the render passes. Other transparency modes are supported. * More GPU memory is required to store the render passes. When rendering a HD image with all render passes enabled at max extra 570MB GPU memory is required. Implementation Details An overview of render passes have been described in https://wiki.blender.org/wiki/Source/Render/EEVEE/RenderPasses Future Developments * In this implementation the materials are re-rendered for Diffuse/Glossy and Emission passes. We could use multi target rendering to improve the render speed. * Other passes can be added later * Don't render material based passes when only requesting AO or Shadow. * Add more passes to the system. These could include Cryptomatte, AOV's, Vector, ObjectID, MaterialID, UV. Reviewed By: Clément Foucault Differential Revision: https://developer.blender.org/D6331
2020-02-20 14:53:53 +01:00
VIEWLAYER_PT_eevee_layer_passes_light,
VIEWLAYER_PT_eevee_layer_passes_effects,
EEVEE Cryptomatte Cryptomatte is a standard to efficiently create mattes for compositing. The renderer outputs the required render passes, which can then be used in the compositor to create masks for specified objects. Unlike the Material and Object Index passes, the objects to isolate are selected in compositing, and mattes will be anti-aliased. Cryptomatte was already available in Cycles this patch adds it to the EEVEE render engine. Original specification can be found at https://raw.githubusercontent.com/Psyop/Cryptomatte/master/specification/IDmattes_poster.pdf **Accurate mode** Following Cycles, there are two accuracy modes. The difference between the two modes is the number of render samples they take into account to create the render passes. When accurate mode is off the number of levels is used. When accuracy mode is active, the number of render samples is used. **Deviation from standard** Cryptomatte specification is based on a path trace approach where samples and coverage are calculated at the same time. In EEVEE a sample is an exact match on top of a prepared depth buffer. Coverage is at that moment always 1. By sampling multiple times the number of surface hits decides the actual surface coverage for a matte per pixel. **Implementation Overview** When drawing to the cryptomatte GPU buffer the depth of the fragment is matched to the active depth buffer. The hashes of each cryptomatte layer is written in the GPU buffer. The exact layout depends on the active cryptomatte layers. The GPU buffer is downloaded and integrated into an accumulation buffer (stored in CPU RAM). The accumulation buffer stores the hashes + weights for a number of levels, layers per pixel. When a hash already exists the weight will be increased. When the hash doesn't exists it will be added to the buffer. After all the samples have been calculated the accumulation buffer is processed. During this phase the total pixel weights of each layer is mapped to be in a range between 0 and 1. The hashes are also sorted (highest weight first). Blender Kernel now has a `BKE_cryptomatte` header that access to common functions for cryptomatte. This will in the future be used by the API. * Alpha blended materials aren't supported. Alpha blended materials support in render passes needs research how to implement it in a maintainable way for any render pass. This is a list of tasks that needs to be done for the same release that this patch lands on (Blender 2.92) * T82571 Add render tests. * T82572 Documentation. * T82573 Store hashes + Object names in the render result header. * T82574 Use threading to increase performance in accumulation and post processing. * T82575 Merge the cycles and EEVEE settings as they are identical. * T82576 Add RNA to extract the cryptomatte hashes to use in python scripts. Reviewed By: Clément Foucault Maniphest Tasks: T81058 Differential Revision: https://developer.blender.org/D9165
2020-12-04 08:28:43 +01:00
VIEWLAYER_PT_layer_passes_cryptomatte,
EEVEE: Arbitrary Output Variables This patch adds support for AOVs in EEVEE. AOV Outputs can be defined in the render pass tab and used in shader materials. Both Object and World based shaders are supported. The AOV can be previewed in the viewport using the renderpass selector in the shading popover. AOV names that conflict with other AOVs are automatically corrected. AOV conflicts with render passes get a warning icon. The reason behind this is that changing render engines/passes can change the conflict, but you might not notice it. Changing this automatically would also make the materials incorrect, so best to leave this to the user. **Implementation** The patch adds a copies the AOV structures of Cycles into Blender. The goal is that the Cycles will use Blenders AOV defintions. In the Blender kernel (`layer.c`) the logic of these structures are implemented. The GLSL shader of any GPUMaterial can hold multiple outputs (the main output and the AOV outputs) based on the renderPassUBO the right output is selected. This selection uses an hash that encodes the AOV structure. The full AOV needed to be encoded when actually drawing the material pass as the AOV type changes the behavior of the AOV. This isn't known yet when the GLSL is compiled. **Future Developments** * The AOV definitions in the render layer panel isn't shared with Cycles. Cycles should be migrated to use the same viewlayer aovs. During a previous attempt this failed as the AOV validation in cycles and in Blender have implementation differences what made it crash when an aov name was invalid. This could be fixed by extending the external render engine API. * Add support to Cycles to render AOVs in the 3d viewport. * Use a drop down list for selecting AOVs in the AOV Output node. * Give user feedback when multiple AOV output nodes with the same AOV name exists in the same shader. * Fix viewing single channel images in the image editor [T83314] * Reduce viewport render time by only render needed draw passes. [T83316] Reviewed By: Brecht van Lommel, Clément Foucault Differential Revision: https://developer.blender.org/D7010
2020-12-04 08:13:54 +01:00
VIEWLAYER_PT_layer_passes_aov,
Cycles: Add support for light groups Light groups are a type of pass that only contains lighting from a subset of light sources. They are created in the View layer, and light sources (lamps, objects with emissive materials and/or the environment) can be assigned to a group. Currently, each light group ends up generating its own version of the Combined pass. In the future, additional types of passes (e.g. shadowcatcher) might be getting their own per-lightgroup versions. The lightgroup creation and assignment is not Cycles-specific, so Eevee or external render engines could make use of it in the future. Note that Lightgroups are identified by their name - therefore, the name of the Lightgroup in the View Layer and the name that's set in an object's settings must match for it to be included. Currently, changing a Lightgroup's name does not update objects - this is planned for the future, along with other features such as denoising for light groups and viewing them in preview renders. Original patch by Alex Fuller (@mistaed), with some polishing by Lukas Stockner (@lukasstockner97). Differential Revision: https://developer.blender.org/D12871
2022-04-02 00:11:11 +02:00
VIEWLAYER_PT_layer_passes_lightgroups,
UI: add a Custom Properties panel to the View Layer tab of properties. Although view layers aren't ID, they do support custom properties, so not providing the UI to access them seems to be a simple oversight.
2022-09-12 00:32:21 +03:00
VIEWLAYER_PT_layer_custom_props,
EEVEE: Arbitrary Output Variables This patch adds support for AOVs in EEVEE. AOV Outputs can be defined in the render pass tab and used in shader materials. Both Object and World based shaders are supported. The AOV can be previewed in the viewport using the renderpass selector in the shading popover. AOV names that conflict with other AOVs are automatically corrected. AOV conflicts with render passes get a warning icon. The reason behind this is that changing render engines/passes can change the conflict, but you might not notice it. Changing this automatically would also make the materials incorrect, so best to leave this to the user. **Implementation** The patch adds a copies the AOV structures of Cycles into Blender. The goal is that the Cycles will use Blenders AOV defintions. In the Blender kernel (`layer.c`) the logic of these structures are implemented. The GLSL shader of any GPUMaterial can hold multiple outputs (the main output and the AOV outputs) based on the renderPassUBO the right output is selected. This selection uses an hash that encodes the AOV structure. The full AOV needed to be encoded when actually drawing the material pass as the AOV type changes the behavior of the AOV. This isn't known yet when the GLSL is compiled. **Future Developments** * The AOV definitions in the render layer panel isn't shared with Cycles. Cycles should be migrated to use the same viewlayer aovs. During a previous attempt this failed as the AOV validation in cycles and in Blender have implementation differences what made it crash when an aov name was invalid. This could be fixed by extending the external render engine API. * Add support to Cycles to render AOVs in the 3d viewport. * Use a drop down list for selecting AOVs in the AOV Output node. * Give user feedback when multiple AOV output nodes with the same AOV name exists in the same shader. * Fix viewing single channel images in the image editor [T83314] * Reduce viewport render time by only render needed draw passes. [T83316] Reviewed By: Brecht van Lommel, Clément Foucault Differential Revision: https://developer.blender.org/D7010
2020-12-04 08:13:54 +01:00
VIEWLAYER_UL_aov,
PyAPI: remove bpy.utils.register_module() In preparation for it being removed, see: T47811
2017-03-18 20:03:24 +11:00
)
Improvements of Freestyle GUI controls - Part 1. This commit makes a set of fixes and improvements based on the results of Freestyle branch review by Brecht. The discussion thread is: http://lists.blender.org/pipermail/bf-committers/2012-October/037927.html * The Layers panel and Freestyle-related panels in the Render tab of the Properties window were moved to the newly created Render Layers tab. The idea is to separate per render layer rendering options into a distinct Properties window tab, and use the existing Render tab to accommodate per scene rendering options. * The new Freestyle panel was added in the Render tab. The panel header contains a toggle button for globally enabling Freestyle, with the aim of making Freestyle easier to find. Those Freestyle options in the Post Processing panel were also moved to the new panel. * GUI code was updated so that UI controls will be greyed out (instead of being hidden) when Freestyle is disabled. Additional UI changes were also made to reduce space consumption. * The list of line sets was moved from the Freestyle panel to the Freestyle: Line Sets panel. * Old ray-casting algorithms were removed from the UI. Now only two algorithms (culled and non-culled cumulative visibility detection algorithms) are available, and the selection is done by the new "Culling" toggle button within the edge detection options.
2012-10-28 16:09:51 +00:00
if __name__ == "__main__": # only for live edit.
PyAPI: remove bpy.utils.register_module() In preparation for it being removed, see: T47811
2017-03-18 20:03:24 +11:00
from bpy.utils import register_class
for cls in classes:
register_class(cls)
Reference in New Issue Copy Permalink