[Toolkit feature]: Roughness strength slider/adjustment

[Kim2091]

Contact Details (Optional)

No response

What is the context of the feature/improvement?

Roughness maps generated by AI aren't always that good (in fact, they're often quite bad). Sometimes they're far too strong, and other times too weak. On top of that, the flaws may be too apparent at the default strength.

Please describe the feature/improvement?

Adding a slider or setting to adjust roughness map strength to the toolkit, similar to the strength adjustment for displacement maps, would be great and should help mitigate the issue mentioned above.

What would be your solution? (optional)

No response

Version

2024.3.1

Media

No response

[automata-rtx]

This would be a killer feature. If the slider was still functional after inputting a roughmap, the slider could change to bias the roughness in one way or another via curves or something on the roughness map itself.

For example, an AI PBR roughness map for a rock. Maybe the AI model mistakenly made parts of the rock far too shiny. The variation in roughness is still visually interesting, but by using the slider (after a feature like this would be implemented) you could bias the whole map to be brighter, lowering the gap between the parts the AI model recognized as rough vs shiny.

The end result would be a properly rough rock texture that has minor variations from the generated map, so it would still be superior to having no roughness map at all.

It would go a long way to make AI generated roughness maps way more viable. If one didn't turn out well, you just bias it in the toolkit using the slider. It would also make the burden of training roughness models far less daunting since it's a difficult thing to nail down.

[nvdamien]

Hello @Kim2091 and @automata-rtx,

It's important to understand that AI textures will never be perfect, at least for now. Attempting to post-fix them would only add more work to the renderer, potentially impacting performance. The main bottleneck in runtime is actually memory bandwidth, which is why we opted to support 'Either texture id or a constant value' for each channel, rather than 'texture id and constant value' to keep the material size on the GPU manageable.

Moreover, adding a slider or curve to compressed textures (dds) may not yield desirable results.

To address this issue, there are a few potential solutions:

1. Develop a more advanced AI model that gives "perfect" result (work in progress).
2. Pre-process the textures offline before converting to dds. Fortunately, we will have a RestAPI available for users to process data externally. For example, a graph could be created in ChaiNNer or ComfyUI where we post fix AI textures, converts them to dds, and integrates them back into the game.

Does it make sense?

[MarkEHenderson]

To expand a bit on Damien's post:

We don't want to do this per-material in the runtime due to memory bandwidth, but we do have option to manipulate all roughness values at the same time here: You can use the Roughness Scale and Bias values to figure out good values for your roughness map, and then actually apply those to the texture in photoshop or something like it.

It could be possible to have an option in the toolkit for altering the textures, but sub-optimal. Toolkit ingestion will compress the textures into DDS, and trying to alter and recompress that texture will result in compression artifacts building up. You'll get much higher quality results by altering the uncompressed texture and re-ingesting it.