color array inputs and evaluation

[bart]

For subtraction, I'd like to ask you how you envision using it in a shader graph. Please give me a practical example. Then, from that, it leads to how you'd implement it.

In a shader list, a positive result could have been passed in through the result color, as opposed to all 0s, when it is not a shader list.

I'd label my non-subtract input base_color, instead of color1, or similar. But if it is the first item in the array, rather than a separate input, then you'd initialize to the first element and start the loop from 1 instead of 0, ie

  color = mi_eval_color(params->colors + i_colors)
  result->r +=  color->r;
  result->g +=  color->g;
  result->b +=  color->b;

  for (i = 1; i < n_colors; i++) {
    color = mi_eval_color(params->colors + i_colors + i);

    result->r -=  color->r;
    result->g -=  color->g;
    result->b -=  color->b;
  }

Also, you could adjust the naming in the Phenomena.

[bart]

As for the power function, I don't think I can imagine where having an array of colors beyond two would be clear in a shader graph.

[Ian_]

Thanks so much bart, for walking me through this, I didn't expect arrays to be that tricky, since I mainly knew how to write metaSL decently, and some hlsl. As far as a use for a subtractive array, I really can't think of a specific use other than a layered shader that might need to subtract a bunch of textures that are inverted, so you would use subtract instead of multiply. There's probably someone that would eventually need a phenomenon with 50 color or float inputs. Really, I think it would be nice to have a huge library of shaders that has every node or shader that would need, even if you wouldn't use every single thing, its just nice to have. I would like to eventually have such a library for MR and in metaSL.

[Ian_]

Thanks again bart, works like a charm! I think I probably will keep with the first item in the array, instead of using a separate input, for the base color, (which I did come to realize I could just use a separate input instead of trying to figure out how to use the first item), and I'll just rename it in phenomenon to "Base Color" or "Base Float", as I would like to have math shaders with different data types..

BTW, one last question, is it better for memory and rendering performance, to have 3 dll's with one shader in each, or is it better to have one dll with 3 shaders, or option 3, if the 3 shaders are very similar, is it better to have the 3 shaders contained in one, where you could have a switch statement to change between the 3?

[bart]

No significant difference regarding memory and performance, however, I'd suggest one dll with respect to asset management and maintenance. From a software management perspective, you might want to keep the c files separate, but link them all together into the same dll, using the same mi declaration file.

As I mentioned earlier, make your code clear and simple. The more you combine, the more you may be making it harder for others (or even yourself after some time as passed) to understand quickly.

Even if you make a combination multi-purpose layer shader, I'd have separate Phenomena, so that it is very clear for look dev artists using it in shader graphs.

[bart]

BTW, I'd give this same advice whether you used C shaders or MetaSL. This is common production sense from a management perspective. It doesn't matter how fast or effective something is, if it is hard or unclear to use it correctly. People time trumps render time.