Fix cubemap face orientation and per-surface assignment timing #41
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Problem
BSP env_cubemap support was added (#21) but has two remaining issues:
1. Cubemap face orientation
The cubemap face remapping from Source VTF order to Three.js CubeTexture order uses
VTF_TO_THREE_FACE = [3, 2, 4, 5, 1, 0]based on the coordinate conversion (threeX=-srcY, threeY=srcZ, threeZ=-srcX). While the face assignment puts sky on the +Y face (correct), individual face images may need horizontal or vertical flips to match Three.js cubemap sampling conventions.Reference: https://tf2maps.net/threads/tutorial-custom-envmaps.49699/ — details on how Source assembles cubemap faces and their orientations.
The same face ordering applies to the skybox cubemap in
skybox.js(suffix order['bk', 'ft', 'up', 'dn', 'lf', 'rt']).2. Per-surface cubemap assignment timing
28 cubemaps load from the BSP pakfile, but
_applyPerSurfaceCubemaps()runs before most BSP surface materials have resolved their VMTs asynchronously. Result: only ~2 of 153 envmap surfaces get per-surface cubemaps, the rest fall back to the skybox cubemap.The fix needs to ensure per-surface cubemaps are assigned regardless of material resolution timing — either by re-running assignment when materials resolve, or by deferring assignment to a later point.
Related