Author Topic: Is there any way to use array in substance designer?  (Read 845 times)

As title says, sometimes I like to use array in substance function.
Why SD does not support array?  :(

Multiple reasons (list not exhaustive and in no particular order) :
  • because there is currently no way to iterate in functions (for similar reasons, cf. the threads requesting "for" loops), which greatly reduces the usefulness of arrays
  • because it is not obvious what the user interface would be to make that convenient in the context of SD function graphs (how to visualize and/or edit the array content)
  • because it is a potential source of nasty bugs (out of boundaries access)
Last Edit: July 20, 2018, 02:28:15 pm

  • about iteration: there is a way to iterate through the fx-map node, this could be used to locate items into an array/list
  • UI: is this really a show-stopper? Come on!
  • out-of bounds: the function language is so controlled it would be easy to catch this

I would love to see the function capabilities improve and array/lists would be awesome. Also, I ideally would like to use a simple script language that would match the nodes functionalities, this would make function code much easier to write and read. I would also like to be able to have more user interaction with the 2D view. For example we can let the user position a control pin, but can we trigger an action when user clicks at a certain location?
Last Edit: February 27, 2019, 07:04:39 pm

Technically, arrays are supported. Just not very big ones. I use vector types as arrays in many of my functions. It allows us to return more than one value from a function, which is huge in some cases.

because it is not obvious what the user interface would be to make that convenient in the context of SD function graphs (how to visualize and/or edit the array content)
The UI you guys use to create exposed drop down boxes for int type is a great setup and would work perfectly for managing array data outside of graph functionality. Within graphs, just use an input connector as the array index to access each specific element. Example:

because it is a potential source of nasty bugs (out of boundaries access)
Every powerful feature will have this problem. But this is a feature you are not forcing us to use by adding it in. We only need to deal with arrays if we want to. If we don't like the risk vs reward, we can opt out by not using them.

As for boundaries access, it would be relatively easy to safeguard against this internally. For example, your array nodes will know exactly how large they are, internally, and can prevent out of bounds access and/or throw a warning when the graph tries to reach too far. This type of check should not hurt performance.

  • about iteration: there is a way to iterate through the fx-map node, this could be used to locate items into an array/list
Totally different context : the graph describing the FxMap node drawing process is not a function graph (for a reason).

  • UI: is this really a show-stopper? Come on!
Sometimes, yes, it can be a non-starter, because we have to consider the development cost vs users benefit ratio to prioritize what feature we implement. As said above, here it is just one of the arguments against it.

  • out-of bounds: the function language is so controlled it would be easy to catch this
Sorry to make an argument of authority here, but no, it would not be easy to catch it in a way that would be fast enough..

Quote
As for boundaries access, it would be relatively easy to safeguard against this internally. For example, your array nodes will know exactly how large they are, internally, and can prevent out of bounds access and/or throw a warning when the graph tries to reach too far. This type of check should not hurt performance.
Again, I'll have to ask you to trust me on this, but yes enforcing dynamic boundary checks would hurt performances badly, and in some contexts (GPU engines) it would not even be possible to catch gracefully/throw a warning.

Quote
Technically, arrays are supported. Just not very big ones.
Technically, even big arrays are supported : textures.



Last Edit: February 28, 2019, 03:07:06 pm

  • about iteration: there is a way to iterate through the fx-map node, this could be used to locate items into an array/list
Totally different context : the graph describing the FxMap node drawing process is not a function graph (for a reason).

Yet, array/lists would be useful when working with fx-map since we have iterations there. Here is a practical example: I have a processing requiring a number of controls points presented as exposed input parameters. First, I would like the user to be able to define the number of control points, but I can't without a dynamic array of input parameters, so this number has to be fixed. Second, the code within functions I am using inside the fx-map is quite repetitive, because I cannot iterate through control point inputs. I am trying to factorize as much as possible into functions but this is still not great (especially when functions have no input parameters). If I could iterate over control points, I would have one big loop and that's all, code would be much cleaner.

About the implementation I reckon we don't have all the keys, we just don't know how your software is working internally. But there should be a way, there is always a way... ;)
Last Edit: February 28, 2019, 11:35:32 pm

Quote
As for boundaries access, it would be relatively easy to safeguard against this internally. For example, your array nodes will know exactly how large they are, internally, and can prevent out of bounds access and/or throw a warning when the graph tries to reach too far. This type of check should not hurt performance.
Again, I'll have to ask you to trust me on this, but yes enforcing dynamic boundary checks would hurt performances badly, and in some contexts (GPU engines) it would not even be possible to catch gracefully/throw a warning.
I trust you, but have to assume you're using a strange internal language. I am far from an expert when it comes to GPU limitations, but I thought min(x,y) was supported? "return min( user_index, array_size - 1 );

But its silly to argue about weather the safeguard to a feature is fast enough when the feature won't exist unless it is. I would rather have a slow horse than walk.

Quote
Quote
Technically, arrays are supported. Just not very big ones.
Technically, even big arrays are supported : textures.
True. But we can't maintain this type of array in the environment. For example, I can't send or return an image from a function node.

Quote
True. But we can't maintain this type of array in the environment. For example, I can't send or return an image from a function node.
You can chain pixel processor nodes.





I just meant it doesn't have the same convenience or usability as a variable. It doesn't take the place of one.

To be honest, I'm not really in a hurry for arrays in Substance. At least not until we have looping to go with it. Without looping, I can do pretty much the same things without arrays that I could with them. It gets a little complicated sometimes (edit: without looping, not without arrays), and you end up writing five times as many function nodes, but its working for now.
Last Edit: March 01, 2019, 10:42:43 pm