Mike nous illumina en ce 2008-10-15 12:55 -->
> "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
> 
> 
After rendering over a checker background, what you have described looks 
perfectly normal to me.
We often have a tendency to underestimate the effect of refractions. Considering 
the shape of the surface, and the IOR, any details of the background can appears 
very small, contributing to the buzy aspect.
You say that decreasing the ior can make the spots disapear, whitch confirm my 
point. At some IOR values, you can get infinite paths as a ray get trapped 
inside your object.

adc_bailout works by estimating the contribution of a surface to the aspect of a 
pixel. If that contribution is less than the provided value, that means that the 
current result is "good enough", and thus, it's time to stop looking further. If 
you stop sampling due to adc_bailout triggering, you get the estimates colour at 
that point. It may not be "exact", but it's close enough to that exact value for 
your needs. If you exeede the max_trace_level, you give up and return BLACK.

max_trace_level default to 5, or a total of 5 bounces + refractions + the 
background. When you increase the value, you test more surfaces and have more 
chances of exiting your object. If you don't exit the object soon enough, you 
get black.

If you increase adc_bailout, you may stop evaluating while still inside the 
object, but without returning black.

That way, adc_bailout can get rid of black spots by skipping on the precision.
The default value is 1/256, or about 0.0039. If you make it larger, you tell 
that it's OK to stop evaluating sooner and return the result "up to now".



-- 
Alain
-------------------------------------------------
A pat on the back is only a few centimeters from a kick in the butt.

Post a reply to this message