Please take a look at the SpineEffectNormalmap.fx file and workflow, which uses an additional input texture (the normal map). You could just create a similar effect file with an emissive color texture which is then used accordingly, adding a read emissive color to the result color.

I have quickly added the necessary lines to the SpineEffectNormalmap.fx file (and named it SpineEffectNormalmapEmissive.fx). I have not tested it, but basically that should be all that's needed, along with providing the emission map as an additional input in the c# side of code, just as the normalmap was added.

What does your emissive texture look like? The emissive texture will not act as a light source (which is not trivial, even more so when not using linear color space), it's just an additive texture layer.

I just noticed that the effect file is not using premultiplied alpha but straight alpha textures, so just add the line

emissiveColor.rgb *= emissiveColor.a;

before adding the emissive color to the output.

Please in the future look at the respective shader code and try to diagnose the situation yourself. It's only three lines that were added to add for the emissive effect, one line that determines how the output color is affected. As a programmer you should be able to figure out what output = saturate(output + emissiveColor); does if you are working on your own game framework.

Glad to hear it helped, thanks for your kind words! :nerd:

Learning the basics of shader programming can be very worthwhile, you can achieve a lot with little knowledge already. Basically shader programming boils down to the following:

1. You always have one vertex shader, and one fragment (pixel) shader.

2. The vertex shader is applied for every input vertex from your mesh. One vertex in, one vertex out - it receives a single vertex's set of data (local position, texcoords, vertex color) and outputs a single vertex with a (different) set of data. Any local position data is transformed (by multiplying localpos with the model, view and projection matrix) to what's called clip-space (which is just some simple transformations away from screen space). This is a required position output since the pipeline will automatically rasterize the triangles and then pass each fragment (pixel) to the fragment shader for further processing. The fragment shader input data values are just the (interpolated) output values of the vertex shader.

3. The fragment (pixel) shader then needs to output (return) an rgba color value, if you return float4(1,0,0,1); you receive a red opaque pixel on screen. The fragment shader can now sample textures at the provided input texture coordinates (which were output by the vertex shader). Since we don't always want fully-bright textures, it can use whatever lighting calculations to determine that the pixel is lit with e.g. intensity 0.5 at the given angle to the light. Light intensity is then combined with the diffuse texture in our case, by simple multiplication. Basically lighting and shadows are always applied by multiplying a color value with something less than 1.0.

4. One thing to note is that color values (sampled texture color, vertex color, etc) are always normalized float values in the range 0.0-1.0, not the 0-255 integer rgb values of your texture file. To prevent any overflow of the output pixel color value over 1.0, there was the saturate(..) call used, which returns the input value clamped to the range [0.0, 1.0].

The following intrinsic functions are available in hlsl:
https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-intrinsic-functions

You're welcome, hope it helps.