glTF 颜色填 128 反而发白，怎样核对线性因子与 sRGB 贴图

glTF的baseColorFactor使用线性颜色分量，范围为0到1；baseColorTexture的RGB则按sRGB解释。把8位颜色128直接填入factor既超范围，除以255后直接作为线性中灰也会比正确的sRGB转线性结果更亮。必须区分颜色来自贴图还是数值因子，避免重复或遗漏色彩转换。

环境和证据范围

本文只计算sRGB通道到线性分量与factor范围，不校准显示器、投影机或现场光照。附件采用8位中灰128，alpha按独立线性标量处理，不做sRGB转换。渲染还受材质、灯光、曝光与色调映射影响，不能用屏幕截图反推一个factor必定错误。

核对顺序

1. 先标记数据来源：图像纹理字节、设计色号还是glTF数值factor。baseColorTexture的RGB已经有sRGB语义，加载器通常负责相应转换；不要再手工修改贴图字节后让加载器转换第二次。

2. 若要把设计sRGB色值写成线性factor，先将8位值除以255得到c，再按sRGB分段函数转换。c<=0.04045时为c/12.92，否则为((c+0.055)/1.055)^2.4。

3. 检查factor每个分量在0到1之间，alpha也单独核对。数值128不能作为合法factor；0.50196作为线性值虽在范围内，却不等价于sRGB字节128，范围校验不能取代语义校验。

4. 在目标引擎中用可控材质与光照核对数据流，记录纹理色彩空间、factor、输出色彩空间和色调映射。不要把环境光变化造成的亮度差全归到颜色编码，也不通过盲调曝光掩盖数据错误。

可复算的输入与预期

128/255约为0.501961，对应线性分量约0.215861。附件同时输出factor=[128,128,128,1]不合法，factor=[0.501961,…,1]在范围内但代表另一线性颜色。脚本使用分段公式实际计算；它不渲染、不测色差，也不提供实际屏幕亮度保证。

下载与现场记录

下载本题合成输入与预期JSON、离线只读核验脚本和现场空白记录CSV。放在同一目录，用 Python 3 运行 python verify.py，逐项计算或解析后与预期比较，失败会显示差异。

现场字段包括 color_source、texture_color_space、srgb_bytes、linear_factor、alpha、tone_mapping、engine_evidence。合成样例保持原样，实测另存并填写型号、版本、证据路径，未采集处留空。本地核验不代表真实设备、代理、浏览器或长期稳定性已测。

失败分支与移交

线性颜色值不等于“颜色看起来更暗”的简单经验规则，渲染器输出还会编码回显示色彩空间。法线贴图、金属度或粗糙度等数据纹理也不能随意按sRGB转换，应按各属性语义处理。遇到发白时先检查通道和转换位置，再做灯光与曝光排查。

移交时保留原色值来源、转换公式、factor和贴图色彩标记，不只留下一个没有来源的RGB数组。真实现场需要目标引擎与显示链路的独立视觉验收，本页只核对glTF颜色数据语义，未验证任何投影融合或屏幕校准结果。

基础背景可看三维场景性能优化：先诊断瓶颈，再谈面数、LOD、实例化与 Draw Call。贴图与因子之前，顶点颜色字节布局也可核对glTF 顶点读出来隔一个错一个，怎样检查 accessor 步长与偏移。更多资料在数字孪生技术方案。

需要项目联调时，可按上述字段整理资料，联系企服君核对实际接入范围。

一级资料

• 官方资料：§3.9材质baseColorFactor为线性、baseColorTexture为sRGB

核对日期：2026-10-24。规范定义与本文应用约定分开，示例门限及脚本不自动代表产品原生能力。