Re: flickering with zbump

["guillaume laforge" <guillaume.laforge.3d(at)gmail.com>]

Here is my try : http://www.vol2nuit.fr/guillaume/shadersMR/antiNaNs.rar

Put this lens shader on your camera.

I test it only in one scene with a "NaN" problem and it solved it. So it is maybe the good way...

Cheers

-- 
Guillaume Laforge
freelance TD | cg Artist
my new blog ! http://vol2blog.blogspot.com/

On 8/9/06, adrian <adrian.wyer(at)fluid-pictures.com> wrote:

lol, alan is busy enough right now!

Halfy?

a

Adrian Wyer
Fluid Pictures
33 Glasshouse Street
London
W1B 5DG
----- Original Message -----
From: "Halfdan Ingvarsson" < hingvars(at)Softimage.COM>
To: <XSI(at)Softimage.COM>
Sent: Wednesday, August 09, 2006 3:55 PM
Subject: RE: flickering with zbump


> Yes, the answer is technical because that's simply the nature of the
> problem. As much as we'd like to believe we can be shielded from the gory
> technical details of working in 3D, they do have a way of making their way
> up to the surface.
>
> These errors are extremely tricky to track down, which is why I asked
> people to send repro scenes at the bottom of the email. The many repro
> scenes I received because of that email, I used to do a major pass over
> our shader libraries for 5.11 to ensure that this effect would, if not
> eliminated, at least be minimized. If you still have scenes with black
> spots in XSI 5.11, please send them to either me directly or to
> support(at)softimage.com .
>
> Unfortunately, there are some closed libraries from mental images (notably
> the sub-surface scattering) and/or 3rd parties that we have no control
> over. I've reported what I can to mental images and they've responded with
> some fixes. Others I've tried to pass on to 3rd parties as much as I've
> been able to dig up an email address for them.
>
> In previous versions of mental ray they would convert the NaNs to
> red/white samples (depending on version) which would then get filtered
> into the final pixel. They would then show up as weird flickering in the
> image. Now they simply let the NaNs go all the way to the filtering stage
> which is why we now get black spots instead (the bigger your filter size,
> the larger the black spots).
>
> I'm sure some kind soul could whip up a camera shader that simply throws
> away those NaN samples. It would overall slow your renders but at least
> you wouldn't end up with black spots. Alan?
>
> - ½
>
> -----Original Message-----
> From: owner-xsi(at)Softimage.COM [mailto: owner-xsi(at)Softimage.COM] On Behalf
> Of Kris Rivel
> Sent: Wednesday, August 09, 2006 10:30 AM
> To: XSI(at)Softimage.COM
> Subject: Re: flickering with zbump
>
> Well that answers nothing for me or the typical artist.  I'm not going
> to build my render tree thinking about NaN values or floating point
> inaccuracies.  I understand it somewhat but the everyday artist probably
> won't.  My biggest problem was that these never appeared in previous
> releases so I'm thinking its either the latest version of MR or a recent
> version of XSI that is the culprit.  It just happens way too often in my
> opinion.
>
> Kris
>
> Bernard Lebel wrote:
>> 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
>>
>>
>
> ---
> 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