The I of the Dragon - missing geometry

[WinterSnowfall]

The game is known to have some rendering issues even on Windows, however WineD3D seems to do better than d8vk in some regards, for example rendering all the bits of the flying rug under the prophet at the start of the first mission:

Here is d8vk:

Here is WineD3D:

The problem is visible in the below trace.

Software information

The I of the Dragon (GOG)

System information

• GPU: RTX 3060
• Driver: 525.89.02
• Wine version: 8.5 Staging
• DXVK version: 2c56a1a

Apitrace file(s)

TheIOfTheDragon.trace.tar.xz

Log files

• d3d8.log: TheIOfTheDragon_d3d8.log

[WinterSnowfall]

It seems I spoke too soon. This bit used to look good on Windows, at least at some point.

[dungeon007]

IDirect3DDevice8::ProcessVertices

WINED3D just tries to emulate this via GL... and probably clipping fails there or missies some precision within drivers, maybe that needs some of the wine flags, but not sure in that is the case...

Seems only DGVoodoo2 does them correct:

Even on d3d8to9/dgv2 looks the same, so these arent your problem... probably DXVK d3d9 have to support this right.

Not sure if any D3D9 driver supporting this if game runs via d3d8to9... I mean if some D3D9 driver of RGB vendors on WIndows do this correct via d3d8to9 (so emiting such d3d8 parts of ProcessVertices on d3d9 too), then it is possible.

DGVoodoo2 is a different beast and crazy what it supports, even do D3D8 ATi TruForm:

This does not sound at all to be possible on D3D9. You have to convert DX11 tesselation down to emulated TruForm N-Patches support . So, no any chance D3D9 to do this.

[WinterSnowfall]

Thank you for checking with dgVoodoo2 and confirming it works. That is actually good news. If there's missing functionality in d8vk's ProcessVertices when comparing to native drivers (or at least dgVoodoo2) and we can't rely on d3d9 to behave properly, then it's something we can look into adding.

It won't necessarily be a priority, since I don't think we've run across such problems in other games, but definitely something to keep in mind and address at some point.

[AlpyneDreams]

Notably, the log shows the game using unsupported render state D3DRS_CLIPPING. So it's possible that could be related, or not.

[AlpyneDreams]

It is indeed something ProcessVertices-related.

Source VB: (same FVF is set before ProcessVertices)

Dest VB: (same FVF is set before subsequent draw calls)

This second shader is actually the problem, as it's doing m_viewportInfo and xyz *= 1 / w transformation on the position when it should just passthrough the already-transformed position. Alternatively, maybe the real issue is with the FFVS used by ProcessVertices since it's an edge case using blend weights.

[AlpyneDreams]

Doesn't appear to only affect blended vertices. It's possible there may be behavior differences between d3d9 and d3d8 here in ProcessVertices but I'm not sure of that.

[AlpyneDreams]

I expect the best fix would be to test ProcessVertices on native D3D9 vs. native D3D8 vs. d9vk. If D3D8 and D3D9 are different then then I'd need to implement a workaround in d8vk, otherwise if d9vk is different then I'd need to change the behavior of d3d9 ProcessVertices/d3d9_swvp_emu to make it be the same. If they're all the same then there might be something wrong with how d9vk is handling XYZRHW.

[WinterSnowfall]

Now tracked here: https://github.com/doitsujin/dxvk/issues/4115