blender/blender
162
514
Fork 780
Code Issues 6.8k Pull Requests 930 Projects 19 Wiki Activity

Improvement ideas for using Driver Context Properties to access scene custom properties #105407

New Issue
Open
opened 2023-03-03 17:01:52 +01:00 by Alexander Gavrilov · 30 comments
Alexander Gavrilov commented 2023-03-03 17:01:52 +01:00
Member
Copy Link

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.

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.
🚀 1
Alexander Gavrilov added the
Type
Design
 label 2023-03-03 17:01:52 +01:00
Alexander Gavrilov added this to the Animation & Rigging project 2023-03-03 17:02:12 +01:00
Alexander Gavrilov added the
Interest
Animation & Rigging
 label 2023-03-03 17:02:21 +01:00
Alexander Gavrilov commented 2023-03-03 17:05:04 +01:00
Author
Member
Copy Link

@dr.sybren @Sergey created a design task for discussion

@dr.sybren @Sergey created a design task for discussion
Sergey Sharybin commented 2023-03-07 09:34:13 +01:00
Owner
Copy Link

Can you please explain what is the practical problem the proposal is aimed to solve?

VSE allows overriding the camera. I'm not sure how it works, but if it doesn't change the reference in the Scene, then accessing the true active camera may require adding another mode.

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.

Allow an optional default value that would be returned by the variable if the referenced property doesn't exist

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.

Allow fallback from Layer to Scene, and then World: one World can be used by multiple Scenes, which can have multiple Layers.

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.

Can you please explain what is the practical problem the proposal is aimed to solve? > VSE allows overriding the camera. I'm not sure how it works, but if it doesn't change the reference in the Scene, then accessing the true active camera may require adding another mode. 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. > Allow an optional default value that would be returned by the variable if the referenced property doesn't exist 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. > Allow fallback from Layer to Scene, and then World: one World can be used by multiple Scenes, which can have multiple Layers. 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.
Sybren A. Stüvel commented 2023-03-07 14:23:33 +01:00
Member
Copy Link

via an implicit rather explicit reference.

What does that mean?

VSE allows overriding the camera. I'm not sure how it works, but if it doesn't change the reference in the Scene, then accessing the true active camera may require adding another mode.

I feel that this is easily checked. Why leave that as an excersise for the reader?

Global options (Custom Properties)

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.

> via an implicit rather explicit reference. What does that mean? > VSE allows overriding the camera. I'm not sure how it works, but if it doesn't change the reference in the Scene, then accessing the true active camera may require adding another mode. I feel that this is easily checked. Why leave that as an excersise for the reader? > Global options (Custom Properties) 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.
Alexander Gavrilov commented 2023-03-07 14:43:11 +01:00
Author
Member
Copy Link

What does that mean?

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.

Also this seems like a completely different thing than checking whether the 'active camera' access is properly handling VSE overrides.

Why should it be related? It says "ideas" (plural) at the top. 😛

> What does that mean? 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. > Also this seems like a completely different thing than checking whether the 'active camera' access is properly handling VSE overrides. Why should it be related? It says "ideas" (plural) at the top. 😛
Alexander Gavrilov commented 2023-03-07 15:10:47 +01:00
Author
Member
Copy Link

It is not immediately clear to me how this is useful for animators, or which practial problem this is solving.

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.

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.

> It is not immediately clear to me how this is useful for animators, or which practial problem this is solving. > 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. 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.
Alexander Gavrilov added the
Interest
Compositing
 label 2023-03-07 15:58:07 +01:00
Alexander Gavrilov commented 2023-03-07 16:06:24 +01:00
Author
Member
Copy Link

I think maybe @icappiello would have an insight re NPR needs. Also, pinging @Mets as the resident rigger. 🙂

I think maybe @icappiello would have an insight re NPR needs. Also, pinging @Mets as the resident rigger. 🙂
Sybren A. Stüvel commented 2023-03-07 16:47:14 +01:00
Member
Copy Link

What does that mean?

I think it's obvious?

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.

> > What does that mean? > > I think it's obvious? 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.
Ivan Cappiello commented 2023-03-09 11:49:07 +01:00
Member
Copy Link

I think maybe @icappiello would have an insight re NPR needs. Also, pinging @Mets as the resident rigger. 🙂

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

> I think maybe @icappiello would have an insight re NPR needs. Also, pinging @Mets as the resident rigger. 🙂 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? https://projects.blender.org/blender/blender/issues/100596
Alexander Gavrilov commented 2023-03-09 12:14:37 +01:00
Author
Member
Copy Link

