解读

国内一线厂在Unity 2021 LTS及以上版本普遍把GPU Lightmapper作为正式烘焙管线，而**RTX Cache（官方称“GPU Lightmapper Cache”）**决定了光照贴图烘焙时的显存占用与迭代速度。面试官问“如何分配”，并不是让你背菜单路径，而是考察三点：

1. 是否理解Cache的显存池机制与**场景分块（Chunk）**关系；
2. 能否根据目标显卡档位（60系/70系/80系）与场景规模（千米级开放世界 vs 室内关卡）给出量化策略；
3. 是否能在多人美术并行烘焙的CI环境下，通过脚本或版本管理避免Cache冲突与显存爆炸。

一句话：把RTX Cache当“显存预算”来设计，而不是勾个选项就完事。

知识点

1. Cache文件本质：GPUCache文件夹下的*.cache与*.txn文件，记录Lightmap Texel与RTX BVH中间结果，复用率=1-（重新采样像素/总像素）。
2. 显存占用公式：CacheSize = LightmapResolution × TexelsPerChunk × ChunkCount × 4 × MipLevels；其中TexelsPerChunk在Unity 2022.2后默认8192，可在LightingSettings.texelsPerChunk脚本调。
3. Chunk划分逻辑：Unity按World-space 16×16×16m网格切分场景，Chunk越多，Cache越大；地形会被强制拆成更大Chunk，需单独降分辨率。
4. 显卡档位建议：
   • RTX 3060 12G：Cache上限4GB，留8G给模型、RTX BVH、后处理，LightmapSize单张不超过2048×2048；
   • RTX 4080 16G：Cache可给8-10GB，单张4096×4096，Chunk上限256；
5. CI并发冲突：Library/GPUCache默认全局共享，多开Unity实例会锁Cache；国内厂用Jenkins + -cacheServer时，需在LightingSettings.gpuCachePath指定每节点独立路径，并在构建脚本里rm -rf旧Cache防止脏数据。
6. 版本管理：.gitignore必须加**/GPUCache/**，但要在README里写明重建Cache命令：Unity.exe -quit -batchmode -executeMethod BuildTool.RebuildGPUCache。

答案

分三步落地：

1. 量化预算：根据目标显卡与场景大小，用公式反推最大Chunk数。举例：RTX 3060 12G场景，单张Lightmap 2048×2048，Mip=3，TexelsPerChunk=8192，则ChunkCountMax = 4GB / (2048×2048×4×3) ≈ 83；在LightingSettings.maxChunkCount里写死83，防止美术手滑。
2. 分块策略：地形单独LightmapParameters分辨率降50%，ClusterResolution降到0.3，减少Chunk；室内静态物件打组后用LightmapStatic合并Mesh，降低Chunk总量。
3. CI隔离：Jenkins Pipeline里加export UNITY_GPUCACHE_PATH=$WORKSPACE/GPUCache_$BUILD_NUMBER，并在构建完成后tar -zcf gpu_cache_$BUILD_NUMBER.tar.gz $UNITY_GPUCACHE_PATH上传Artifactory，供下次增量烘焙；同时LightingSettings.enableGPUCacheCompression=true打开Cache压缩，省30%空间。

一句话总结：先算显存、再限Chunk、最后CI隔离，让RTX Cache既快又不爆显存。

拓展思考

1. DLSS 3.0 Frame Generation与GPU Lightmapper同时跑时，显存带宽被双倍占用，需把CacheSize再降20%并开Resizable BAR。
2. Unity 2023.2开始支持GPU Out-of-Core Baking，可把Cache分页到SSD，但国内NVMe TLC盘连续写寿命有限，建议Cache路径挂到企业级P5510并定期smartctl检查。
3. 如果项目后期要切URP GPU Progressive，原RTX Cache不能复用，需提前在版本管理里打Tag，双轨维护Legacy Cache与URP Cache，避免美术误用旧Cache导致光照结果偏差。