32 bit machine Vs 64 bit machine.

[Rachit Agrawal]

I have come across this compatibility issue with 'pbrt'. Here are some
of them:

1. When I render the scene killeroo-glossy.pbrt in 32 bit machine I
get

Error: Negative luminance value, -0.0825347, returned for image
sample. Setting to black.

But no such problem with 64 bit machine.

2. Whereas the scene file sibenik.pbrt is rendered in 64 machine I get

Error: Not-a-number radiance value returned for image sample. Setting
to black.

But no such problem with 32 bit machine.

This seem to be some format conversion problem According to the error
I felt the geometry files included in original scene had some problem.
But when I checked them, they all seem to be double value. So I don't
understand, why this conversion will generate such error.

Can someone throw some light on this?

Thanks

[Asbjørn]

On Sep 15, 9:00 am, Rachit Agrawal <rachit86...@yahoo.co.in> wrote:
> Can someone throw some light on this?

Bit hard to say since you don't mention the platform or compiler.
However I'd venture a guess that it has to do with the lack of the FPU
on the Intel x64 platform. This requires the compiler to only use SSE
instructions. On the x86 platform the compiler can use FPU
instructions as well. This means that the code paths may be different,
which could lead to different results (more so when using
optimizations).

Cheers
- Asbjørn

[Rachit Agrawal]

Thanks for your reply.

I have FPU in both the machines x64 and x32 as confirmed by
/proc/cpuinfo output. So, I don't think its the issue with FPU.

The two machines that I am using
1. Machine 1: x86_64, RHEL5, 24-core machine, GCC( 4.1.2 20080704)
2. Machine 2: 32bit, debian 5.0, dual core machine, GCC(4.3.2)

I was looking at the code, following is the code synopsis that is giving error.

Spectrum Ls = 0.f;
if (rayWeight > 0.f)
{
Ls = rayWeight * Li(ray, sample, &alpha);
}
// Issue warning if unexpected radiance value returned


if (Ls.IsNaN()) {
// Machine 1 complains on this
Error("Not-a-number radiance value returned "
"for image sample. Setting to black.");
Ls = Spectrum(0.f);
}


else if (Ls.y() < -1e-5) {
// Machine 2 complains on this
Error("Negative luminance value, %g, returned "
"for image sample. Setting to black.", Ls.y());
Ls = Spectrum(0.f);
}

What else can be the problem?

[Asbjørn]

On Sep 16, 2:03 pm, Rachit Agrawal <rachit.k.agra...@gmail.com> wrote:
> I have FPU in both the machines x64 and x32 as confirmed by
> /proc/cpuinfo output. So, I don't think its the issue with FPU.

That is besides the point. The specifications for the amd x64 platform
(which intel adopted) does not include any FPU instructions. The only
way to do floating-point math on the amd x64 platform is to use SSE.
On the x86 platform, the compiler can use the FPU instructions (in
addition to SSE), and in some cases it's faster to use FPU
instructions than SSE instructions IIRC.

Now, obviously the SSE unit shouldn't be significantly more inaccurate
than the FPU (they're after all mapped to the same silicon in the
end), however the compiler generated code paths (sub-expressions)
might be somewhat different due to this, which would lead to
differences in rounding and similar (especially with options such as /
fp:fast in Visual Studio). This could build up over time, giving
different results in the end.

Of course, the problem could certainly be something completely
different :)

Cheers
- Asbjørn

[Rachit Agrawal]

Thanks Asbjorn. Now I get what you are trying to say. That might be
the problem. But is there a way, that I can confirm that is exactly
the problem.

Here is one more experiment that I did.

I ran the plants-godrays.pbrt scene file. The one provided with the CD
provided in the book. When I ran this code on the 64 bit machine. I
got a segmentation fault. Here is the strack trace of that.

Rendering: [+++++++++++++++++++++++++++ ]
(54.2s|44.2s) Error: Not-a-number radiance value returned for image
sample. Setting to black.
Line 74, file plants-godrays.pbrt

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 182900517632 (LWP 8023)]
SingleScattering::Li (this=0x13ce9aa0, scene=0x1401ebb0,
ray=@0x7fbffcb4a0, sample=Variable "sample" is not available.
) at integrators/single.cpp:64
64 LatinHypercube(samp, N, 3);

