Re: flickering with zbump

["adrian" <adrian.wyer(at)fluid-pictures.com>]

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