Ttanasart-pt
commented
1 year ago Hmm... TBH This is something I've been avoiding since the beginning of the project. My principle is to have all data visualized in the graph, instead of hidden away in some abstract variable.
However I see your point. And tunnel node has already been breaking that principle more or less anyway. I'll reconsider it.
Something that would greatly streamline procedural workflows is the ability to expose node inputs as top level parameters that can be used to conveniently drive node values. You can see some users creating sections in their graphs to accomplish this with tunnel nodes:
This is a clever approach, but causes clutter in the graph and different artists can easily place their input nodes in different places within different graphs. Having a standard area to view exposed parameters at will make things much more consistent and easy to use. Perhaps exposed parameters could be found in the project's meta data inspector?
Exposing an input could be accomplished with a menu dropdown on valid fields. This menu could allow fields to pull their values from already exposed parameters too. A quick mockup:
A good example of this kind of workflow is Substance Designer. While I don't think Pixel Composer would need anywhere near as much control over parameters, the core idea here is solid. Clearly marked fields for values driven by exposed parameters, with the ability to rename and edit parameters in a centralized inspector.
Exposed (X Amount) vs Unexposed (Y Amount) Fields
Substance Designer Input Parameters
I realize that this is a rather big overhaul of how node fields can be driven so I definitely do not think this is something that could be implemented quickly. A lot of details will need to be hashed out, like support for animating exposed parameters in the timeline. The improvements to procedural workflows that exposed parameters would bring are massive however, and something like this is worth thinking about!