天文软件的 GL 版本鸿沟

【踩坑实录】天文软件的 GL 版本鸿沟

▍现象
天文软件工程的编译开关逐一实证阶段：一个可视化子功能（联动另一天文软件的实景天空模拟）始终点不亮——它的渲染代码硬性要求桌面 OpenGL 3.3，而设备图形栈是 GLES 3 体系。GL 版本鸿沟：不是代码写错，是两个图形世界的版本号不通约。

▍定位过程
工程把全部可选能力逐一开关验证（这是该工程方法论的一部分）：脚本引擎通过补编依赖点亮；表格导出链路补编验证通过；而这个实景模拟子功能评估后定性为不可行——上游硬依赖桌面 GL 3.3 的渲染体系，没有 GLES 路径。翻译层（gl4es）理论上能桥一部分，但该功能的着色器复杂度（大气散射级）在翻译路径的稳定性不看好。工程的处置干净利落：定性不可行、登记、关闭开关、继续别的。

▍另一条路线的对照
同一个工程的主体渲染反而是另一番景象：天文软件的主渲染代码用 Qt 的 GL 包装层写，构建选 GLES 3 配置后直连设备驱动，完全不需要翻译层——主体亮、子功能熄，一明一暗正好说明 GL 鸿沟的判定要逐路径做，不能整体下结论。

▍根因
桌面 GL 与 GLES 是分叉后各自演进的体系：版本号、管线形态、着色器方言都有差异。应用代码对某个版本的硬依赖（着色器版本指令、固定管线假设、扩展语义），要么上游有 GLES 分支，要么翻译层能桥，要么不可行——三选一的判定逐个功能做。

▍对策
能力开关的分档决策（可行就点亮、依赖太重就登记延期、硬依赖不可桥就定性关闭——三档都要有明确登记，含证据）；不可行结论写明原因（版本鸿沟的具体点——后续翻译层或上游演进时可重评）。

▍方法论沉淀
编译开关逐一实证：每个可选能力单独开关构建加真机验证，结论登记。这比一把全开的撞大法慢，但每格结论都有证据——天文工程的开关实证表是同类工程的模板。

GL 版本鸿沟的完整判定记录在天文工程实录，apps 板块 56 篇欢迎对照。