Are static const arrays in materials the best I can for a collection of static data?

I now have several instances where I need to use different data depending on the index which I one way or another encode into my mesh/buffers/etc…
so quite often I end up doing something like

static const float3 colors[3] = {
  float3(0.0, 0.0, 0.0), 
  float3(1.0, 0.936, 0.0),
  float3(1.0, 0.016, 0.0)
};
return colors[index];

in a custom node and passing an index to it.

Is there a better way of doing this? This proves to work fine so far but I’m pretty much building a large chunk of my graphics pipeline around it.
I’m new to HLSL and Graphics Programming in general.
Am I better off making a 1D texture and sampling it instead?

1D texture? Do you mean a 3vector for color? Why not use both as necessary or practical?

The issue with encoding may be memory or processing capacity if they’re large enough and not opimized somehow for Unreal developing. There’s also converting a texture or vector color / attribute into a parameter, which then you would make a material instance of the master material and modify those parameters without having to get into the material editor every time.

A 1D texture is simply a texture that’s 1 pixel in height and N pixels in width, meaning you would sample it using a single index and not 2 like you would do with a 2D texture (U and V).

I’m not sure what I was trying to say is clear.

There’s potentially dozens of float3 values that I’m differentiating between depending on an index.

There’s no way to expose an array of float3 values except sampling a prameter collection by index, which I can’t do more than once within a single shader + I don’t need the dynamic part of it so I suspect const arrays would be more performant, but I’m not entirely sure.
If there’s a way to sample more than one parameter collection per material that would be useful.
The way I did that is

return MaterialCollection0.Vectors[i];

where i is an input to the custom expression and additionally you pass any parameter from the collection so the custom expression node understands which MaterialCollection0 you’re referring to.
This works, but unfortunately as soon as you add another one of these it breaks, and I need several per material.