Author Topic: Is there any way to make reading function graphs easier (like a script)?  (Read 463 times)

Hello, I'm relatively new to Substance Designer. In general I like the workflow, but I'm not really a fan of "function graphs". I'm trying to understand the inner working of complex nodes like Tile Random. Looking at the graphs seems to be quite tedious as there is no defined structure, no variable names, no encapsulation of calculations, trivial calculations take half the screen and finding things you saw before is unnecessarily time consuming (again, due to the overall lack of variable names and structure).

Graphs make a lot of sense for operations on images (as you want to see the intermediate results), but I don't see their value when writing functions which operate on scalars or vectors.

Is there any way of obtaining the "script-like" form of a graph function? if not, are there any plans to make writing and reading function graphs less tedious (like Unreal does by offering a script alternative to Blueprints)?

Thanks.
Last Edit: January 16, 2019, 10:20:06 pm

Hi,

Quote
Graphs make a lot of sense for operations on images (as you want to see the intermediate results), but I don't see their value when writing functions which operate on scalars or vectors.

This is your opinion, it may not be shared by all the users. Actually, some may think the opposite.

That being said we are regularly speaking about a "text function node" but it never became a high priority as it requires quite a lot of work. So for now you'll have to stick with function graph.

What you could potentially do, is to use the python API to generate the function graph.
Product Manager - Allegorithmic

Thanks for answering.

What experience shows is that node based programming languages are rare (for good reason), those which survive either offer a real scripting language or are simply relics of the past (like LabVIEW).

I have very little doubt that a test (have you done any? anecdotal opinions are not as important as results and productivity) would show consistently that those who use an actual scripting language end up being far more productive and having a much easier time reading other people's code and maintaining their own.

For trivial cases the distinction becomes irrelevant, but you market this product as a serious professional tool for studios. Having spaghetti code forced upon you is a non-negligible flaw. And I predict it will only get worse as people start trying to make more complex things with Substance Designer, while old code becomes an unreadable mess.

What you could potentially do, is to use the python API to generate the function graph.

Yeah, but as I said, the biggest problem is reading other people's code, in this case the code behind some of the complex built-in nodes. Basically, I would need the reverse operation: graphs to scripts.
Last Edit: January 17, 2019, 07:01:34 pm

Thanks for answering.

What experience shows is that node based programming languages are rare (for good reason), those which survive either offer a real scripting language or are simply relics of the past (like LabVIEW).

I have very little doubt that a test (have you done any? anecdotal opinions are not as important as results and productivity) would show consistently that those who use an actual scripting language end up being far more productive and having a much easier time reading other people's code and maintaining their own.

And you would be wrong.

18 years of CG industry here (VFX for film, tv and games), 25 in SWE.

DAGs are the way of life: Modo, Lightwave, Softimage, SD, NUKE, and even Maya's texture graphs.

Every single one.

You might not like it, but it is not "anecdotal". It is how this industries toolset(s) have and continue to evolve.

Thanks for answering.

What experience shows is that node based programming languages are rare (for good reason), those which survive either offer a real scripting language or are simply relics of the past (like LabVIEW).

I have very little doubt that a test (have you done any? anecdotal opinions are not as important as results and productivity) would show consistently that those who use an actual scripting language end up being far more productive and having a much easier time reading other people's code and maintaining their own.

And you would be wrong.

18 years of CG industry here (VFX for film, tv and games), 25 in SWE.

DAGs are the way of life: Modo, Lightwave, Softimage, SD, NUKE, and even Maya's texture graphs.

Every single one.

You might not like it, but it is not "anecdotal". It is how this industries toolset(s) have and continue to evolve.

It seems you have not read my posts. First, everything that you mention is hardly programming, as I make clear by praising Substance graph for building materials but criticize it when used for actual functions (the so called "function graphs") where a script is infinitely superior, as any programmer could tell you. As I said, I have no doubt that a test, even among Allegorithmic employees, would prove me right.

Have you ever tried to write a program as opposed to connect input and outputs like the graphs in those programs? it's not the same.

The main difference being that in the graphs you are used to you are not really building functions from scratch but connecting massive nodes (with tons of properties) wich each other, which do the complex, low-level work for you. Substance function graphs operate at a much lower level, where you arbitrarily define variables, operate on scalars and vectors with custom user-defined operations, where there is a very diverse set of tasks which vary from problem to problem that would benefit a lot from being encapsulated, and where tiny common expressions like "1*8 + 5*7" take a lot of space. It's considerably closer to what programming is, even if very bare-bones and still quite far from being the same.

Try to write a non-trivial pixel processor or fx-map function with graphs and then do it with a script. You will save a lot of time doing the latter, while making it far easier for other people to understand what you wrote.

As an example: variable names and function names, when properly defined, are very, very good at making people understand complex calculations. It's the reason why programmers emphasize how important it is to name things properly. With graphs there is no such thing to begin with (at least without making the graph even more gigantic and the process of writing it way slower).

Another example, think of how easy it would be to reuse code with an actual language as opposed to graphs.

One question for Allegorithmic employees in charge of writing those, how often have they used pseudo-code to delineate the spaghetti they needed to write? or are you using an internal tool? if Substance supported a scripting language (probably a custom one as the supported features wouldn't warrant a full fledged scripting language), they would be more productive.
Last Edit: January 19, 2019, 05:24:41 pm

You are not alone Uqbar. I too find substance functions to be an absolute nightmare to work with. I too would prefer a scripting interface to at least the functions, preferably the whole of designer. Making complex materials gets to be an absolute mess of spaghetti, which impacts workflow efficiency, readability, maintenance, re-usability, and team work. Unfortunately it does not look like Substance was built with a 'shading language' in mind, and there doesn't seem to be any intention to improve the usability of functions in the near term. Depending on your needs, you should look into Renderman SE expressions and of course c++ shaders.

+1

New user here, also very surprised that this doesn't exist in Designer already. A simple expression node would be hugely beneficial. All the node-based compositors I can think of include this feature (Fusion, Nuke, Houdini).

Yeah, but as I said, the biggest problem is reading other people's code, in this case the code behind some of the complex built-in nodes. Basically, I would need the reverse operation: graphs to scripts.

+1