Improvement ideas for using Driver Context Properties to access scene custom properties #105407
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Viewport & EEVEE
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Asset Browser Project
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Module
Viewport & EEVEE
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Severity
High
Severity
Low
Severity
Normal
Severity
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
5 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#105407
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?
The #105132 pull request introduces access to properties of the current scene and view layer via an implicit rather explicit reference.
The existing implementation is perfectly fine for built-in properties, but I have some additional ideas aimed at making it easier and more convenient to allow scene-global custom settings via custom properties.
Basically, since the properties have to be added by the user, it would be convenient to support the case when it doesn't exist. It also may be nice to allow setting overrides at several different levels of abstraction.
Thus:
Allow an optional default value that would be returned by the variable if the referenced property doesn't exist, instead of failing with an error.
Allow fallback from Layer to Scene, and then World: one World can be used by multiple Scenes, which can have multiple Layers.
Since this all only makes sense for custom properties, maybe it can be a new mode specifically aimed at them, e.g. some kind of "Layer/Scene/World Custom Property", which has options for the custom property name (without the
["..."]
quoting), channel index (for vectors), and default value.These are things missing for the new driver things to fully cover the features of the View Layer mode of the Attribute material node.
@dr.sybren @Sergey created a design task for discussion
Can you please explain what is the practical problem the proposal is aimed to solve?
For rendering a dependency graph is needed. If the camera reference is not changed, the actual active camera might not even be in the dependency graph then.
I am not aware of reported issue about it, but this is something to investigate even outside of the driver variables, since it could be causing actual bugs with regular renders.
It is not immediately clear to me how this is useful for animators, or which practial problem this is solving.
In my experience if a property is not found animators want the property to be created instead, so that they can actually do something useful with it.
While this might sound closer to how variable scopes work in programming languages, I am not sure at all this is something riggers or animators want. They typically want a single place where properties can be found.
If there is such fall-backs implemented, it will become a nightmare for riggers, animators, and shot builders to figure out why shot does not behave the way it is supposed to.
What does that mean?
I feel that this is easily checked. Why leave that as an excersise for the reader?
I agree with Sergey here. Also this seems like a completely different thing than checking whether the 'active camera' access is properly handling VSE overrides.
I think it's obvious? Normal drivers refer to some specific datablock, so if you link the object you have to override the reference. This feature picks the target (scene or layer) from the context, so no overriding is necessary.
Why should it be related? It says "ideas" (plural) at the top. 😛
First, I wonder how this whole feature is useful for animators specifically, in the first place. 😉
Access to the current scene or view layer info seems like a scene level shading, rigging, layout and compositing feature.
Some uses I can think about is things like automatically adjusting level of detail or particle density based on the distance to camera in geonodes, supporting special modes in materials to use in additional render layers for compositing effects, and scene-global settings for things like NPR shading.
Basically, things that are global to the scene, and would require overriding every single object (i.e. making simple linking useless), without context-dependent drivers.
So, distance to camera is basically already covered, because the camera is a built-in object, you access builtin properties, and there always is a camera if you are rendering something.
Now, for special material modes you want defaults, because otherwise you would have to define the switch property in every other layer, only to set it to "off".
Finally, NPR shading. The way I understand it, since normal Blender lighting is completely dedicated to photorealistic approach, for NPR it is inevitably relegated to a dumb incident angle, occlusion and shadow query, while all actual lighting is done manually in materials, or even compositing. Sometimes the RGB channels of blender lights are used for ad-hoc light groups. This means that you need to replace lights with a ton of custom scene-global settings storing the same data.
Given this situation, first, I think it would be annoying if a prop completely stopped working unless all of the properties it needs were defined. In my opinion, defaults would be convenient.
Second, the user may want to change these properties between view layer to e.g. have different lighting settings for the background and characters. But maybe they don't want it. Therefore it would be useful to have a fallback chain, thus allowing the settings to be placed in either location.
Finally, if you put the properties in the scene, they cannot be linked from a file unlike a lighting setup done with lamps. You can only copy them to the scene, and that's it. However, there happens to exist a World datablock, which doesn't seem to have any real purpose other than, interestingly, containing the world background material. A world can be shared by many scenes. Thus in some circumstances it may make a lot of sense to place settings in the world datablock.
These considerations are the reason for suggesting a mode for accessing custom properties with a "Layer -> Scene -> World -> default" fallback chain.
I think maybe @icappiello would have an insight re NPR needs. Also, pinging @Mets as the resident rigger. 🙂
As said before: if someone (with a brain and some knowledge of the discussed topic) has to ask what something means, then it's safe to assume it's not obvious.
i dob't think i get the full picture if this task. For sure NPR is a technique that requires edgy workflows and hack atm in 3D packages.
VSE/GP/LINEART interaction may probably benefit from this. but i don't think i undertand completely what this proposal issue could be.
@angavrilov do you think this can be solved by your design?
#100596
This is about tools to make rigging those hacks easier, especially in the context of linking.
Basically, TLDR:
Originally drivers only supported referencing specific datablocks, meaning that if you used drivers in your materials to access those hacky lighting related properties in Scene or some other object, you couldn't link the materials without overrides.
Recently Sergey added ability for drivers to reference the active Scene or View Layer implicitly from context (i.e. a driver variable that targets Active Scene, whatever it is, instead of Scene.001 etc). Thus a material accessing a Scene property using this new context method can be linked as is. However, the target property must exist, or the driver would have an error. It is also necessary to decide whether the property will be in Scene, or View Layer beforehand.
I'm proposing a mode for custom properties that would support a default value if the property is not found, and also try looking up the property in Layer, Scene and then World in sequence.
A situation I envision when proposing:
Possible solutions:
With already committed code, the property can be placed in the View Layer, or Scene, or World; the decision is fixed in the material. The property must exist, or the driver in the material will be broken.
With suggested enhancements, the property can be placed in any of the locations, even allowing to set the color for the whole scene, and then override it for a specific view layer. It is also possible to omit the property, in which case a default value will be used.
The question for you is whether this situation analysis is relevant from your NPR experience.
Note that allowing defaults and the Layer->Scene->World lookup chain are in essence separate features that need evaluating separately.
npr shading would for sure benefit that!
Atm the only valuable workfolw we have found is putting a lot of properties on a bone of the rig that drive all the variables in the shader node. That's really hacky (and prone to errors since the inputs in the group nodes are sorted in list positions and not by explicit name) and not that convenient.
The proposed possible solutions seems quite convenient to me at a first look, but i can't tell if this is the best option. Would definitely like to test this Scene level properties workflow to give more detailed feedback.
I believe what @dr.sybren is asking is to also raise the general limitation to see if there could be a more general low level approach to a more general and widespread limitation (please correct me if i am wrong!)
I imagine that also has its place - you probably have settings that you want to be able to change per character, but also some that should be uniform throughout the scene for consistency. There are also background objects, which probably don't need individual settings and should all share one set of values, so it would be convenient to put them in the scene. So this is about making scene-global (or view layer global) settings feasible and convenient to use.
These new drivers also allow stuff like making a Lamp object also read a light location custom property from the scene, so your material can both use incoming light info from Blender to account for shadows, and do some direct computation with that light location.
that makes sense
Because a design task should be only about one thing. This is not a discussion forum.
Closing due to inactivity, and because it discusses too many things at once to be a clear design task.
You know, how is it ok to close this for 'inactivity', yet somehow it is fine to not review any patches for weeks and months. The main reason there is no activity is that I don't want to grow the stack of unreviewed patches even more.
Improvement ideas for Driver Context Propertiesto Improvement ideas for using Driver Context Properties to access scene custom propertiesWeeks ago I asked to focus this task on a single topic, and nothing happened with that.
If you want to have things accepted, then it's not a good idea to snap back with an "it's obvious" when someone asks for clarification.
So far this design task doesn't seem to solve a concrete need, but rather just adds a technical feature for which a concrete use still has to be found.
@icappiello So, I made a simple demo with a crude NPR cartoon shader that uses scene properties for lighting control.
It basically demonstrates:
Using a scene property to specify the position of the light, used both directly in the material for a raw shading computation, and to position a light object for cast shadow.
Using a scene or view layer property to specify the color of the light.
Using the World viewport color from the material for the unlit part of objects.
Using a scene or view layer property to specify crosshatching density.
The file uses two view layers for 'background' and 'foreground' objects, with an override for the light color and hatching density in the FG layer.
To remind: the question being discussed is whether it is useful to be able to:
The light color and hatching density are accessed by the material via the Attribute node, which implements the Layer -> Scene -> World fallback sequence when searching for the property, and signals whether it was found to the material via the Alpha output (if the property is not found there is no error, the node simply returns zero from all output sockets). Thus, it is possible to specify the color in the Scene or even World, and then override it for certain layers. The material also provides a fallback to a default value through an extra Mix node.
In comparison, the light position uses drivers, which currently supports neither. Thus it cannot be overriden for some layer, and must always be defined in the scene or the drivers would break.
Edit: This file obviously requires the 3.6 Alpha nightly build to run.
Edit 2: apparently there are some technical problems with the file on mac, so added a correct F12 render result too.
I totally agree that drivers need to be made more intuitive to use by having a fallback system of default values. A while back I was trying to use custom properties and drivers to set up material node channels before realizing it would've taken so many clicks and going back and forth that it would be faster to work without creating custom properties. There are many different possible applications for this feature. It would be difficult to list them all, but practically any workflow that could benefit from using custom properties would probably benefit a lot from having a more intuitive default set up. I'm sorry I can't provide more specifics, it's a bit fuzzy now. But the gist of it ( at least in my situation ) was that I wanted to use custom properties to set up quick controls and there were many things that just should have been set differently by default.
This is something that pos-up every now and then by riggers, so it is something that is potentially will become very useful.
I am very sceptical about it. Such things always come with a complication of troubleshooting by artists. It is also not clear what is the proper fall-back strategy for the set/background scenes/viewlayers is.
I would suggest focusing on the dynamic overrides, help with finishing their design and see if the use-case you shown is achievable with it (to me it really does sound like something that belongs to the dynamic overrides).
So you would support it as an option available for all properties? Or at least context and simple property?
What do you mean?
Do you mean a method where you could place the property in World, and then use overrides to change it per scene or layer?
Also while working on the example file, I had another idea: what about adding a "Copy As New Context Driver" context menu button for properties belonging to datablocks accessible via the context properties (scene, world, camera)?
I think the default value should be there for all RNA path properties (which includes the Context properties, and the "old" regular properties).
In the Scene properties there is "Background Scene": https://docs.blender.org/manual/en/latest/scene_layout/scene/properties.html
In the simple case yes, override per view layer.
The initial idea was also to support variants on per-collection basis, so that you can make the same object appear with different materials in different collections, for example.
The design and project plan has not been finalized yet.
It does sound interesting, but i am not sure how we can in a generic manner detect if something can be reached from the context.
I wonder how does that work already for the Active Scene drivers?
All I'm proposing at the moment is an automatic fallback search of Active View Layer, Active Scene, and Active Scene ->
world
, matching what the View Layer Attribute nodes do. It could be another option in the list, like "Active Layer, Scene or World". Object and Instancer attributes already did complex fallback chains, so including fallback seemed to fit with the concept there.I'm not sure what 'same object' means here.
I wonder if overrides could support wildcard datablock reference replacements, like "replace all uses of Material1 with Material2 in this view layer". The view layers have a feature to replace all materials, but that seems to crude to me to be useful, and providing part of the motivation for access to view layer properties in materials to work around by building in switches into the materials themselves.
I think even a hard-coded list of datablock types (Scene, World, Camera) would be better than none. The operator itself could then check if the specific object is currently reachable through context in poll or via failing with an error. Copy As New Driver is so convenient that when making the test I was basically using it and then manually editing the created drivers.
It is always using the scene for which the dependency graph is built for. Effectively, it is a safe (from relations perspective) replacement for
depsgraph.scene.foo
expression.It means, well, same object. Like,
OBMug
coming fromprops/mug.blend
. With the overrides it should be possible to instance it in few places, but give different material.Exact workflow/UX is not well defined yet.
Maybe we should also move this discussion to devtalk, it is a better suited place.
@Sergey I've just had a new idea: I wonder if it is possible to expose the fact whether the lookup succeeded or the default was used to the driver expression in some nice way?
Basically, that would allow one to implement any fallback sequence in the driver itself by doing
choice1 if (choice1 found?) else choice2 if (choice2 found?) else choice3
etc. Even with just defaults you can approximate that by using some 'impossible' default value and doingchoice1 if choice1 != -100000 else ...
, but maybe it can be done cleaner? Or some way to set really impossible default values like infinity or nan in the UI field?..You can visualize this in the drivers UI, similar to the invalid drivers.
I would not use this information for the decision making.
Um, do you even remember what this is all about?
One of my proposals here is to add a mode that would try looking up the path in View Layer, Scene and then World, to match how the View Layer type Attribute node works. Access to the lookup failure status would allow implementing that in the driver expression without a separate feature.
Any UI visualization is utterly beside the point.
Yes, I remember. The default value is one of the two points where to my knowledge it is aligned with what I know could become very useful in the production.
The part of the fallbacks is still fussy to me. It would help a lot if it becomes a real design proposal. You'd need to take initiative with doing so, as we have very limited time outside of the pre-agreed targets to help out finalizing proposals.
So, I submitted a pull request implementing defaults for driver variables.
I also updated my example file above (attached) to use the defaults to emulate the behavior of the attribute nodes used to access custom properties with fallbacks. However, the trick necessarily exploits invalid values for the specific attribute being accessed as markers of failed lookup, which is kinda messy.
One thing I came to wonder - is it really fine not to have a Camera Transform driver variable type (basically Transform Channel locked to active camera)?
The discussion about this and documentation seems to suggest you can use
camera.location
, but that is misleading and bad, because that is the keyed location, not the final position after constraints. True position has to be accessed ascamera.matrix_world[3][0/1/2]
, which is highly technical and not suggested anywhere. Getting the true camera orientation would be even more difficult.Edit: at the very least I think the proper usage of
matrix_world
should be documented as a set of recipes for non-mathematical users: 104513.