I wonder if anyone can shed light on best practice for material performance.
I don’t necessarily have performance issues right now, but would like to get in to the best practice to mitigate it down the line.
So my question is, do we have to structure materials like the M_Owen_Master (in the Content Examples) or, can we break the M_Owen_Master in to multiple materials without a performance hit.
I am open to suggestions, as from a programmers perspective, M_Owen_Master currently resembles a “God” class and breaks the single responsibility principle.
From a programming aspect you are correct, you want to have a class for each new type of functionality. However, for shaders and GPU rendering, and remember a Material acts as a shader instruction call to the engine, it is better to have few draw calls and therefore fewer materials. M_Owen_Master allows one draw call to completely shade our Character with only slight math and texture variations which are calculated during the initial draw call (This is how instancing works in Materials.)
So to expound, if I had a group of Opaque materials which are all setup (Shaded) in a similar fashion with only a value changed here and there I would create a master material and then instance out the material thus resulting in 1 draw call and some math calculations rather than 5 to 6 different draw calls. In the same vein if I then wanted to use those same objects for a particle system, I might make a new master material which accommodates the new usage more than the original master did and instance again. In this way, the materials do work on the single responsibility principle just on a broader scope based on shader type.
Hopefully that explains what you are asking, if you still have questions feel free to ask,
Great to get, from the sounds of it, a programmers perspective
This would be a valuable resource in the documentation.
Lessons learned: Blueprints are what they are, and that is that they’re great!
It would be nice though if we could follow more SOLID principles http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29 although I understand this is asking a LOT!
I think the main thing that I really think would be helpful is any kind of documentation implement design patterns in BluePrints, to manage the above complexity. (Somewhat for the, edging on, OCD folk - like me
I will open a new question for this though as it really is very important to me
I am glad I could help clarify these things for you, but keep in mind that Materials are Shaders and are coding through HLSL (High Level Shader Language) and not C++. Blueprints are a visual form of Programming with C++ (gross simplification).
