TinCanMan wrote:
> 
> From what I understand, the ior value comes into play whaent he ray passes
> through a surface, so any time the ray passed through a surface of  either
> sphere, that sphere's ior value would be applied even if the surface is
> inside or intersects another surface.  On the other hand, if you apply a
> 'merge' to these two spheres, the surfaces inside the intersection are
> removed so the image would come out quiet different looking.
> 

But when the spheres are merged a ray on the x-axe coming from -x to +x 
would enter the merge at ior from the the first sphere. But the point where 
it leaves the merge (<3,0,0>) the surface would have a different ior which 
leads to the same problem as described in chapter 6.6.1 when ior was a 
surface property.

Post a reply to this message

Judging with my limited understanding of what is happening, I think it's
quite clear.

As we are talking about a raytracer here, the ior acts directly on the ray,
which hits the object. That is, if the ray hits the object, the angle in
which it travels further is calculated from the current ior and the one of
the object it's hitting. If it hits another object, the same happens. If it
leaves the object the same happens. Ior has no effect if it is constant,
important are those points on the ray where the ior changes.

Now - in your example everything is clear - in overlapping areas the current
ior depends on the object which was hit as the second one. I might be wrong,
though.

Hope that helps and is absolute nonsense,

Marc-Hendrik

"Micha Riser" <mri### [at] gmxnet> schrieb im Newsbeitrag
news:3d3a6e8b@news.povray.org...
> Considering two objects with ovelaping area. Like:
>
> sphere{<-1,0,0>,2 pigment{rgbt 0.8} finish{ior 1.5}}
> sphere{<1,0,0>,2 pigment{rgbt 0.8} finish{ior 1.2}}
>
> How does POV-Ray handle this? In the intersection of the spheres there are
> two ior values defined. Which one does POV use?
>
> - Micha

Post a reply to this message

Micha Riser <mri### [at] gmxnet> wrote in news:3d3aec0d@news.povray.org

> I think we are talking of different things. With 'overlap' I do not
> mean that big parts of the *surface* overlap. Obviously this has
> undefined result. What happens if the objects have a partly common
> interior. Maybe csg intersection is better to make you clear what I
> mean: 
> intersection{
>   box{0,5 interior{ior 1.1}}
>   box{2,6 interior{ior 1.2}}
> }
> This results in a box{2,5} but what ior is used?

hmm... render it and see what's the result :) set one's ior to 1.001 and 
second to ior 2.0

btw. can You pleas NOT quote ENTIRE posts ? 

-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

> But when the spheres are merged a ray on the x-axe coming from -x to +x
> would enter the merge at ior from the the first sphere. But the point
where
> it leaves the merge (<3,0,0>) the surface would have a different ior which
> leads to the same problem as described in chapter 6.6.1 when ior was a
> surface property.
>

See the image I posted in p.b.i.
The camera is orthographic and looking down on 6 sets of two stacked clear
spheres.
1st row: both spheres have an ior of 1.5
2nd row: bottom sphere has ior of 1.5, top sphere has an ior of 2.5
3rd row: bottom sphere has ior of 2.5, top sphere has an ior of 1.5

for each row, the left hand spheres are 'union'ed and the right hand ones
are 'merge'ed

as you can see, no two groups look the same.

-tgq

Post a reply to this message

Rafal 'Raf256' Maj wrote:

> Micha Riser <mri### [at] gmxnet> wrote in news:3d3aec0d@news.povray.org
>> intersection{
>>   box{0,5 interior{ior 1.1}}
>>   box{2,6 interior{ior 1.2}}
>> }
> 
> hmm... render it and see what's the result :) set one's ior to 1.001 and
> second to ior 2.0

Of course I have done test renderings before. But always with spheres so 
far and I have not been able to see what exactly happens. But this box 
example is more interesting. See picture in p.b.i.

IMO it is a bug in POV-Ray. The ray passes through the box and is refracted 
when it leaves it. That means it is refracted even though the ior before 
the hit and after the hit both are 1.0.

To produce consistent results following has to be assured:
- transparent unions with iors are not allowed to overlap
- merge and intersection have to have the same ior within all parts

The first point can hardly be assured at parsing time. It could issue a 
warning during rendering though.
The second point could be checked during parsing.


> 
> btw. can You pleas NOT quote ENTIRE posts ?
> 

Usually I only quote as much as I consider neccessary to understand the 
posting. No need to shout.

- Micha

Post a reply to this message

> IMO it is a bug in POV-Ray. The ray passes through the box and is
refracted
> when it leaves it. That means it is refracted even though the ior before
> the hit and after the hit both are 1.0.

This is not a bug, it is the intended operation as AFAIK.  Even though ior
is specified in 'interior'  it isn't treated as an interior property but
rather acts only on surfaces.  This is whay you can't have ior mapping or
variable iors within a single object.  When a ray passes through a surface
it is refracted according to the iors at that surface.  In your example only
the surface of the intersection that belonged to the box with an ior of 1
has an ior of 1, the other surface has the ior of 1.2 so when the ray hits
this face, with the 1.2 ior, it gets refracted as if the interior had an ior
of 1.2 and the exterior had an ior of 1.