(gdb) bt
#0 SingleScattering::Li (this=0x13ce9aa0, scene=0x1401ebb0,
ray=@0x7fbffcb4a0, sample=Variable "sample" is not available.
) at integrators/single.cpp:64
#1 0x00000000004438f6 in Scene::Li (this=0x1401ebb0,
ray=@0x7fbffcb4a0, sample=0x1401ec20, alpha=0x0) at core/scene.cpp:111
#2 0x0000002aa7ae925c in DirectLighting::Li (this=0x13d15440,
scene=0x1401ebb0, ray=@0x7fbffcb920, sample=0x1401ec20, alpha=Variable
"alpha" is not available.
)
at core/color.h:51
#3 0x00000000004438a0 in Scene::Li (this=0x1401ebb0,
ray=@0x7fbffcb920, sample=0x1401ec20, alpha=0x0) at core/scene.cpp:109
#4 0x0000002aa7aea297 in DirectLighting::Li (this=0x13d15440,
scene=0x1401ebb0, ray=@0x7fbffcbda0, sample=0x1401ec20, alpha=Variable
"alpha" is not available.
)
at core/color.h:51
#5 0x00000000004438a0 in Scene::Li (this=0x1401ebb0,
ray=@0x7fbffcbda0, sample=0x1401ec20, alpha=0x0) at core/scene.cpp:109
#6 0x0000002aa7aea297 in DirectLighting::Li (this=0x13d15440,
scene=0x1401ebb0, ray=@0x7fbffcc220, sample=0x1401ec20, alpha=Variable
"alpha" is not available.
)
at core/color.h:51
#7 0x00000000004438a0 in Scene::Li (this=0x1401ebb0,
ray=@0x7fbffcc220, sample=0x1401ec20, alpha=0x0) at core/scene.cpp:109
#8 0x0000002aa7aea297 in DirectLighting::Li (this=0x13d15440,
scene=0x1401ebb0, ray=@0x7fbffcc6a0, sample=0x1401ec20, alpha=Variable
"alpha" is not available.
)
at core/color.h:51
#9 0x00000000004438a0 in Scene::Li (this=0x1401ebb0,
ray=@0x7fbffcc6a0, sample=0x1401ec20, alpha=0x0) at core/scene.cpp:109
#10 0x0000002aa7aea297 in DirectLighting::Li (this=0x13d15440,
scene=0x1401ebb0, ray=@0x7fbffcc9c0, sample=0x1401ec20, alpha=Variable
"alpha" is not available.
)
at core/color.h:51
#11 0x00000000004438a0 in Scene::Li (this=0x1401ebb0,
ray=@0x7fbffcc9c0, sample=0x1401ec20, alpha=0x7fbffcc93c) at
core/scene.cpp:109
#12 0x00000000004444bb in Scene::Render (this=0x1401ebb0) at core/color.h:74
#13 0x0000000000416d26 in pbrtWorldEnd () at core/api.cpp:462
#14 0x0000000000455765 in yyparse () at core/pbrtparse.y:454
#15 0x000000000043a785 in ParseFile (filename=0x7fbffff622
"plants-godrays.pbrt") at core/parser.cpp:32
#16 0x0000000000412fed in main (argc=2, argv=0x7fbffff3d8) at
renderer/pbrt.cpp:33


By looking at the trace, my first guess was that samp would be NULL.
But it is not. I am still looking into it. But to me it seems, pbrt is
do have some problem with x64 machines. And I am using pbrt1.04.

So, is there a way to fix this?

[Asbjørn]

On Sep 16, 11:46 pm, Rachit Agrawal <rachit.k.agra...@gmail.com>
wrote:

> I ran the plants-godrays.pbrt scene file. The one provided with the CD
> provided in the book. When I ran this code on the 64 bit machine. I
> got a segmentation fault. Here is the strack trace of that.

How do you know samp is not NULL, have you checked it? Also, have you
checked to see if t0 and t1 are not infinite (use isinf())? We had
some issues where, due to compiler optimizations, IntersectP would
return true, but t1 would be infinite. Looking at the code, that might
lead to problems. So, if you're using -ffast-math, don't, look here:
http://www.luxrender.net/forum/viewtopic.php?p=18289#p18289

Other than that I don't know. The only 64bit unsafe code I can recall
seeing is in MemoryArena, however it's not something that would be an
issue for normal scenes.

Cheers
- Asbjørn

[Rachit Agrawal]

Hi, Thanks again for the reply.

Yes, samp is not NULL and I had checked it. Cross checked it again
now. And indeed t0 and t1 are infinite. I am not explicitely using
-ffast-math. I am using the default makefile provided along with the
code. And I checked it, it does not have -ffast-math optimization
enabled. Is it possible that on the machine I am trying -ffast -math
is enabled by default? Is there a way to explicitely turn this
optimization off??

