Is it possible for the Emissive Color input to intake multiple RGBA channels?

[Iratus_Despero]

So being fairly new to materials, nodes and pretty much all of the related material here it’s been fun crashing through all of the problem solving, hitting walls and finding new solutions to the problems.

Currently I have a material for a sword item I’ve been working on after quickly finding out procedural material nodes didn’t transfer when I tried bringing the model over from blender.

Fixing the other textures using the built in UE5 auto UV unwrapping tools from the modeling plugin made that part super easy, so my challenge was reinserting glowing runes onto the sword model. I didn’t want to take a bandaid approach of just slapping an emissive decal onto the sword actor, so I set about it and got it setup.

So placement / scale are all correct, and it’s on both sides of the object.

However to achieve this I had to use two separate texture samples because I couldn’t get the texture wrapping to work properly at the size it needed to be (wouldn’t line up exactly on both sides) so I clamped it and used two instead.

Problem is, with only one Emissive color input in the final material, the only way I can control them independently is by separating the color channels each of the textures uses, obviously less than ideal if you’re looking to have a uniform color for said glowing texture on both sides.

So that makes me wonder, is it possible to have two textures being input with the full range of RGBA channels into the emissive input via some kind of other joining connector (the ones I tried didn’t work) and retain control of each texture independently to move / color without affecting the other? Since, right now if I have them both using all channels it just winds up overlapping and changes to one will affect both.

Perhaps I’ve come to the wrong solution for the problem? Looking for advice.

[BananableOffense]

A pixel can only be one color at a time. So they will always need to be combined into a single RGB value somehow before being pumped into the emissive.
There are many other ways to combine them however. For example the “Max” node takes the maximal value and throws away the lesser value. The “Min” node does the opposite.

[Iratus_Despero]

So the two textures being output by the emissive count as the same pixels? At least that’s what I’m getting from this. I wonder if it’s possible to modify the core final material node itself to enable additional emissive colors to be added.

Either way, i’ll have to investigate the min / max nodes, that sounds interesting.

[BananableOffense]

You may want to think about it more abstractly.
In this case, the circle mask is applying two colors to the same pixel. Adding them together results in yellow, which is fairly intuitive.

Here, the UV coordinates of the mask have been shifted, so the circles only partially overlap. Areas that neither circle filled will have a value of (0,0,0). Areas filled by either circle will be (1,0,0) or (0,1,0) and areas filled by both circles will be (1,1,0).

Here, I’m using the mask as an alpha for a lerp, which allows me to draw the red on top of the green rather than mixing them.

Here I’m using a Min node. The minimal value on most pixels is (0,0,0), except where the circles overlap. In that case, the minimal value is (0.1,0.1,0.1) creating the almond shape.

The point being, you can combine, compare or write the values to a pixel any way you see fit - But there can only be one output for a given pixel. It’s usually wise to think about these values not as colors but instead vectors which you are performing math operations on.
Having multiple RGBA channels for emissive doesn’t make sense, in the same way having two base colors doesn’t make sense, or having two roughness values. Does the pixel represent a smooth surface or a rough one? One point in space can’t be both at the same time. Is it a red pixel or a green pixel?
While it can’t be both, but it can be some kind of math operation performed with those values (like an add, average, min/max, multiply, lerp, etc).