I think you didn’t read my post properly because I mentioned that I already know about the scalar parameter but having vector2 and vector3 parameters along with enum will be more user-friendly.
I can’t collapse the multiple scaler parameter, but I can collapse the vector2 and vector3.
It doesn’t bother me when I use append to combine the 2 vectors. I am more concerned about the look and design of the Material instance parameter field.
we don’t need multiple parameters on a material instance when we can simplify it using parameters like vectors 2 and 3.
I agree that we could use these parameters and I am aware that what I am posting is not a solution, just a partial workaround, but it can help at least a little bit You can name the Float4 parameter channels whatever you want
And then in the Material Instance dialog, you can see the names:
If nothing, you can at the very least use these channel names to let user know that for example B and A channels are not used by naming them as “unused” or “none” or “empty”
I am not sure if this is true, but I always assumed the reason we can’t parametrize Vec2 or Vec3 is that the GPU shader math internally only works with Floats and Vec4s, so if we had Vec2 and Vec3, it would still be stored as Vec4 internally with some bits just unused. This solution kinda pushes user in the direction of utilizing all the bits allocated in memory for given type so they don’t go to waste. I may be wrong though. I’d love someone more experienced to chime in.
then why do they have constant vectors 2 and 3. if we can have constants then we can also have parameters.
and about vector 4 and changing channel names to suit the need. there are a few issues with that.
It’s slow
it’s clamped and required manual input in the field if you want to enter a negative value or higher than 1.
if you grab the field and try to increase or decrease the value by mouse movement. it will reset the values higher than 1. so you will need to set all the values again.
filling extra channels with words like none or empty make it less user-friendly.
And you ignored the enums. they already have an enum parameter built in an unreal engine with the name of “Mask Channel”.
So we should also have access to enums so we can avoid multiple booleans.
Prolly b/c on the card, everything is a 4vec. A 1vec can be easily interpolated across X-spaces, but a 2 or 3 vec cannot be readily expanded into a 4vec based on some kind of assumption; it’s the same reason LERP has that quirk.
Plus, on the compiler, it’s likely easier to pack single-channels vs blocks of 2 or 3.
Since the node-based UI is middleware, the more assumptions they have to make under the covers, the less reliable it will become.
At some point you have to say we won’t (can’t) do this because there’s too many things that might muck up someone’s code if we guess wrong, it’s not worth risking that so let’s just leave X, Y and Z at a basic level.
This is more a thing with abstraction vs shaders; anytime the dev has to assume the thinking of the user, they’ll likely get it wrong.
You can name the Float4 parameter channels whatever you want
