为什么我的光线追踪器不能重新创建“坐骑”?场景?
我正在尝试从 Eric Haines 的标准程序数据库 (SPD),但折射部分就是不想合作。我已经尝试了所有我能想到的方法来修复它。
这是我的渲染(使用瓦特公式):
(来源:philosoraptor.co.za)
这是我使用“正常”公式的渲染:
(来源:philosoraptor.co.za)
这是正确的渲染:
(来源:philosoraptor.co.za)
您所看到的,只有几个错误,主要是在球体的两极周围。这让我认为应该归咎于折射或某些精度误差。
请注意,场景中实际上有 4 个球体,它们的 NFF 定义(s x_coord y_coord z_coord radius
)为:
s -0.8 0.8 1.20821 0.17
s -0.661196 0.661196 0.930598 0.17
s -0.749194 0.98961 0.930598 0.17
s -0.98961 0.749194 0.930598 0.17
也就是说,在前景中更明显的三个球体后面还有第四个球体。从这三个球体之间留下的间隙可以看出。
这是第四个球体的图片:
(来源:philosoraptor.co.za)
这是第一个球体的图片:
(来源:philosoraptor.co.za)
您会注意到我的版本和正确版本中都缺少许多奇怪的地方。我们可以得出结论,这些效应是球体之间相互作用的结果,问题是哪种相互作用?
我做错了什么?以下是我已经考虑过的一些潜在错误:
- 折射矢量公式。
据我所知,这是正确的。这与几个网站使用的公式相同,我亲自验证了推导过程。我的计算方法如下:
double sinI2 = eta * eta * (1.0f - cosI * cosI);
矢量传输 = (v * eta) + (n * (eta * cosI - sqrt(1.0f - sinI2)));
transmit = Transmission.normalise();
我在 3D 计算机中找到了替代公式图形,第三版,艾伦·瓦特 (Alan Watt)。它给出了更接近正确图像的近似值:
double etaSq = eta * eta;
double sinI2 = etaSq * (1.0f - cosI * cosI);
Vector transmit = (v * eta) + (n * (eta * cosI - (sqrt(1.0f - sinI2) / etaSq)));
transmit = transmit.normalise();
唯一的区别是我最后除以 eta^2。
- 全内部反射。
我对此进行了测试,在交叉点代码的其余部分之前使用以下条件:
if (sinI2 <= 1)
- 计算 eta。
我使用类似堆栈的方法来解决此问题:
/* Entering object. */
if (r.normal.dot(r.dir) < 0)
{
double eta1 = r.iorStack.back();
double eta2 = m.ior;
eta = eta1 / eta2;
r.iorStack.push_back(eta2);
}
/* Exiting object. */
else
{
double eta1 = r.iorStack.back();
r.iorStack.pop_back();
double eta2 = r.iorStack.back();
eta = eta1 / eta2;
}
正如您所看到的,这会将包含该射线的先前对象存储在堆栈中。退出时,代码会将当前 IOR 从堆栈中弹出,并使用它及其下的 IOR 来计算 eta。据我所知,这是最正确的方法。
这适用于嵌套传输对象。然而,对于相交的传输对象,它会崩溃。这里的问题是您需要独立定义交集的 IOR,而 NFF 文件格式则无法做到这一点。目前尚不清楚“正确”的行动方针是什么。
- 移动新光线的原点。
新光线的原点必须沿着传输路径稍微移动,以便它不会与前一光线相交在同一点。
p = r.intersection + transmit * 0.0001f;
p += Transmission * 0.01f;
我尝试过将该值变小(0.001f)和(0.0001f),但这会使球体看起来是实心的。我想这些值不会将光线移动到距前一个交点足够远的位置。
编辑:这里的问题是反射代码正在做同样的事情。因此,当物体同时具有反射性和折射性时,光线的来源最终会出现在完全错误的位置。
- 光线反弹量。
我人为地将光线反弹量限制为 4。我测试将此限制提高到 10,但这并没有解决问题。
- 法线。
我很确定我正确计算了球体的法线。我取交点,减去球体的中心,然后除以半径。
I'm trying to render the "mount" scene from Eric Haines' Standard Procedural Database (SPD), but the refraction part just doesn't want to co-operate. I've tried everything I can think of to fix it.
This one is my render (with Watt's formula):
(source: philosoraptor.co.za)
This is my render using the "normal" formula:
(source: philosoraptor.co.za)
And this one is the correct render:
(source: philosoraptor.co.za)
As you can see, there are only a couple of errors, mostly around the poles of the spheres. This makes me think that refraction, or some precision error is to blame.
Please note that there are actually 4 spheres in the scene, their NFF definitions (s x_coord y_coord z_coord radius
) are:
s -0.8 0.8 1.20821 0.17
s -0.661196 0.661196 0.930598 0.17
s -0.749194 0.98961 0.930598 0.17
s -0.98961 0.749194 0.930598 0.17
That is, there is a fourth sphere behind the more obvious three in the foreground. It can be seen in the gap left between these three spheres.
Here is a picture of that fourth sphere alone:
(source: philosoraptor.co.za)
And here is a picture of the first sphere alone:
(source: philosoraptor.co.za)
You'll notice that many of the oddities present in both my version and the correct version is missing. We can conclude that these effects are the result of interactions between the spheres, the question is which interactions?
What am I doing wrong? Below are some of the potential errors I've already considered:
- Refraction vector formula.
As far as I can tell, this is correct. It's the same formula used by several websites and I verified the derivation personally. Here's how I calculate it:
double sinI2 = eta * eta * (1.0f - cosI * cosI);
Vector transmit = (v * eta) + (n * (eta * cosI - sqrt(1.0f - sinI2)));
transmit = transmit.normalise();
I found an alternate formula in 3D Computer Graphics, 3rd Ed by Alan Watt. It gives a closer approximation to the correct image:
double etaSq = eta * eta;
double sinI2 = etaSq * (1.0f - cosI * cosI);
Vector transmit = (v * eta) + (n * (eta * cosI - (sqrt(1.0f - sinI2) / etaSq)));
transmit = transmit.normalise();
The only difference is that I'm dividing by eta^2 at the end.
- Total internal reflection.
I tested for this, using the following conditional before the rest of my intersection code:
if (sinI2 <= 1)
- Calculation of eta.
I use a stack-like approach for this problem:
/* Entering object. */
if (r.normal.dot(r.dir) < 0)
{
double eta1 = r.iorStack.back();
double eta2 = m.ior;
eta = eta1 / eta2;
r.iorStack.push_back(eta2);
}
/* Exiting object. */
else
{
double eta1 = r.iorStack.back();
r.iorStack.pop_back();
double eta2 = r.iorStack.back();
eta = eta1 / eta2;
}
As you can see, this stores the previous objects that contained this ray in a stack. When exiting the code pops the current IOR off the stack and uses that, along with the IOR under it to compute eta. As far as I know this is the most correct way to do it.
This works for nested transmitting objects. However, it breaks down for intersecting transmitting objects. The problem here is that you need to define the IOR for the intersection independently, which the NFF file format does not do. It's unclear then, what the "correct" course of action is.
- Moving the new ray's origin.
The new ray's origin has to be moved slightly along the transmitted path so that it doesn't intersect at the same point as the previous one.
p = r.intersection + transmit * 0.0001f;
p += transmit * 0.01f;
I've tried making this value smaller (0.001f) and (0.0001f) but that makes the spheres appear solid. I guess these values don't move the rays far enough away from the previous intersection point.
EDIT: The problem here was that the reflection code was doing the same thing. So when an object is reflective as well as refractive then the origin of the ray ends up in completely the wrong place.
- Amount of ray bounces.
I've artificially limited the amount of ray bounces to 4. I tested raising this limit to 10, but that didn't fix the problem.
- Normals.
I'm pretty sure I'm calculating the normals of the spheres correctly. I take the intersection point, subtract the centre of the sphere and divide by the radius.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
只是基于图像差异的猜测(并且没有阅读问题的其余部分)。在我看来,问题出在球体背面的折射。您可能会:
检查这一点的一种方法是通过几乎面向相机的立方体查看安装座。如果折射正确,图片应该稍微偏移,但其他方面不会改变。如果不正确,那么图片会显得稍微倾斜。
Just a guess based on doing a image diff (and without reading the rest of your question). The problem looks to me to be the refraction on the back side of the sphere. You might be:
One way to check for this would be to look at the mount through a cube that is almost facing the camera. If the refraction is correct, the picture should be offset slightly but otherwise un-altered. If it's not right, then the picture will seem slightly tilted.
经过一年多的时间,我终于明白了这是怎么回事。头脑清醒等等。我完全偏离了这个公式。我现在使用赫克伯特的公式,我确信它是正确的,因为我自己使用几何和离散数学证明了它。
下面是正确的向量计算:
在上面的代码中,eta 是 eta1(光线发出表面的 IOR)除以 eta2(目标表面的 IOR),v 是入射光线,n 是法线。
还有一个问题,让问题更加混乱了。退出对象时,我必须翻转正常(这很明显 - 我错过了它,因为其他错误掩盖了它)。
最后,我的视线算法(确定表面是否被点光源照亮)没有正确穿过透明表面。
现在我的图像正确排列了:)
So after more than I year, I finally figured out what was going on here. Clear minds and all that. I was completely off track with the formula. I'm instead using a formula by Heckbert now, which I am sure is correct because I proved it myself using geometry and discrete math.
Here's the correct vector calculation:
In the code above, eta is eta1 (the IOR of the surface from which the ray is coming) over eta2 (the IOR of the destination surface), v is the incident ray and n is the normal.
There was another problem, which confused the problem some more. I had to flip the normal when exiting an object (which is obvious - I missed it because the other errors were obscuring it).
Lastly, my line of sight algorithm (to determine whether a surface is illuminated by a point light source) was not properly passing through transparent surfaces.
So now my images line up properly :)