Thanks

[Matt Pharr]

Hmm, that'd definitely not good! I will try to spend some time
digging into this in the next day or two. My guess about what's going
on with the stack trace below is that the alloca() call is trying to
allocate more memory than is available on the stack and that memory is
getting stomped on.

Regarding the floating point stuff, it's possible to get different
results from using the regular x86 floating point unit vs the SSE
unit. In particular, regular x86 registers hold 80 bits of precision
for all floating point numbers (while SSE uses 32 for float and 64 for
double). You'd think this precision would be nice, but it's a pain
since if a register gets stored to memory (and down to 32 bits for a
float) and then re-loaded, then in general, it won't have the same
value. This can lead to surprising things happening in code:

float a = (some computaiton);
float b = (some other computation);

if (a < b) {
assert(a < b); // assert may fail if a and or b was stored to
memory and re-loaded
}

But in general I haven't seen issues like that from pbrt. Anyway,
I'll look into all this. For the in progress version 2, I'm pretty
much always working with 64-bit mode and haven't seen any problems,
though this could be due to small bugs fixed along the way. (In
general I've tried to make sure those get back-ported to pbrt v1,
though.)

Anyway, I'll poke around and see what I can figure out.

Thanks,
-matt

[Rachit Agrawal]

Thank you sir, for this insight. It made some points clear. I forgot
to mention one more thing here. N is negative in this case along with
t0 and t1 being negative. I am just attaching the output:

bash-3.00$ ../bin/pbrt plants-godrays.pbrt
pbrt version 1.030 of Sep 17 2009 at 02:36:57
Copyright (c)1998-2007 Matt Pharr and Greg Humphreys.
The source code to pbrt (but *not* the contents of the book) is
covered by the GNU General Public License. See the file COPYING.txt
for the conditions of the license.
Warning: Parameter "scale" not used
Line 30, file plants-godrays.pbrt
Warning: Parameter "scale" not used
Line 30, file plants-godrays.pbrt
Warning: Parameter "premultiplyalpha" not used
Line 74, file plants-godrays.pbrt
Rendering: [++++++++++++++++++++++ ]
(67.1s|82.4s) Error: Not-a-number radiance value returned for image

sample. Setting to black.
Line 74, file plants-godrays.pbrt

Rendering: [+++++++++++++++++++++++ ]
(70.4s|79.6s) Error: Not-a-number radiance value returned for image

sample. Setting to black.
Line 74, file plants-godrays.pbrt

Rendering: [+++++++++++++++++++++++++ ]
(76.6s|73.5s) Error: Not-a-number radiance value returned for image

sample. Setting to black.
Line 74, file plants-godrays.pbrt
Error: Not-a-number radiance value returned for image sample. Setting to black.
Line 74, file plants-godrays.pbrt
Error: Not-a-number radiance value returned for image sample. Setting to black.
Line 74, file plants-godrays.pbrt

Rendering: [++++++++++++++++++++++++++ ]
(79.4s|70.3s) Error: Not-a-number radiance value returned for image

sample. Setting to black.
Line 74, file plants-godrays.pbrt
Error: Not-a-number radiance value returned for image sample. Setting to black.
Line 74, file plants-godrays.pbrt
Error: Not-a-number radiance value returned for image sample. Setting to black.
Line 74, file plants-godrays.pbrt
Error: Not-a-number radiance value returned for image sample. Setting to black.
Line 74, file plants-godrays.pbrt

Rendering: [+++++++++++++++++++++++++++ ]
(82.1s|66.9s) Error: Not-a-number radiance value returned for image

sample. Setting to black.
Line 74, file plants-godrays.pbrt

N is negative:-2147483648 // Printed by me

Segmentation fault

[Matt Pharr]

Success! The short version is that there's a subtle bug in the
specular transmission code that leads to not-a-number values when the
incident ray is in the plane of the refractive object. (This happens
surprisingly often in the plants scene!). I don't know why things
went particularly bad with the 64-bit build, but it's nice that the
long-lurking problem manifested itself more obviously.

