Add imagearray node

[ld-kerley]

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.

[dbsmythe]

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 <imagearray> that weren’t all in the same colorspace?

[lgritz]

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.

[crydalch]

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 , or any other texture node. Or does that cause problems with the various shading languages/rendering targets?

[ld-kerley]

@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 by providing a UV value and an integer index, and then get back the color(?) value.

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.