Keep in mind this feedback is from someone with extensive programming, game and film development and 3D art experience who is new to Unreal. I say this not to make the feedback easily dismissed but to frame the perspective of someone who is not clueless having an initial reaction to Unreal’s toolset.
Specifically, I was referring to the LightVector node and the fact that this in the toolset, leads me to assume there are other instances of this that are not bound by technical constraints but rather developer whim. LightVector errors out if you try to use it in any other context than Light Function or Deferred Decal. I can still get a light vector wherever I want but I have to use a material parameter collection to do it which is an entire additional obtuse layer. This works so long as I want the same light vector(s) for every instance of a material that requires a light vector, but this, as idiotic as it may sound, is not often what I want. I intend to put some materials on the marketplace that use this functionality and I think it will be a bad user experience that users will need to duplicate the material, crack it open, create a whole new material parameter collection, and set up a blueprint when they want unique light vectors in different instances of the material. This is something that should be a simple parameter exposed in the material interface. I am trying to do something in Unreal that doesn’t obey the laws of photorealism and it feels like the decisions made in Unreal’s design are putting up constant small roadblocks that are engineered to force devs to use the tools the way Epic intended, specifically to create high performance games with a decidedly photoreal or hyperreal look. It’s frustrating because I can see everything I need is in the engine, but it’s been intentionally engineered, according to the answers I see here and on the answer hub, to make it difficult or undesirable to do certain things because someone couldn’t imagine an end user using the tool to do anything other than make a photoreal game.
As long as I’m airing grievances, the user facing glossary exposed in the toolset is inconsistent and confusing. Examples:
Everyone knows what a lerp is. Every programming language seems to have a lerp(), your editor node is called lerp, yet it is presented in the menu as LinearInterpolation.
2Vector, 3Vector, 4Vector. No defined type in C/C++, Cg, or HLSL begins with a numeral, and it’s bad form if not outright forbidden by the compiler in every language I’ve used for a user defined type. Why is this acceptable in a visual programming interface built on these languages? Vector2, Vector3, Vector4 is the common presentation in other software/interfaces.
A vector can be a lot of things, particularly a Vector3. Why is it always presented with a color picker in the user interface? I think this is confusing for less technical artists who use materials developed by someone else. Although a color is a vector, it is common for other tools and languages to make a type distinction to eliminate the confusion of vectors representing colors vs vectors representing positions or directions.
BreakOutFloatNComponents? Why not a more understandable name like VectorNToFloatN.
MakeFloatN. Another head scratcher. It creates a vector from N floats. The tooltip even says this. Why is it not called MakeVectorN or FloatNtoVectorN to better align with the above vector conversions.
The whole menu organization is pretty haphazard. Nodes exist under multiple headings, not awesome, but accepting that, there are many of fundamentally the same type and use that do not exist in the same place(s) in the menu. Some vector and “coordinate” node names have WS postfixes while others that are also in world space do not. Why is there even a WS postfix at all? What other space might be applicable to something like a camera position? It’s like you can tell just by naming conventions Dev A implemented these nodes, Dev B did these nodes, Dev C… etc.
There are a ton of small issues like the above that I think are pretty obvious and addressing them would go a long way toward making the tools more accessible and user friendly for both artists and programmers. All in all Unreal is one of the most sensible and cohesive tool sets to game development I’ve see from a top level, which makes it all the more frustrating to see things get so inconsistent and sideways at the lower levels of the toolset.
I love Unreal. There are a lot of things about it the Dev team nailed in terms of design and implementation, but I’m consistently encountering issues that I then read about on this forum or the Answer Hub the just baffle or frustrate me, especially when I see explanations that amount to the devs don’t want users to do that.