I've pushed an updated version of the minor changes up to the git
repository (available from http://github.com/mmp/pbrt-v1/tree). I've
also tarred up everything; grab http://pbrt.org/src/pbrt-1.05-
rc1.tar.gz. (This will eventually turn into the 1.05 release of pbrt.)

Sorry for the bother.. Beyond some added infrastructure for new
assertions to catch such bugs earlier, the main changes are pretty
simple (diffs inline below, FWIW).

Thanks,
-matt

diff --git a/core/reflection.cpp b/core/reflection.cpp
index 8257221..b14eb01 100644
--- a/core/reflection.cpp
+++ b/core/reflection.cpp
@@ -84,7 +84,7 @@ Spectrum FresnelDielectric::Evaluate(float cosi)
const {
swap(ei, et);
// Compute _sint_ using Snell's law
float sint = ei/et * sqrtf(max(0.f, 1.f - cosi*cosi));
- if (sint > 1.) {
+ if (sint >= 1.) {
// Handle total internal reflection
return 1.;
}
@@ -113,7 +113,7 @@ Spectrum SpecularTransmission::Sample_f(const
Vector &wo,
float eta = ei / et;
float sint2 = eta * eta * sini2;
// Handle total internal reflection for transmission
- if (sint2 > 1.) return 0.;
+ if (sint2 >= 1.) return 0.;
float cost = sqrtf(max(0.f, 1.f - sint2));
if (entering) cost = -cost;
float sintOverSini = eta;
diff --git a/core/util.cpp b/core/util.cpp
index cf439c4..0f3f8ec 100644
--- a/core/util.cpp
+++ b/core/util.cpp
@@ -65,7 +65,7 @@ static void processError(const char *format, va_list
args,
fprintf(stderr, "\tLine %d, file %s\n",
line_num,
current_file.c_str());
}
- exit(1);
+ abort();
}
#ifndef WIN32
free(errorBuf);
diff --git a/integrators/directlighting.cpp b/integrators/
directlighting.cpp
index 53ff788..db60f9c 100644
--- a/integrators/directlighting.cpp
+++ b/integrators/directlighting.cpp
@@ -129,7 +129,7 @@ Spectrum DirectLighting::Li(const Scene *scene,
// Trace rays for specular reflection and
refraction
Spectrum f = bsdf->Sample_f(wo, &wi,
BxDFType(BSDF_REFLECTION |
BSDF_SPECULAR));
- if (!f.Black()) {
+ if (!f.Black() && AbsDot(wi, n) > 0.f) {
// Compute ray differential _rd_ for
specular reflection
RayDifferential rd(p, wi);
rd.hasDifferentials = true;
@@ -153,7 +153,7 @@ Spectrum DirectLighting::Li(const Scene *scene,
}
f = bsdf->Sample_f(wo, &wi,
BxDFType(BSDF_TRANSMISSION |
BSDF_SPECULAR));
- if (!f.Black()) {
+ if (!f.Black() && AbsDot(wi, n) > 0.f) {
// Compute ray differential _rd_ for
specular transmission
RayDifferential rd(p, wi);
rd.hasDifferentials = true;
diff --git a/integrators/irradiancecache.cpp b/integrators/
irradiancecache.cpp
index af85eaf..a089554 100644
--- a/integrators/irradiancecache.cpp
+++ b/integrators/irradiancecache.cpp
@@ -136,7 +136,7 @@ Spectrum IrradianceCache::Li(const Scene *scene,
const RayDifferential &ray,
// Trace rays for specular reflection and
refraction
Spectrum f = bsdf->Sample_f(wo, &wi,
BxDFType(BSDF_REFLECTION |
BSDF_SPECULAR));
- if (!f.Black()) {
+ if (!f.Black() && AbsDot(wi, n) > 0.f) {
// Compute ray differential _rd_ for
specular reflection
RayDifferential rd(p, wi);
rd.hasDifferentials = true;
@@ -160,7 +160,7 @@ Spectrum IrradianceCache::Li(const Scene *scene,
const RayDifferential &ray,
}
f = bsdf->Sample_f(wo, &wi,
BxDFType(BSDF_TRANSMISSION |
BSDF_SPECULAR));
- if (!f.Black()) {
+ if (!f.Black() && AbsDot(wi, n) > 0.f) {
// Compute ray differential _rd_ for
specular transmission
RayDifferential rd(p, wi);
rd.hasDifferentials = true;
diff --git a/integrators/photonmap.cpp b/integrators/photonmap.cpp
index 454aa43..0c77c87 100644
--- a/integrators/photonmap.cpp
+++ b/integrators/photonmap.cpp
@@ -367,7 +367,7 @@ Spectrum PhotonIntegrator::Li(const Scene *scene,
// Trace rays for specular reflection and
refraction
Spectrum f = bsdf->Sample_f(wo, &wi,
BxDFType(BSDF_REFLECTION |
BSDF_SPECULAR));
- if (!f.Black()) {
+ if (!f.Black() && AbsDot(wi, n) > 0.f) {
// Compute ray differential _rd_ for
specular reflection
RayDifferential rd(p, wi);
rd.hasDifferentials = true;
@@ -391,7 +391,7 @@ Spectrum PhotonIntegrator::Li(const Scene *scene,
}
f = bsdf->Sample_f(wo, &wi,
BxDFType(BSDF_TRANSMISSION |
BSDF_SPECULAR));
- if (!f.Black()) {
+ if (!f.Black() && AbsDot(wi, n) > 0.f) {
// Compute ray differential _rd_ for
specular transmission
RayDifferential rd(p, wi);
rd.hasDifferentials = true;
diff --git a/integrators/whitted.cpp b/integrators/whitted.cpp
index 7024b89..6a87a16 100644
--- a/integrators/whitted.cpp
+++ b/integrators/whitted.cpp
@@ -83,7 +83,7 @@ Spectrum WhittedIntegrator::Li(const Scene *scene,
// Trace rays for specular reflection and
refraction
Spectrum f = bsdf->Sample_f(wo, &wi,
BxDFType(BSDF_REFLECTION |
BSDF_SPECULAR));
- if (!f.Black()) {
+ if (!f.Black() && AbsDot(wi, n) > 0.f) {
// Compute ray differential _rd_ for
specular reflection
RayDifferential rd(p, wi);
rd.hasDifferentials = true;
@@ -107,7 +107,7 @@ Spectrum WhittedIntegrator::Li(const Scene *scene,
}
f = bsdf->Sample_f(wo, &wi,
BxDFType(BSDF_TRANSMISSION |
BSDF_SPECULAR));
- if (!f.Black()) {
+ if (!f.Black() && AbsDot(wi, n) > 0.f) {
// Compute ray differential _rd_ for
specular transmission
RayDifferential rd(p, wi);
rd.hasDifferentials = true;

[Rachit Agrawal]

Dear sir,

Thank your for that update. It is working for scenes using plants
texture. But then there are other scenes which do have problem still.
One such scene is "sibenik", where the assertion fails. Though this
assertion does not fail in 32 bit machines. Here is the sample output
from the run of this scene.

pbrt version 1.030 of Sep 22 2009 at 10:58:36

Copyright (c)1998-2007 Matt Pharr and Greg Humphreys.
The source code to pbrt (but *not* the contents of the book) is
covered by the GNU General Public License. See the file COPYING.txt
for the conditions of the license.

Warning: Degenerate uv coordinates in triangle mesh. Discarding all uvs.
Line 17199, file geometry/sibenik.pbrt
Warning: Degenerate uv coordinates in triangle mesh. Discarding all uvs.
Line 578151, file geometry/sibenik.pbrt
Warning: Degenerate uv coordinates in triangle mesh. Discarding all uvs.
Line 583562, file geometry/sibenik.pbrt
Warning: Degenerate uv coordinates in triangle mesh. Discarding all uvs.
Line 805006, file geometry/sibenik.pbrt
Rendering: [ ] Fatal
Error: Assertion "!isnan(a)" failed in core/color.h, line 78
Line 41, file sibenik.pbrt
Aborted

Also, scene "killerro-glossy" still has problem in 32 bit machine
regarding negative luminance value though this problem is not there in
64 bit machine.

There are some other warnings like Degenerate uv coordinates in
triangle mesh. Is it because of 64 bit machines as well?

Can you please throw some light on this?

Thanks

[Matt Pharr]

Here's the fix for the sibenik bug. I'll get this up on the github
repository this evening. I'll also do a bunch more tests to see if I
can come up with any more lurking little ones like this.

Thanks,
-mat

diff --git a/core/shape.h b/core/shape.h
index 4416323..7cd0cc0 100644
--- a/core/shape.h
+++ b/core/shape.h
@@ -102,7 +102,7 @@ public:
// Convert light sample weight to solid angle measure
float pdf = DistanceSquared(p, ray(thit)) /
(AbsDot(dgLight.nn, -wi) * Area());
- if (AbsDot(dgLight.nn, -wi) == 0.f) pdf = INFINITY; //
NOBOOK
+ if (AbsDot(dgLight.nn, -wi) == 0.f) pdf = 0.f; // NOBOOK
return pdf;
}
// Shape Public Data