Looking for help to achieve plugging an existing material into a material function or material… or convert it to a function…
My impression is the only way is to copy the whole material graph which is not only ridiculously tedious for a library of materials but breaks things all the time. So material once it’s done is basically dead end code and whatever is not exposed in instance parameters can’t be expanded upon without changing the actual graph.
Say i want to colorize the albedo but the material has no node for it. I would expect being able to make a function with a color input that i can call from a new material and give it the other materials output.
I am not sure what you want to do but have a look into Static Switches.
Static Switches allow you to enable or disable entire branches of Material nodes in your Material Instance by check on or off a checkmark box. In your example, you could have a Static Switch that allows you to enable some Materials to use a simple color for the Base Color while others can use a 2D Texture for the Base Color.
What he wants to achive, is being able to extent an already existing material with additional nodes/functions, without actually going into that material. With instances, you have to plan for every possible scenario in advance, you cannot expose or use nodes, values and switches, that you have not programmed into the main material.
He wants material A with just some nodes in it, then being able to use it in material B as input, add there some additional nodes, so that he can have two materials, which would make material B the sum of material A plus those additional nodes, while at the same time keeping material A and all it´s instances unaltered.
This could be realized, if there would be the ability to convert mats into material functions, or create material functions (or an adapter), that can be linked to materials, which then possess the same nodes as the linked mat (thinking about layered materials and their requirement of material functions instead of materials…).
Thanks Suthriel, this description is spot on, thanks for taking the time ! I always thought of it as similar to the texture sample/object just with a material (to hook it up to a break material attributes or such for further alteration. And ideally being able to take Material Instance as an input i guess to save compile work).
@Sam, always enjoy your UE4 training videos they are great.
Not what you want as described above, but you should look into (I think still alpha or beta) material layers.
Otherwise - currently - you would have to manually create functions to use into a final material the way you describe.
while its not that complicated you end up paying for it performance wise with the number of instructions, so it can get troublesome.
however you can set the output of a material function as the result of a make material attributes.
This allows you to take the output into the material and break it to access all the different material pins.
This is sort of similar to how the layers are supposed to work. Except for you do it all manually yourself…
@Sam
I think if you can pass along this as a feature request it would be a great addition.
You can think of it as a class extension in OOP. Or better yet, just allow us to call a different material or material instance within a material.
The data we need is all already present and can be broken up into pins (I would assume) like a function with make material attributes as an output pin.
this would potentially extend ease of use, as well as possibly enable some interesting recursion? Well not sure about recursion, since everything would likely crash, but still…
What would cause a crash in this case? We would not want infinite loops per cycle or frame, just reading the original mats values, doing our calculations and whatever the mat is intended to do, and then write it back, so that the next frame can start with the new values. So we would only get one loop/calculation per frame.
Only problem would be, if there are two or more mats using the same mat for their calculations, and that the first wants to write while the second wants to read the same stats. Could cause some confusion, if the second mat would not know, if it has to use the original values or the new values from the first mats calculation. However, this could be avoided, if all mats are forced to read the original values at the beginning of the cycle, use those values no matter what other mats do before its their turn, and then all mats can write their results. Would probably require twice the memory, since it has to store the original values at the beginning, and the results from all calculations, that happens until the last material is finished, because writing them would only happen at last step, for all mats.
Because of the HLSL conversion implementation most of that is not really applicable.
Reading data in is one thing - we do it all the time with custom shaders or custom nodes. And should be straightforward.
Recursion however, like calling the material you are editing within itself can be problematic to say the least.
Priamarily because it creates infinite permutations by nature. As you should know, an infinite loop causes a crash (or at the very least memory issues). Same theory applies here.