Thats a really good idea. That's essentially what i was hoping to do. Store some coefficient that transformed the diffuse into the emissive factor.

Sort of like barycentric light coordinates. Where a 0.25 would indicate that the stored color is 0.25 between diffuse and emissive.
So neither the diffuse nor the emissive value were directly stored, but rather the barycentric value and coordinate were stored.

I'm not sure if that's even possible. But your solution is almost exactly that, assuming the only difference between the two colors was intensity.

Thank you. I'll run that by them.

edit:
I'm using unpacked because each channel is only using 8 bits.
I'm pretty sure we could spare another render target. But i would be proud of the implementation if it only needed 2 targets. It would also obviously be significantly better with less render targets. In terms of memory and texture fetches and resolve times.

Well, you want to keep your artist Then this is the way I do it my engine:
I support multi-layered, emissive materials, but in the g-buffer I only store the index of the material, in the lighting pass I take this index, get the material vectors and use it to do the calculation. To handle materials more granulary I save 2 indicies and an alpha value per pixel to interpolate between different material. All material vectors are saved in const shader parameters (as said, only needed in the lighting pass). When rendering a model to the g-buffer, I use a uniform parameter per surface to hold the indicies and an alpha value saved in a texture to manage the material distribution.

I would change your current gbuffer like this:


RGBA8: diffuse RGB 8 bits each, 8 bit material index A
RGBA8: compressed normal xy 8 bits each, 8 bit material index B, 8 bit alpha value


// lighting pass pseudo shader code:
vec4 materialA = materials[material_index_A]
vec4 materialB = materials[material_index_B]
vec4 material = interpolate(materialA,materialB,alpha)

final_light = diffuse * (light_factor * material.diffuse_channel + material.emissive_channel) + diffuse * ( pow(spec_factor,material.spec_exponent) * material.gloss)


This way you have some freedom to expand the material properties (I currently use 3 material vectors), while keeping a constant impact on the g-buffer.

An alternative is to save the texture coords and make several texture lookup.

For normal compression take a look here: clicky

Having the g-buffer output emissive as the starting point for light accumulation works out fairly well.

You can't avoid clearing the buffer to black, so you might as well have the g-buffer pass fill it in for you.