- Status
- Offline
- Joined
- Mar 3, 2026
- Messages
- 703
- Reaction score
- 457
Anyone else hitting a wall with the AniGraph2 update for CS2 skin rendering?
Legacy skins like the Printstream are currently a mess in internal inventory changers, rendering with non-legacy UV maps even if you're doing everything "by the book". If you are seeing distorted textures on your weapon models, the engine is likely overwriting the UV layout faster than the current logic handles it.
The Current Logic Flow
Most internal implementations are following this standard path to handle the viewmodel:
The problem is that even with SetMeshGroupMask(2) called on both the weapon and the HUD model scene nodes, the legacy UV layout just won't stick. It seems the composite builder is ignoring the mask during its specific build phase.
Internal Reversing Notes
The engine's internal legacy UV handler pattern looks like this for those digging through the binaries:
This function (internal sub_18071AB40) usually traverses Weapon -> Composite Entity -> Scene Node to set the mask to 2. However, calling this manually on the weapon pointer hasn't been a silver bullet after the recent AniGraph2 changes.
Prevention & Troubleshooting
I've tried hooking hkFrameStageNotify at Stage 6 to prevent the engine from reverting the mesh group masks, but the UV mapping distortion persists. The composite builder seems to take preference over these manual overrides during the skin application process.
Has anyone successfully forced the composite builder to respect legacy UVs when injecting skins via the fallback kit? There might be a specific function we need to hook to override the UV set properly before the scene node finishes rendering.
Drop your findings or crash logs below if you've been messing with this.
Legacy skins like the Printstream are currently a mess in internal inventory changers, rendering with non-legacy UV maps even if you're doing everything "by the book". If you are seeing distorted textures on your weapon models, the engine is likely overwriting the UV layout faster than the current logic handles it.
The Current Logic Flow
Most internal implementations are following this standard path to handle the viewmodel:
- Scanning for cs2_hudmodel_weapon and matching m_hOwnerEntity to the weapon pointer.
- Injecting the skin via m_nFallbackPaintKit.
- Triggering updates using UpdateSubClass and UpdateComposite (vTable index 255).
The problem is that even with SetMeshGroupMask(2) called on both the weapon and the HUD model scene nodes, the legacy UV layout just won't stick. It seems the composite builder is ignoring the mask during its specific build phase.
Internal Reversing Notes
The engine's internal legacy UV handler pattern looks like this for those digging through the binaries:
Code:
48 85 C9 0F 84 ?? ?? ?? ?? 55 41 56 48 8B EC 48 83 EC 58 4C 8B F1This function (internal sub_18071AB40) usually traverses Weapon -> Composite Entity -> Scene Node to set the mask to 2. However, calling this manually on the weapon pointer hasn't been a silver bullet after the recent AniGraph2 changes.
Checking C_PaintKit shows an interesting offset at 0xAE (use_legacy_model). Setting this flag should theoretically nudge the composite builder in the right direction, but testing indicates this alone isn't enough to correct the UV mismatch on skins that require the legacy layout. There might be an attribute in CEconItemView that we're missing.
Prevention & Troubleshooting
I've tried hooking hkFrameStageNotify at Stage 6 to prevent the engine from reverting the mesh group masks, but the UV mapping distortion persists. The composite builder seems to take preference over these manual overrides during the skin application process.
Has anyone successfully forced the composite builder to respect legacy UVs when injecting skins via the fallback kit? There might be a specific function we need to hook to override the UV set properly before the scene node finishes rendering.
Drop your findings or crash logs below if you've been messing with this.
