[Toolkit feature]: Option to use colormap as the source for emissive map

[wolfestridershooter]

Contact Details (Optional)

No response

What is the context of the feature/improvement?

It would help us avoid having to use a solid emissive color for large area displays.

Please describe the feature/improvement?

Option to use colormap as the source for emissive map.

What would be your solution? (optional)

...

Version

2024.4.1

Media

[anon-apple]

Just to be clear, you can provide an emissive texture if you want to use a non-solid emissive color by just replacing the material. Furthermore this is already how it works too if the material is set with an emissive blend mode. If you replace the material you can set an override on the blend mode to force it to something emissive like additive which will do this.

I assume though this is asking for a way to use the original material's color texture for both the albedo and the emissive for auto-translated materials specifically via something other than the replacement path. Is that correct?

[xoxor4d]

I assume though this is asking for a way to use the original material's color texture for both the albedo and the emissive for auto-translated materials specifically via something other than the replacement path. Is that correct?

@anon-apple Similar to that yea! The issue is that we can't set an emissive replacement texture as the unreplaced albedo is a video file (bik - rendered by a shader). Using the unused renderstate PR that is currently up, I can force the material hash for it which allows tweaks via the toolkit.

I enabled emission and set a solid color but doing that will somewhat eliminate the albedo. I have currently set the blend mode to multiply but that somewhat inverts the white parts of the video file which are now black.

Will add an image in a sec.

[anon-apple]

Well the problem with that is if the material can't be identified in any way suitable for replacement it's not going to be identifiable to some sort of option to do this outside the usual replacement workflow. There needs to be some sort of stable identifier for such things and indeed video files and whatever do pose a challenge.

I think we've talked about having a way to assign materials based on a mesh hash instead if that is stable (would be a bit more tedious though since many meshes would have to be flagged) but I don't think there's a way to do that currently.

[xoxor4d]

Indeed! This would only be useful for projects with code access in some form or another. With the mentioned PR, it is possible to force a material hash for a specific drawn surface. But again, that is only useful if one has code access and can uniquely identify and intercept rendering of that surface (which I have here:)

https://github.com/user-attachments/assets/aa46ad71-61fd-4ee5-bcd2-cf0ff8d5504b

Should look like this:

It's a really niche QoL thing with very low priority. I think additional blending options in the toolkit might be the better way?

[anon-apple]

Well it should work fine really, each blend mode has "interesting" behavior trying to mimic the way raster kinda looks, in the case of multiplicative white regions are considered "transparent" so that's not really what you want. Have you tried additive, as that will convert albedo to emission directly to mimic the emissive effect it usually has in raster.

Of course really these objects aren't blended so using the blend mode to get it to do this is a bit odd overall as it will add an opacity component to things which is undesirable. I think the ideal solution would be some sort of way in the Remix API to programmatically remap the game's texture slots into the PBR materials rather than just relying on the limited amount of ways we support the remapping right now.