External Render Engines and storing 3D View dependent data #69579
Labels
No Label
Interest
Animation & Rigging
Interest
Blender Cloud
Interest
Collada
Interest
Core
Interest
Documentation
Interest
Eevee & Viewport
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
Import and Export
Interest
Modeling
Interest
Modifiers
Interest
Nodes & Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds, Tests & Devices
Interest
Python API
Interest
Rendering & Cycles
Interest
Sculpt, Paint & Texture
Interest
Translations
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Meta
Good First Issue
Meta
Papercut
Module
Add-ons (BF-Blender)
Module
Add-ons (Community)
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender-addons#69579
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
With the new design of the preview shading modes blender/blender#68312 (LookDev & Eevee Preview) external render-engines can have viewport specific settings. For example when implementing blender/blender#69476 (Eevee: Option to Display Render Passes in the 3D Viewport) a user might want to work in a configuration where multiple render layers are shown at the same time.
Displaying Diffuse Color pass and Diffuse Direct pass in different viewport.
Currently the implementation is very limited as Blender has a fixed list of common render passes and stores the selection inside
View3DShading
. The external render engine can act upon this.There are several ways I came up with to make this more flexible. They will be explained here. The goal of this design is to find a solution for this kind of features.
Personally I would go for the Custom Properties as it gives more freedom to the add-on developers, but just want to be sure that there are no other options or ideas that you have in mind, that I am not aware of. Or that this proposal is a road we don't want to take due to reasons
Register Viewport Passes
When the render engine is registered it will register a list of viewport passes.
The issue with this is that it is really a point solution for this specific problem; It reduces the potential flexibility that render-engines might want to have.
Space level Custom Properties
Another solution would be to allow Custom properties on space level. This way render engines (but also other add-ons) can extend the viewport data model and we don't need to keep track of all the different options inside blender RNA. We could limit it to SpaceView3D only when it only has potential in the 3d viewport.
Added subscribers: @Jeroen-Bakker, @brecht, @mont29, @ideasman42
Added subscriber: @povmaniac
I think this should be custom properties for
View3DShading
, usingRNA_def_struct_idprops_func
.I would not add a generic viewport passes system, just leave it to the renderer to define this themselves.
Added subscriber: @frameshift
Changed status from 'Open' to: 'Resolved'
Solved in blender/blender@68d1f09.