-tgq

Post a reply to this message

TinCanMan wrote:

>> IMO it is a bug in POV-Ray. The ray passes through the box and is
> refracted
>> when it leaves it. That means it is refracted even though the ior before
>> the hit and after the hit both are 1.0.
> 
> This is not a bug, it is the intended operation as AFAIK.  Even though ior
> is specified in 'interior'  it isn't treated as an interior property but
> rather acts only on surfaces.  This is whay you can't have ior mapping or
> variable iors within a single object.  When a ray passes through a surface
> it is refracted according to the iors at that surface.  In your example
> only the surface of the intersection that belonged to the box with an ior
> of 1 has an ior of 1, the other surface has the ior of 1.2 so when the ray
> hits this face, with the 1.2 ior, it gets refracted as if the interior had
> an ior of 1.2 and the exterior had an ior of 1.
> 

I do not think this behavior can be intended.

From the documentation part 6.6.1
"... It is totally illogical to have a ray enter an object with one index 
or refraction and then recalculate with another index. The result is not an 
average of the two ior values. Similarly it makes no sense to have a ray 
enter at one ior and exit at a different ior without transitioning between 
them along the way. ..."

That is the reason why ior was moved from finish to interior. But exactly 
what one wanted to prevent happens with the merges boxes!

Another point to consider is that refraction is directional, so ior A -> 
ior B gives a different result than B -> A. That means it has to be 
distinguished between entering and leaving objects. Now at the back surface 
of the box should the ray be refracted 1.0 -> 1.2 or 1.2 -> 1.0?

Post a reply to this message

> I do not think this behavior can be intended.
>
> From the documentation part 6.6.1
> "... It is totally illogical to have a ray enter an object with one index
> or refraction and then recalculate with another index. The result is not
an
> average of the two ior values. Similarly it makes no sense to have a ray
> enter at one ior and exit at a different ior without transitioning between
> them along the way. ..."
>
Read the next two sentences:
POV-Ray only calculates refraction as the ray enters or leaves. It cannot
incrementally compute a changing ior through the interior of an object.



>
> Another point to consider is that refraction is directional, so ior A ->
> ior B gives a different result than B -> A. That means it has to be
> distinguished between entering and leaving objects. Now at the back
surface
> of the box should the ray be refracted 1.0 -> 1.2 or 1.2 -> 1.0?

1.2 -> 1.0  where the 1.0 is the ior (implied) of the space outside the box
(as opposed to the applied ior 1.0).  The ray is considered leaving this
surface, the suface has an ior of 1.2 going into empty space, ior 1.0,
therefore it would act as though the interior of the object had an ior of
1.2 at this surface.  At the front surface it acts as if the interior has an
ior of 1.0, no refraction.  As stated (though perhaps not as clearly as it
could) in 6.6.1, the ior should vary alng the interior of this object but
that is almost impossible to calculate properly.  Having a CSG object with
different iors on different parts will not produce any kind of realistic
results and I would consider poor coding practice (unless it is intended).
This is just a limitation of POV, not a bug though.

-tgq

Post a reply to this message

TinCanMan wrote:
> 
> 1.2 -> 1.0  where the 1.0 is the ior (implied) of the space outside the
> box
> (as opposed to the applied ior 1.0).  The ray is considered leaving this
> surface, the suface has an ior of 1.2 going into empty space, ior 1.0,
> therefore it would act as though the interior of the object had an ior of
> 1.2 at this surface.  At the front surface it acts as if the interior has
> an
> ior of 1.0, no refraction.  

Okay, like this the refraction is always well defined. But it is rather 
unlogical to refract from 1.2 -> 1.0 even though though the ray has never 
been in space with ior 1.2.

> Having a CSG object with
> different iors on different parts will not produce any kind of realistic
> results and I would consider poor coding practice (unless it is intended).
> This is just a limitation of POV, not a bug though.

Of course, a feature not a bug ;). What has the effort of moving ior from 
finish to interior been worth if it is still possible that a ray enters at 
one ior and leaves at another? IMO at least a warning should be issued.

- Micha

-- 
http://objects.povworld.org - the POV-Ray Objects Collection

Post a reply to this message

> Okay, like this the refraction is always well defined. But it is rather
> unlogical to refract from 1.2 -> 1.0 even though though the ray has never
> been in space with ior 1.2.

But can you tell me conclusively what the interior ior of the intersection
object is, 1.0 or 1.2?  Sort of schrodinger's fridge*.

>
> Of course, a feature not a bug ;). What has the effort of moving ior from
> finish to interior been worth if it is still possible that a ray enters at
> one ior and leaves at another? IMO at least a warning should be issued.
>
I don't know why it was moved other than in reality it is a property of the
interior rather than the surface regardless of how POV treats (calculates)
it.
yes, perhaps it would be helpful for debugging puprose to have POV warn you
when an object has more than one ior applied.

-tgq

*http://angryflower.com/schrod.gif

Post a reply to this message