如何解决使用与输入和输出相同的纹理渲染到自定义FrameBuffer
ShaderToy中的某些片段着色器(例如,流体动力学,https://www.shadertoy.com/view/4tGfDW)使用与输入和输出相同的缓冲区。但是,当我尝试在C / C ++代码中执行此操作时,它不起作用(我渲染了奇怪的棋盘工件,例如视觉内存不一致)。要解决此问题,我必须使用两个不同的FrameBuffers A,B和翻转纹理(首先将A渲染为B,然后将B渲染回A)
我了解由于内存一致性问题,OpenGL不允许将相同的纹理用作输入和输出(?)。 但是,有没有比使用两个FrameBuffers更优雅的解决方案了?例如。使用一些锁或临时缓存(我不知道一些同步标志可以解决此问题)?
编辑-回答评论/问题的详细信息:
OpenGL(取决于GL版本)对于某些内容有一些非常具体的规则 使用相同的纹理作为渲染目标时,可以也不能完成 和采样器输入。如果您的用例可以在此范围内实现 是否要求不明确,因为您还没有解释什么 正是您需要或想要在这里做。
基本上我想实现流体动力学求解器(例如上面链接的ShaderToy的求解器)以及其他偏微分方程求解器。这意味着每个像素输出取决于相邻像素的某个卷积蒙版(导数,拉普拉斯算术平均值)。可能还会有一些移动(平流),这意味着读取值形成了较远的像素。
目前,我意识到伪影主要出现在我读取/写入不同位置的像素时-即它是非局部的(例如,pixel [100,100]取决于pixel [10,10])
Shadertoy的简单流体求解器示例:
vec4 solveFluid(sampler2D smp,vec2 uv,vec2 w,float time,vec3 mouse,vec3 lastMouse)
{
const float K = 0.2;
const float v = 0.55;
vec4 data = textureLod(smp,uv,0.0);
vec4 tr = textureLod(smp,uv + vec2(w.x,0),0.0);
vec4 tl = textureLod(smp,uv - vec2(w.x,0.0);
vec4 tu = textureLod(smp,uv + vec2(0,w.y),0.0);
vec4 td = textureLod(smp,uv - vec2(0,0.0);
vec3 dx = (tr.xyz - tl.xyz)*0.5;
vec3 dy = (tu.xyz - td.xyz)*0.5;
vec2 densDif = vec2(dx.z,dy.z);
data.z -= dt*dot(vec3(densDif,dx.x + dy.y),data.xyz); //density
vec2 laplacian = tu.xy + td.xy + tr.xy + tl.xy - 4.0*data.xy;
vec2 viscForce = vec2(v)*laplacian;
data.xyw = textureLod(smp,uv - dt*data.xy*w,0.).xyw; //advection
vec2 newForce = vec2(0);
data.xy += dt*(viscForce.xy - K/dt*densDif + newForce); //update velocity
data.xy = max(vec2(0),abs(data.xy)-1e-4)*sign(data.xy); //linear velocity decay
#ifdef USE_VORTICITY_CONFINEMENT
data.w = (tr.y - tl.y - tu.x + td.x);
vec2 vort = vec2(abs(tu.w) - abs(td.w),abs(tl.w) - abs(tr.w));
vort *= VORTICITY_AMOUNT/length(vort + 1e-9)*data.w;
data.xy += vort;
#endif
data.y *= smoothstep(.5,.48,abs(uv.y-0.5)); //Boundaries
data = clamp(data,vec4(vec2(-10),0.5,-10.),vec4(vec2(10),3.0,10.));
return data;
}
解决方法
目前,我意识到伪影主要出现在我读取/写入不同位置的像素时-即它是非局部的(例如,pixel [100,100]取决于pixel [10,10])
是的,这在GPU上永远都行不通,因为对各个片段着色器调用的顺序没有任何特别的保证。因此,如果写入像素[100,100]
的调用将看到写入[10,10]
的调用的结果,否则原始数据将是完全随机的。根据规范,在这种并发的读/写方案中读取时会得到未定义的值,因此从理论上讲,您可能不会获得一个或另一个,但会看到部分写入或完全不同的值(尽管这种情况不太可能发生)在现实世界的硬件上)。
任何这样规模的订单保证在渲染管道中根本就没有意义,因此也没有手动添加的特定同步手段来解决此问题。
要解决此问题,我必须使用两个不同的FrameBuffers A,B和翻转纹理(首先将A渲染为B,然后将B渲染回A)
是的,对于这种用例,应该采用乒乓球方法。老实说,在那种情况下它都不会造成任何显着的性能损失,因为您似乎无论如何都要写入每个输出像素一次,因此您不需要额外的“未触及”像素副本。因此,所有这些都是额外的内存。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。