NVIDIAGameWorks
[Runtime feature]: Option to use colormap as the source for emissive map
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
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?
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.
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.
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?
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.
Is the ask here to be able to edit original material prims in the toolkit in the same way that you would be able to edit a replacement material? (which is the current workflow for using emissive map)
Is the ask here to be able to edit original material prims in the toolkit in the same way that you would be able to edit a replacement material? (which is the current workflow for using emissive map)
Mh not really no. This is a very niche thing :D The original colormap is animated which means that the hash is also constantly changing. I have made changes on the runtime side to force hashes per prim (ignoring the auto generated one) so that I'm able to use a replacement material on the tv prim.
Now to get the texture to be emissive (matching the colormap), I would have to "animate" the emissive map. You'd normally do that with a spritesheet but that will not work here because A. it will never sync with the animated colormap and B. it's not feasible to create a spritesheet that matches a video file.
So having a setting (eg. a simple "checkbox") in the emissive section of the toolkit that makes the runtime automatically use the colormap that is either set (albedo replacement) or not set (the original d3d colormap) would help in this case.
Not sure if that would help in any other situation .. tho I have made some replacements for certain particles and had to ingest the captured colormap so that I could 1:1 re-use it as the emissive map