"Mike" <win### [at] hotmailcom> wrote:
> Alain <ele### [at] netscapenet> wrote:
> > Mike nous illumina en ce 2008-10-13 13:37 -->
> > > Actually, I just tried it with photons on and it did not get rid of the
> > > speckles.  Also, I do not think the speckles are from the egg crate pattern
> > > since the frequency is too small and since this program does not seem to take
> > > into account interference of waves, I don't think it would be possible to have
> > > such a small frequency developing.  The reason I am being such a stickler with
> > > this is that I plan on using this for visualizing an experiment and we would at
> > > least try to minimize artifacts as much as possible.
> > >
> > > -Mike
> > >
> > >
> > >
> > >
> > > "Cousin Ricky" <ric### [at] yahoocom> wrote:
> > >> "Mike" <win### [at] hotmailcom> wrote:
> > >>>   My problem is that when I try to
> > >>> merge the two objects I create, I have tried merge and union I always see a
> > >>> middle boundary in between them.  The indicies of refraction are matched and I
> > >>> am using fresnel reflection, so I do not see how or why I am seeing this.  If
> > >>> anyone has any ideas on how to make this artifact go away that would be very
> > >>> helpful.  I have posted the code I used to make the object below.
> > >> This looks like a coincident surface problem.  Usually this shows up as
> > >> speckles, but in your case it appears to have obliterated both surfaces.
> > >>
> > >> The quick solution would have been to change the 3.2 to 3.4999 so that the
> > >> overlap area is only 0.0001--but that didn't eliminate the problem for me; it
> > >> only made it thinner.
> > >>
> > >> But I like Mike Williams's solution better anyway.  The cast spots seem to be
> > >> from the egg-carton topology, although I can't think of why that would be.  But
> > >> once you turn on photons, they'll refract into a spotted pattern anyway, so I
> > >> wouldn't worry about them.
> > >
> > >
> > >
> > >
> > What can explain the speckling is multiple total internal reflections. At one
> > pixel, you may have only a few, but the next pixel may need a max_trace_level
> > near the maximum of 255.
> > Have you tried increasing adc_bailout? It limit the number on reflection and
> > refractions based on the effective contribution to the colour returned by a ray.
> > In some cases, it won't change a thing, in others, it can greatly help, and in
> > still other, it may not be acceptable. Only experimentation can tell you if it's
> > acceptable in a specific case.
> >
> > In some cases, adding "all_intersections" can help.
> >
> > --
> > Alain
> > -------------------------------------------------
> >    My wife is such a bad cook, in my house we pray after the meal.
> >     Rodney Dangerfield
>
>
> So, I tried both adding all_intersections, playing with adc_bailout (seems like
> I should make it smaller to decrease the error it permits before "giving up"),
> and I played with the max_trace. All of this did not fix it.  Actually, I
> looked online and found someone who might have fixed the problem.
> http://www.triplespark.net/render/povray/patches/isoacc-patch/
> They edit isosurf.cpp.  I am not sure how to do this, I am using MegaPov on an
> intel mac.
>
> -Mike



I tried the patch and it does not seem to do much else besides speeding up the
processing time (It uses a better root finding algorithm).  Actually, I notice
that if I lower the refractive index of my material the black dots go away, so
it definitely is a total internal reflection thing.  Also, it seems that by
turning off adc_bailout (seting equal to 0 ) and messing with the
max_trace_level I can make less black dots appear.  However, I have yet to be
able to make max_trace_level equal to 255 with adc_bailout off because it takes
too long to render.  Maybe I do not fully understand how adc_bailout works, it
seems if I make it really small I get no change from if I have it not there at
all (the default value).  Any ideas.

-Mike

Post a reply to this message