[Runtime Bug]: Authoring vertex colors via displayColor and displayOpacity attributes is broken

[EmanuelKozerski-Wa]

Describe the bug

Context

Since vertex-based tinting works for original game assets, I decided to author some vertex painted colors in this window piece to have more unique detailing options with reusable/tileable texture maps. But the colors are all messed up:

Here is the setup in blender and how the colors look in OV when no material is assigned to the mesh.

Findings

Investigating a bit, I assembled this pallete setup to test:

• 6 circles + panel on the left uses the window material
• 6 circles + panel on the right use a new full white material
• 6 circles on top use 0.5 the primary color intensity. I.e: red is (0.5, 0, 0)
• They fade from their full primary color to white. The panels also fade to black at the bottom.

This is how it looks:

• Basically, you always get a 100% blue color.
• Any authored displayColor will be Added+ to that base (0, 0, 1.0)
• Only thing is, the channels are off by 1. So Red is Blue, Green is Red, Blue is Green

According to @MarkEHenderson, this part of the code is responsible to handle color decoding: https://github.com/NVIDIAGameWorks/dxvk-remix/blob/main/src/lssusd/usd_mesh_importer.cpp#L480 Should be changed from:

const uint32_t enColor = D3DCOLOR_ARGB((DWORD) ((color[0]) * 255.f), (DWORD) ((color[1]) * 255.f), (DWORD) ((color[2]) * 255.f), 0xFF);

to:

const uint32_t enColor = D3DCOLOR_ARGB(0xFF, (DWORD) ((color[0]) * 255.f), (DWORD) ((color[1]) * 255.f), (DWORD) ((color[2]) * 255.f));

Tried myself but was unsuccessful at building and running the newest runtime version locally (deadlocked black screen at start).

How do you reproduce the bug?

For messed up colors:

• Just add a quad replacement mesh with painted vertex colors in a displayColor attribute, or use my pallete setup: WindowPlanks.zip

No materials should be necessary but since replacements inherit parent mesh material, the actual look might be off a bit, so replacing a white mesh or adding a new white material helps.

For opacity blending:

• Same quad, but author some displayOpacity values on its vertices. Having only displayColor or displayOpacity alone, or both, should all behave as expected.

What is the expected behavior?

Expected Behaviour

1. Vertex colors authored as displayColor and displayOpacity attributes should be applied to replacements meshes the same way they are to original draw calls.
2. Targetting opacity blending specifically, displayOpacity should allow blending the mesh when enable blending == true so we can detach and recombine blending from/with the texture maps as needed.
3. Bonus points to gryffindor if it also works on TranslucentPBR.

Extra Testing

I caught a problem that enabling blending on meshes with authored displayColor/displayOpacity attributes make them disappear.

Use Cases/Benefits

Blending these dock pillars with a wet version of the same wood material is not possible, as it requires a new decal mesh with UVs mapping to a gradient texture to drive opacity: But that makes the normals, albedo, height, roughness to fade alway as the decal mesh is just a smooth black cover.

With vertex colors and alpha blending, we have two options:

1. Paint the dock pillar vertices directly to darken the colors
2. (Ideal) Duplicate the pillar mesh and its material, but with black albedo and low roughness, and use displayOpacity to drive the mesh blending as a decal.

Version

Latest actions and also current ToT (7cef72a7270befce5a16837bcbb94a3b232cea55)

Logs

No need

Crash dumps

No need

Media

No need, but check the convo on discord if you need more context: https://discord.com/channels/1028444667789967381/1196836285545971712/1363891451964030997

[Ekozmaster]

Adding to that, the vertex color math blending operation should multiply with the base color. I'm not sure what is going on here but my blender setup and remix look very different:

[NV-LL]

Thanks for reaching out! We've filed REMIX-4189 for internal tracking.

[MarkEHenderson]

Added a global option to toggle handling vertex color as lighting here: https://github.com/NVIDIAGameWorks/dxvk-remix/commit/931122dc47f7b2a625df33d705ee91fcb3d8fa00

Also updated the ingestion process to allow for vertex colors (as well as some other things that shouldn't have been stripped) here: https://github.com/NVIDIAGameWorks/toolkit-remix/commit/bbbf1d743cfa598b799aae7f5f692790fbb679a8

Supporting per-mesh options for vertex color handling won't be doable for now, but I'll keep it in mind for the future - hopefully we'll be able to support manually controlling the color and alpha blend modes within the toolkit, and that should include control over how the vertex color is handled.