@icappiello i dob't think i get the full picture if this task.

This is about tools to make rigging those hacks easier, especially in the context of linking.

Basically, TLDR:

  1. 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.

  2. 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.

  3. 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:

  • A NPR material needs a scene-level light color parameter, because the native light color channels are used for light groups, or other reasons; or maybe light location to calculate incident angle from scratch.
  • In order to allow linking the material, the user decides to place the property outside the material itself, and use context drivers to access it.

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.

> @icappiello i dob't think i get the full picture if this task. This is about tools to make rigging those hacks easier, especially in the context of linking. Basically, TLDR: 1. 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. 2. 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. 3. 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: * A NPR material needs a scene-level light color parameter, because the native light color channels are used for light groups, or other reasons; or maybe light location to calculate incident angle from scratch. * In order to allow linking the material, the user decides to place the property outside the material itself, and use context drivers to access it. 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.
Ivan Cappiello commented 2023-03-09 12:44:37 +01:00
Member
Copy Link

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!)

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!)
Alexander Gavrilov commented 2023-03-09 12:59:16 +01:00
Author
Member
Copy Link

Atm the only valuable workfolw we have found is putting a lot of properties on a bone of the rig

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.

> Atm the only valuable workfolw we have found is putting a lot of properties on a bone of the rig 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.
Ivan Cappiello commented 2023-03-09 14:55:18 +01:00
Member
Copy Link

that makes sense

that makes sense
Sybren A. Stüvel commented 2023-03-14 11:13:21 +01:00
Member
Copy Link

Why should it be related? It says "ideas" (plural) at the top. 😛

Because a design task should be only about one thing. This is not a discussion forum.

> Why should it be related? It says "ideas" (plural) at the top. 😛 Because a design task should be only about one thing. This is not a discussion forum.
Sybren A. Stüvel commented 2023-03-30 12:37:48 +02:00
Member
Copy Link

Closing due to inactivity, and because it discusses too many things at once to be a clear design task.

Closing due to inactivity, and because it discusses too many things at once to be a clear design task.
Blender Bot added the
Status
Archived
 label 2023-03-30 12:37:50 +02:00
Sybren A. Stüvel removed this from the Animation & Rigging project 2023-03-30 12:37:56 +02:00
Blender Bot added
Status
Confirmed
 and removed
Status
Archived
 labels 2023-03-30 15:20:13 +02:00
Alexander Gavrilov commented 2023-03-30 15:22:56 +02:00
Author
Member
Copy Link

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.

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.
Alexander Gavrilov changed title from Improvement ideas for Driver Context Properties to Improvement ideas for using Driver Context Properties to access scene custom properties 2023-03-30 15:37:12 +02:00
Sybren A. Stüvel commented 2023-03-30 16:31:45 +02:00
Member
Copy Link

You know, how is it ok to close this for 'inactivity'

Weeks 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.

> You know, how is it ok to close this for 'inactivity' Weeks 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.
Alexander Gavrilov commented 2023-03-30 22:08:26 +02:00
Author
Member
Copy Link

@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:

  • Optionally override a property defined in the Scene or World at the View Layer level without having to commit to defining it separately for every View Layer.
  • Allow omitting the property entirely in a given scene without breaking the material or other system using it via a fallback to default.

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.

@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: - Optionally override a property defined in the Scene or World at the View Layer level without having to commit to defining it separately for every View Layer. - Allow omitting the property entirely in a given scene without breaking the material or other system using it via a fallback to default. 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.
test-npr-globals.blend
119 KiB
screenshot-npr-render.jpg
103 KiB
screenshot-npr-render.jpg
rim-pom commented 2023-03-30 22:59:24 +02:00
Copy Link

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.

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.
Sergey Sharybin commented 2023-04-05 16:47:24 +02:00
Owner
Copy Link

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.

This is something that pos-up every now and then by riggers, so it is something that is potentially will become very useful.

Allow fallback from Layer to Scene, and then World: one World can be used by multiple Scenes, which can have multiple Layers.

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).

> 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. This is something that pos-up every now and then by riggers, so it is something that is potentially will become very useful. > Allow fallback from Layer to Scene, and then World: one World can be used by multiple Scenes, which can have multiple Layers. 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).
Alexander Gavrilov commented 2023-04-06 13:13:26 +02:00
Author
Member
Copy Link

This is something that pos-up every now and then by riggers, so it is something that is potentially will become very useful.

So you would support it as an option available for all properties? Or at least context and simple property?

It is also not clear what is the proper fall-back strategy for the set/background scenes/viewlayers is.

What do you mean?

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).

