AcademySoftwareFoundation
Add imagearray node
As previously discussed, this PR adds a new <imagearray> node. It behaves very similarly to the <image> node but accepts an array of filenames, instead of a single file. The index integer input is used to select which filename from the array of filenames is used.
This PR adds shader gen and render support for both MSL and GLSL. Both MSL and GLSL use texture arrays to implement the <imagearray> node.
I attempted an OSL implementation, but the texture filename in OSL uses a struct (textureresource).
struct textureresource { string filename; string colorspace; }
In order to support <imagearray> in OSL we would need an array of this texture resource struct. Unfortunately arrays of structs are not supported as OSL parameters.
I believe we should be able to refactor how filenames and colorspaces are managed in OSL, and thus allow <imagearray> to be supported in OSL, but I'm opting to leave this to a follow up PR, as its likely to be a more invasive change.
For OSL, would it make sense to have the filename within the textureresource struct be the array, and keep colorspace as a regular non-array string? How often would you have an array of images feeding into an
Unfortunately arrays of structs are not supported as OSL parameters.
Really? That sounds like maybe a bug or just something unimplemented because the case didn't come up.
This is a neat idea! One question/concern I have, would this require having array-flavors of every current/future texture-map related shader (triplanar, hextiled)?
What if there was a shader node, that takes an array of filepaths, and has an integer input to select one of the filepath outputs? This could then be connected to
@lgritz - I posted this issue to the OSL project, as a response to your comment above. If there's a good reason things are the way they are feel free to close.
@crydalch - This is not an array of filenames, but instead a MaterialX realization of the hardware shading concept of texture arrays, where a number of images are bound to a single texture unit and then selected by index. So you read the texel from an
I guess we could provide a nodegraph fallback implementation that works the way you describe - but for the hardware languages I think we would likely want to directly use the hardware support. This nodegraph idea might work around the current complexities in the OSL implementation.
I don't think this proposal necessarily infers array versions of other nodes, at least not yet, and certainly not necessarily. Though I can see a world where one might want to add an image-array version of something like hextile for instance, and then randomly selecting an index to use to increase variation in the generated texture.
@ld-kerley Taking a step back from this specific implementation, it seems worthwhile to consider the alternative, where the new index input is simply added to the image node, and all of the existing functionality of image nodes (e.g. filter modes, address modes, default color behavior, texture coordinate overrides) would automatically extend to image arrays as well.
I don't have a definitive answer as to which of these two approaches is best, but adding an index input is certainly simpler and more straightforward to extend to tiledimage and other image-like nodes in the future. In addition, it would provide artists with a straightforward mechanism to maintain array support in custom graphs that leverage image under the hood.
