Is it unwise to add plugs to nodes like StandardOptions? #4186
-
I'd like to add some plugs to StandardOptions and Camera nodes to keep related settings in the same place, but I'm not sure that's a good idea. Specifically, I'm implementing VRay-specific motion-blur settings and ideally I'd like those to live next to the existing StandardOptions motion blur plugs so they are as obvious as possible. I've tested it out and find that I can, but not sure if I should. So far the main thing I'm missing is the ability to include my new settings in the I saw that the recent release that included advanced camera settings for Arnold has them added to CameraTweaks and not like my scheme, which is perhaps related? I'm adding a Python script in Any advice is appreciated!
|
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
I'm not sure I'd go so far as to say it was unwise - as you've found, it does work. But it definitely does go against the grain. Gaffer is intended to be renderer agnostic, and to be able to generate scenes that can target multiple renderers at once. While it's possible to put all the settings for all the supported renderers on one node, that would lead to a lot of clutter, and a lot of irrelevant settings for users of a particular renderer. So instead we've opted for clarity, separating things into StandardOptions that everything should support, and then ArnoldOptions and DelightOptions etc to add renderer specific settings. When you consider only one renderer at a time, it's true that this could be less user-friendly than having everything in one place. The argument I've used is that Gaffer provides lots of possibilities (boxes, references, extension nodes) for aggregating this more granular functionality into something specific to a particular pipeline where the renderer is known. It's fairly common to want to build higher level abstractions on top of some of the settings, drive some parameters from asset databases, hide others entirely, and present it all as a YourStudioOptions node. So I'm pretty comfortable with Gaffer providing clarity and modularity rather than absolute friendliness, and leaving it to others to build their specific workflow. So on balance I think I'd recommend against injecting stuff into StandardOptions. Perhaps a compromise is to derive VRayOptions from StandardOptions, so that it still provides everything in one place, but without cluttering StandardOptions itself? |
Beta Was this translation helpful? Give feedback.
I'm not sure I'd go so far as to say it was unwise - as you've found, it does work. But it definitely does go against the grain. Gaffer is intended to be renderer agnostic, and to be able to generate scenes that can target multiple renderers at once. While it's possible to put all the settings for all the supported renderers on one node, that would lead to a lot of clutter, and a lot of irrelevant settings for users of a particular renderer. So instead we've opted for clarity, separating things into StandardOptions that everything should support, and then ArnoldOptions and DelightOptions etc to add renderer specific settings.
When you consider only one renderer at a time, it's true that t…