Do you mean a method where you could place the property in World, and then use overrides to change it per scene or layer?

> This is something that pos-up every now and then by riggers, so it is something that is potentially will become very useful. So you would support it as an option available for all properties? Or at least context and simple property? > It is also not clear what is the proper fall-back strategy for the set/background scenes/viewlayers is. What do you mean? > 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). Do you mean a method where you could place the property in World, and then use overrides to change it per scene or layer?
Alexander Gavrilov commented 2023-04-06 13:18:27 +02:00
Author
Member
Copy Link

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)?

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)?
Sergey Sharybin commented 2023-04-06 14:03:01 +02:00
Owner
Copy Link

So you would support it as an option available for all properties? Or at least context and simple property?

I think the default value should be there for all RNA path properties (which includes the Context properties, and the "old" regular properties).

What do you mean?

In the Scene properties there is "Background Scene": https://docs.blender.org/manual/en/latest/scene_layout/scene/properties.html

Do you mean a method where you could place the property in World, and then use overrides to change it per scene or layer?

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.

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)

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.

> So you would support it as an option available for all properties? Or at least context and simple property? I think the default value should be there for all RNA path properties (which includes the Context properties, and the "old" regular properties). > What do you mean? In the Scene properties there is "Background Scene": https://docs.blender.org/manual/en/latest/scene_layout/scene/properties.html > Do you mean a method where you could place the property in World, and then use overrides to change it per scene or layer? 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. > 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) 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.
Alexander Gavrilov commented 2023-04-06 14:41:55 +02:00
Author
Member
Copy Link

In the Scene properties there is "Background Scene": https://docs.blender.org/manual/en/latest/scene_layout/scene/properties.html

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.

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.

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.

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 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.

> In the Scene properties there is "Background Scene": https://docs.blender.org/manual/en/latest/scene_layout/scene/properties.html 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. > 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. 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. > 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 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.
Sergey Sharybin commented 2023-04-24 09:51:06 +02:00
Owner
Copy Link

I wonder how does that work already for the Active Scene 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.

I'm not sure what 'same object' means here.

It means, well, same object. Like, OBMug coming from props/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.

> I wonder how does that work already for the Active Scene 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. > I'm not sure what 'same object' means here. It means, well, same object. Like, `OBMug` coming from `props/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.
Alexander Gavrilov commented 2023-05-15 12:32:39 +02:00
Author
Member
Copy Link

@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 doing choice1 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?..

@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 doing `choice1 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?..
Sergey Sharybin commented 2023-05-15 14:43:50 +02:00
Owner
Copy Link

You can visualize this in the drivers UI, similar to the invalid drivers.
I would not use this information for the decision making.

You can visualize this in the drivers UI, similar to the invalid drivers. I would not use this information for the decision making.
Alexander Gavrilov commented 2023-05-15 14:55:58 +02:00
Author
Member
Copy Link

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.

> 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.
Sergey Sharybin commented 2023-05-15 15:12:51 +02:00
Owner
Copy Link

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.

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.
Alexander Gavrilov commented 2023-07-16 14:30:09 +02:00
Author
Member
Copy Link

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.

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.
Screenshot_20230716_152353.png
73 KiB
test-npr-globals-def.blend
121 KiB
Screenshot_20230716_152353.png
Alexander Gavrilov commented 2023-07-16 19:44:16 +02:00
Author
Member
Copy Link

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 as camera.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.

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 as `camera.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](https://projects.blender.org/blender/blender-manual/pulls/104513).
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels   
Interest
Alembic

  
Interest
Animation & Rigging

  
Interest
Asset System
Asset datablocks, libraries, browser and shelf

  
Interest
Audio

  
Interest
Automated Testing

  
Interest
Blender Asset Bundle

  
Interest
BlendFile

  
Interest
Code Documentation
Code comments, Python/RNA API descriptions

  
Interest
Collada

  
Interest
Compatibility
Backward and forward 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
Wayland windowing on Unix

  
Interest
Workbench

  
Interest: X11

Xorg/X11 windowing

  
Legacy
Asset Browser Project

Archived

  
Legacy
Blender 2.8 Project

Archived

  
Legacy
Milestone 1: Basic, Local Asset Browser

Archived

  
Legacy
OpenGL Error

Archived

  
Meta
Good First Issue

  
Meta
Papercut

  
Meta
Retrospective

  
Meta
Security
Related to security, see policy: https://developer.blender.org/docs/handbook/bug_reports/vulnerability_reports/

  
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

Archived

  
Type
Report

Archived

  
Type
To Do

No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Code Documentation
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
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
5 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#105407
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?