Halfdan actually answered that question on the mr list:
"It's a combination of mental ray, the shader libraries and floating
point inaccuracy.
A shader returns NaN (not a number) value which overwhelms any other
value in the array of samples which are filtered down to a pixel. If
you increase your filter size, for example, the black spots get
bigger.
When a NaN is converted to 8- or 16-bit value, the conversion function
returns zero, which is why you see black spots. If you save the image
out as float, the NaN values will be saved out with it.
This is usually caused by a shader passing a negative value to sqrt().
A simple example:
nd = mi_vector_dot( &state->dir, &state->normal );
val = sqrt( 1.0f - nd );
Under some circumstances, even if both state->normal and state->dir
are a supposedly unit vectors, the dot product can give a value
slightly larger than 1.0, due to floating point inaccuracies. This
then gets inverted and passed as a very small negative number to
sqrt() which then returns a NaN. This NaN value then proceeds to
contaminate any and all calculations it is involved with downstream.
http://en.wikipedia.org/wiki/NaN
These kinds of errors are very often highly non-trivial to uncover. My
recommendation is to talk to your vendor. The more examples they get,
the easier it is to track these things down."
Cheers
Bernard
On 8/9/06, Kris Rivel <kris(at)krisrivel.com> wrote:
What's with those damn black artifacts? Can anyone at Soft give a
clear
explanation of the problem and maybe put as at ease and tell us it
will be
fixed in the next release. It happens way too often and there
doesn't seem
to be a clear repro for it. I know I've submitted some nasty scene
files to
illustrate it. The problem is that its somewhat random but seems to
happen
often when using OpenEXR, HDRI or shaders like zbump or dark tree. I
had it
pop up again on a job where I was using an OpenEXR image as an
environment
for reflections. I got lots of the little buggers so I converted it
to HDRI
and it worked fine. It just happens a bit too often I think. If its
an MR
thing, we need to bash their heads in a bit to address the problem.
Kris
kim aldis wrote:
Didn't the new version fix that?
-----Original Message-----
From: owner-xsi(at)Softimage.COM [mailto:owner-xsi(at)Softimage.COM] On
Behalf Of adrian
Sent: 09 August 2006 12:20
To: XSI(at)Softimage.COM
Subject: Re: flickering with zbump
we had issues with this, but it manifested itself as 2x2 or 4x4 pixel
black squares.....
resolved by lowering the bump factor, or some convoluted rendertree
chicanery to stop zbump returning NAN values
not much help i know
a
Adrian Wyer
Fluid Pictures
33 Glasshouse Street
London
W1B 5DG
----- Original Message -----
From: "Chris Marshall" <chris(at)eclipsecreative.co.uk>
To: <XSI(at)Softimage.COM>
Sent: Wednesday, August 09, 2006 12:22 PM
Subject: flickering with zbump
Hi All,
Does anyone get flickering problems when using zbump?
I've seen it on two jobs now, and it's so bad we've had to go back to
regular bumpmapping, which isn't ideal.
It happens when you have an object breaking through the surface of
the one
using zbump. The flickering occurs around the area where the one
object
penetrates the other.
Anyone seen this or can offer some advice on fixing it?
Thanks
Chris
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in
body:
unsubscribe xsi
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in
body:
unsubscribe xsi
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in
body:
unsubscribe xsi
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in
body:
unsubscribe xsi
