我需要一个 vec4 和一个 float 从顶点着色器传递到几何着色器，然后传递到片段着色器。为了保持统一的唯一性，3 个着色器属于 3 个不同的程序，并且这 3 个着色器被收集在单个程序管道中，并根据需要附加/分离几何着色器。
GL_ARB_separate_shader_object 扩展说:
GLSL has a "rendezvous by name" model for connecting varying output variables to varying input variables of a subsequent shader. With separate shaders, there's no assurance whether a preceding shader will write a given user-defined input varying variable. HLSL9, Cg, and OpenGL assembly extension programs handle this situation by with "rendezvous by API resource" model. In GLSL terms, this means separate GLSL shaders /must/ communicate by built-in varying variables rather than user-defined varying variables.
很好，在顶点和几何着色器中，我使用 gl_FrontColor 作为 vec4，使用 gl_FogFragCoord 作为 float ，通过 gl_FogFragCoord 和 gl_Color 在片段中读取它们。
它有效，很好..但是..我的意思是..拜托，真的吗？
我可以理解这一切背后的基本原理，但对我来说这确实是一个蹩脚的解决方法。 如果不同程序的不同着色器都在同一个程序管道中工作，真的没有其他方法可以使它们相互通信吗？
最佳答案
让我们首先解决这个问题:您在那里读到的内容与该扩展/核心功能并不相符。下面解释了如果它在规范中，它为何不正确，以及为什么该错误行出现在该规范中。
在阅读扩展规范时，请务必注意以下各项之间的区别:
- 规范文本:定义扩展的实际工作方式。这是本文的重点。
- 描述性文本:这提供了功能用途的非约束性概述。它不具有约束力，这意味着实际的规范性文本可能与其相反。
- 元文本:解释规范文本背后的推理。它还表示页眉和页脚信息(扩展程序的编写者、发布日期等)。
扩展的描述性文本由“概述”部分组成。
规范性文本(解释其全部工作原理的部分)由“新程序和功能”、“新 token ”部分以及表格的任何部分“对...规范的添加/更改”定义.
其他一切都是元文本。但尤其是“问题”部分。该部分解释了规范中做出的决定背后的一些原因。您引用的内容来自“问题”部分。它不具有约束力，因此与实际功能无关。
现在，您可能想知道在这种情况下决策背后的推理怎么可能是错误的。为什么“问题”部分会对扩展内容做出明显错误的事实声明？
好吧，这可以追溯到有关此扩展规范的两个事实。
它基于一个名为 GL_EXT_separate_shader_objects 的旧扩展。 。在那个扩展中，上述陈述是正确的。您不能将用户定义的变量与可分离的程序一起使用。这是因为该扩展完全是由 NVIDIA 编写的，他们实际上只是拼凑了一些废话，足以满足某些用户的需求。这不是一个真正的解决方案，更像是一个权宜之计。
ARB 在将此扩展规范放在一起方面令人震惊地懒惰。这实际上是荒谬的，它是多么懒惰地构建的。例如，第 2 期是从 EXT 版本中逐字复制的，尽管 ARB 版本中引用的部分绝对不正确。
阅读其他一些问题就像深入研究偏执型精神 split 症患者的思想。他们提出其他非事实的主张，然后立即自相矛盾。这就像在 ARB session 或其他 session 上占据擂台边的座位一样。功能(大部分)都很好；扩展规范本身就是垃圾。
我理解你的沮丧。我从扩展中了解功能的一般方法是阅读概述，然后跳到问题。概述让我很好地了解了它应该做什么，问题部分让我很好地了解了实现的样子。所有这些都无需通过“规范语言”进行解析。
您无法使用此扩展程序执行此操作。问题部分比毫无值(value)更糟糕；这是积极的误导。您必须阅读规范语言。
关于opengl - 程序管线着色器变量交换，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8938419/