NVIDIAGameWorks / NVIDIAGameWorks/rtx-remix

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

Open
#831 3 comments 5 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug jira runtime
Dominant language
No language data
Stars
1.7k
Forks
99
PR merge metrics
No merged PRs in 30d

Description

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:
Image

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

Findings

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

  • 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:
Image

  • 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:
Image
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

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in src/lssusd/usd_mesh_importer.cpp around line 480 and inspect how displayColor and displayOpacity are decoded for replacement meshes. Reproduce with WindowPlanks.zip, including authored colors, opacity, and blending enabled. Done means vertex colors and opacity work on replacement meshes without channel swapping, unintended additive blue, or disappearance when blending is enabled.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
computer-graphics
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.