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 message
news:3d3a6e8b@news.povray.org...

> two ior values defined. Which one does POV use?

My 2c.

Since ior is defined in the finish a surface property), the overlap is
irrelavent?

The only place that this would be an issue is on co-incident surfaces, which
are a no-no anyway (for presumably exactly this kind of reason).

Post a reply to this message

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

> 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?

If You have i.e. big box (A) and small (B) placed like :

aaaaa
abbba
abbba
abbba
aaaaa

Then in 'a' area (that is inside of object A) - ior will be as in A object

In 'b' are - with is both inside A and B - AFAIK ior will be like in 'B' - 
because this object is closest to tested points - in other words - ray 
intersect surface of B at last.

in area 'A' ray traveled trought A surface so ior is A
in 'B' tray traveled trought A, and later trought B - and the last value is 
important

If You talk about two _ideal_ same objects in same space like
sphere { 0 1 } and sphere {0 1 } - this will always result errors, not only 
in interior

-- 
#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

Tom Melly <tom### [at] tomandlucouk> wrote:
> Since ior is defined in the finish a surface property), the overlap is
> irrelavent?

  IOR should not be defined in the finish block,
but in the interior block.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Rafal 'Raf256' Maj wrote:

> Micha Riser <mri### [at] gmxnet> wrote in news:3d3a6e8b@news.povray.org
> 
>> 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?
> 
> If You have i.e. big box (A) and small (B) placed like :
> 
> aaaaa
> abbba
> abbba
> abbba
> aaaaa

This case is clear as B is compleatly inside A. But what happens if A and B 
only partly overlap?

> 
> If You talk about two _ideal_ same objects in same space like
> sphere { 0 1 } and sphere {0 1 } - this will always result errors, not
> only in interior
> 

No, that's not was I meant. Look closer at my example scene above.

- Micha

Post a reply to this message

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

> Rafal 'Raf256' Maj wrote:
> 
>> Micha Riser <mri### [at] gmxnet> wrote in news:3d3a6e8b@news.povray.org
>> 
>>> 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?
>> 
>> If You have i.e. big box (A) and small (B) placed like :
>> 
>> aaaaa
>> abbba
>> abbba
>> abbba
>> aaaaa
> 
> This case is clear as B is compleatly inside A. But what happens if A
> and B only partly overlap?

They should not overlap. At least - they can overlap in some not-connected 
points, like sphere { y*0 1 } sphere { y*2 1 }. Point <0,1,0> is inside A 
_OR_ inside B, the result is quite random - it deppends on implementation, 
but if this is 1 separate pint - this artfact probably will not be visible.

If the overlap area is bigger, like
cone { y*0 1 y*1 1 }
cone { y*1 1 y*2 1 }

then area with shape of cone { y*1 1 y*1 1 }will have random artefacts (it 
can be i.e. black pixels)

-- 
#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

"Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote in
news:Xns### [at] 204213191226 

[...]

in other words - any objects in POV intersect, but intersection of objects 
_surfaces_ can lead to errors it some cases (if objects, or it's parts are 
too similar to each other)

-- 
#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

Tom Melly wrote:

> "Micha Riser" <mri### [at] gmxnet> wrote in message
> news:3d3a6e8b@news.povray.org...
> 
>> two ior values defined. Which one does POV use?
> 
> Since ior is defined in the finish a surface property), the overlap is
> irrelavent?

As Warp said ior is a interior property. It is allowed to be specified in 
finish only for backwards compatibility. See chapter 6.6.1 of the 
documentation.

I made some further test with CSG and ior. Obviously there is also a 
problem when objects with different ior ar merged together/intersected. 
Consider:

merge{ // or intersection{
  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}}
}

Note that here ior is specified in finish where it does no longer belong to.
What ior does the resulting object have? Testing showed that POV-Ray uses 
the ior value from the first object that has a finish{ior xy} defined for 
the whole object.

However if I specify ior in interior as

merge{ // or intersection{
  sphere{<-1,0,0>,2 pigment{rgbt 0.8} interior{ior 1}}
  sphere{<1,0,0>,2 pigment{rgbt 0.8} interior{ior 1.2}}
}

I get a different result. I cannot exactly say how POV treats this case 
though... anybody?

- Micha

Post a reply to this message

"Micha Riser" <mri### [at] gmxnet> wrote in message
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?

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.

-tgq

Post a reply to this message

Rafal 'Raf256' Maj wrote:

> Micha Riser <mri### [at] gmxnet> wrote in news:3d3ae686@news.povray.org
> 
>> Rafal 'Raf256' Maj wrote:
>> 
>>> Micha Riser <mri### [at] gmxnet> wrote in news:3d3a6e8b@news.povray.org
>>> 
>>>> 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?
>>> 
>>> If You have i.e. big box (A) and small (B) placed like :
>>> 
>>> aaaaa
>>> abbba
>>> abbba
>>> abbba
>>> aaaaa
>> 
>> This case is clear as B is compleatly inside A. But what happens if A
>> and B only partly overlap?
> 
> They should not overlap. At least - they can overlap in some not-connected
> points, like sphere { y*0 1 } sphere { y*2 1 }. Point <0,1,0> is inside A
> _OR_ inside B, the result is quite random - it deppends on implementation,
> but if this is 1 separate pint - this artfact probably will not be
> visible.
> 
> If the overlap area is bigger, like
> cone { y*0 1 y*1 1 }
> cone { y*1 1 y*2 1 }
> 
> then area with shape of cone { y*1 1 y*1 1 }will have random artefacts (it
> can be i.e. black pixels)
> 

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?

Post a reply to this message

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

"TinCanMan" <Tin### [at] hotmailcom> wrote in
news:3d3b1328@news.povray.org 

>> 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*.

I suggest to make intersection and later apply interior/material to entire 
object.



-- 
#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

In article <3d3b0efd@news.povray.org> , Micha Riser <mri### [at] gmxnet>  wrote:

> 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.

There were reasons and it had been explained when 3.1 was released also I
unfortunately do not recall where (nor do I have the time these days to look
it up).  If it isn't explained anywhere in the (3.1) docs, I would suggest
to find someone who has an archive of the CompuServe Go POVRAY forum...

The way ior works right now is definitely as it should.

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

TinCanMan wrote:

>> 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?  
> 

No, IMO it is not defined (and cannot be defined in a logical and 
consistent way). That is why I think there is something to be changed with 
POV-Ray, e.g. issue a warning.

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

Post a reply to this message

Rafal 'Raf256' Maj wrote:

> I suggest to make intersection and later apply interior/material to entire
> object.

Sure. But I want to test the limits of POV-Ray ;)

The reason why I came up with this question was that I am writing my own 
little ray-tracer and have to find a way to handle refraction with csgs.

So I am not looking from the user's point of view (I want to do X. How do I 
tell the program to do so) but from the programmer's point of view (The 
syntax allows the users to specify X. How should the program interpret this 
to ensure consistency).

- Micha

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

Post a reply to this message

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

> The reason why I came up with this question was that I am writing my
> own little ray-tracer and have to find a way to handle refraction with
> csgs. 

me too :) But it's now - a 2d (!) program - just for testing some 
algorithms. The important thing - it's a photons-tracer not 
[camera]-ray-tracer. So it will work _much_ slower but will implement all 
radiosity (true - with normals, specular etc), caustics etc in natural way.

Maybe some parts of code may be used in POV ? Normaly ray-tracing is 
ofcourse very fast, but after some point of photo-realistics it may be 
better to use photon-tracer, rather then make wark-around's for ray-tracer 
limitations. 


-- 
#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

In article <3d3b1cf6@news.povray.org> , Micha Riser <mri### [at] gmxnet>  wrote:

> So I am not looking from the user's point of view (I want to do X. How do I
> tell the program to do so) but from the programmer's point of view (The
> syntax allows the users to specify X. How should the program interpret this
> to ensure consistency).

That is the wrong approach.  If you look at POV-Ray that way you will always
only run against walls and never get done anything.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> There were reasons and it had been explained when 3.1 was released also I
> unfortunately do not recall where

  I think that one of the most practical reasons for moving ior outside
the texture block is that when it was in the finish block it was possible
to define an ior which changes along the surface of the object (ie.
different parts of the surface have different ior), which gave a physically
completely incorrect result (in reality IOR never changes only in the
surface of an object).

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

In article <3d3b1cf6@news.povray.org>, Micha Riser <mri### [at] gmxnet> 
wrote:

> The reason why I came up with this question was that I am writing my own 
> little ray-tracer and have to find a way to handle refraction with csgs.

Well, the method I'm considering with my own raytracer is to just forbid 
overlapping transparent objects. After a ray enters a shape, the tracer 
will only test against that shape until it exits again. Things will be 
arranged so that each shape only has one material, so it won't enter 
through a surface with one material and exit through one with a 
different material. Non-refracting objects would be exempt from this, it 
would be very undesireable for media containers.

One potential problem: exiting into the interior of a shape that is 
overlapping. I'll probably just ignore this condition, it would be 
impossible to say which object it entered into when several are 
overlapping. It would be possible to check this condition, just check 
the exit point to see if it is inside any other object, but that would 
slow things down. Maybe for a scene debugging mode...

Another odd little trick I've been wanting to try: normally, when you 
hit a surface like glass, you have to trace a refracted ray and a 
reflected ray. With many transparent objects, this can create a lot of 
rays very quickly.
The trick would be to randomly choose refraction or reflection. The rays 
would never "branch", they would just take a random path through all the 
possible paths. You would then take several samples for each pixel, each 
sample would take a different path and you would get a fair 
approximation for the pixel without tracing every single ray. I have no 
idea how well this would actually work, but it seems like an interesting 
idea.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

In article <chr### [at] netplexaussieorg>,
 Christopher James Huff <chr### [at] maccom> wrote:

> Well, the method I'm considering with my own raytracer is to just forbid 
> overlapping transparent objects. After a ray enters a shape, the tracer 
> will only test against that shape until it exits again. Things will be 
> arranged so that each shape only has one material, so it won't enter 
> through a surface with one material and exit through one with a 
> different material. Non-refracting objects would be exempt from this, it 
> would be very undesireable for media containers.

Another problem with this: transparent objects inside other transparent 
objects, like a glass marble in a pool of water. It would also make the 
pool of water more difficult.

I think the only solution is to do something like what POV does and just 
say that partially overlapping objects won't render correctly because it 
is impossible to say what the "correct" way is. A render-time warning 
might be helpful sometimes, but would usually be useless overhead.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

On Sun, 21 Jul 2002 20:28:17 +0200, Micha Riser 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.

Careful what you call a bug.  You seem to be concerned that POV-Ray does 
something unrealistic when you present it with a situation that cannot exist
in reality.  Why is this a problem?

-- 
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbt 1}hollow interior{media{emission T}}finish{
reflection.1}}#end Z(-x-x.2y)Z(-x-x.4x)camera{location z*-10rotate x*90}

Post a reply to this message

Ron Parker wrote:
> 
> Careful what you call a bug.  You seem to be concerned that POV-Ray does
> something unrealistic when you present it with a situation that cannot
> exist
> in reality.  Why is this a problem?
> 

I called it a bug because ior has been moved from finish to interior 
because ior has to be constant in the whole object to prevent that a ray 
enters at one ior and leaves at a different one. But when two object of 
different ior are merged / intersected exactly the same thing happens. 

I see now that overlaping of transparent object in union cannot be checked 
at parsing time and checking it during rendering would things slow down. 
But in the case of merge/intersection a warning at parsing time could be 
issued.

- Micha

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

Post a reply to this message

"Ron Parker" <ron### [at] povrayorg> wrote in message
news:slr### [at] fwicom...
>
> Careful what you call a bug.  You seem to be concerned that POV-Ray does
> something unrealistic when you present it with a situation that cannot exist
> in reality.  Why is this a problem?
>

Something about the above statement, even though I understand it, makes my brain
hurt.

Post a reply to this message

Christopher James Huff wrote:
> 
> Another problem with this: transparent objects inside other transparent
> objects, like a glass marble in a pool of water. It would also make the
> pool of water more difficult.

Well, it could still be done by cutting the space for the marble out of the 
water. But with too many cuts out the performance gain would be lost.

- Micha

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

Post a reply to this message

In article <3d3ed0da@news.povray.org>, Micha Riser <mri### [at] gmxnet> 
wrote:

> I called it a bug because ior has been moved from finish to interior 
> because ior has to be constant in the whole object to prevent that a ray 
> enters at one ior and leaves at a different one. But when two object of 
> different ior are merged / intersected exactly the same thing happens. 

There isn't really any way around that. At least it is an improvement.
One thing that has been bothering me is the "glass of water" type 
situation...I'm not sure POV handles it correctly or how to model it 
correctly.


> I see now that overlaping of transparent object in union cannot be checked 
> at parsing time and checking it during rendering would things slow down. 
> But in the case of merge/intersection a warning at parsing time could be 
> issued.

It is no more possible in those cases than it is in a union. They would 
have to be checked at render time just like unions.
The best you could do is check if the bounding boxes overlap and give a 
"possible overlap" warning if more than one object is transparent, but 
that would happen so often it would be completely useless.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

Christopher James Huff wrote:
> 
> Another odd little trick I've been wanting to try: normally, when you
> hit a surface like glass, you have to trace a refracted ray and a
> reflected ray. With many transparent objects, this can create a lot of
> rays very quickly.
> The trick would be to randomly choose refraction or reflection. The rays
> would never "branch", they would just take a random path through all the
> possible paths. You would then take several samples for each pixel, each
> sample would take a different path and you would get a fair
> approximation for the pixel without tracing every single ray. I have no
> idea how well this would actually work, but it seems like an interesting
> idea.

But how would you combine the sample values to the final value? Average 
would be much too dark. Sum of course depends on the number of samples.. 
One would kinda have to estimate the number of all possible paths by 
measuring the samples trace depth and then mulitplicate the average by that 
number.

- Micha

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

Post a reply to this message

"Micha Riser" <mri### [at] gmxnet> wrote in message
news:3d3ed209@news.povray.org...
> Christopher James Huff wrote:
> >
> > Another problem with this: transparent objects inside other transparent
> > objects, like a glass marble in a pool of water. It would also make the
> > pool of water more difficult.
>
> Well, it could still be done by cutting the space for the marble out of
the
> water. But with too many cuts out the performance gain would be lost.
>
> - Micha

Doing this, you essentially increase the number of surfaces as you can't
have coincidental surfaces.

-tgq

Post a reply to this message

> One thing that has been bothering me is the "glass of water" type
> situation...I'm not sure POV handles it correctly or how to model it
> correctly.
>

Here it is necessary to double up your surfaces so the surface of the water
is slightly outside the surface of the glass. ie, the ray exits the glass
into air and then into the water.  There is no way to avoid increasing the
number of surfaces in this case if you want it to work correctly. For
something completely immersed int the water (or glass for that matter) this
isn't necessary (in case you think this is contradicatory to my previous
post).

-tgq

Post a reply to this message

Christopher James Huff wrote:
> One thing that has been bothering me is the "glass of water" type
> situation...I'm not sure POV handles it correctly or how to model it
> correctly.

AFAIR the discussions about this problem the suggested why to do this is 
make the water overlap the glass. Because leaving a space between will 
cause multiple reflections. However I don't know if the overlaping is 
handled as wished in that case.

>> I see now that overlaping of transparent object in union cannot be
>> checked at parsing time and checking it during rendering would things
>> slow down. But in the case of merge/intersection a warning at parsing
>> time could be issued.
> 
> It is no more possible in those cases than it is in a union. They would
> have to be checked at render time just like unions.
> The best you could do is check if the bounding boxes overlap and give a
> "possible overlap" warning if more than one object is transparent, but
> that would happen so often it would be completely useless.

It is in the nature of merges to overlap.Otherwise you could just as well 
use union. It is even more in the nature of intersection memebers to 
overlap ... otherwise you have a null object. So it would be natural to 
assume at parsing time that merge/intersection do overlap and always issue 
a warning when iors are different.

So forcing merge/intersection to have one single ior would not make the sdl 
weaker because in that case where the merges do not overlap the user should 
have used union anyways.

- Micha


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

Post a reply to this message

TinCanMan wrote:
> 
> Doing this, you essentially increase the number of surfaces as you can't
> have coincidental surfaces.
> 

An alternative would be to allow objects be (compleatly) inside another. So 
that the water object would have a list of its 'internal' objects. Tracing 
ray inside the water would then only test for these interal objects and the 
water container. Outside the water the interal objects would not have to be 
considered.

- Micha

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

Post a reply to this message

In article <3d3ed209@news.povray.org>, Micha Riser <mri### [at] gmxnet> 
wrote:

> > Another problem with this: transparent objects inside other transparent
> > objects, like a glass marble in a pool of water. It would also make the
> > pool of water more difficult.
> 
> Well, it could still be done by cutting the space for the marble out of the 
> water. But with too many cuts out the performance gain would be lost.

It wouldn't be a good solution. The interface between glass and water 
should be a single surface, with two they would have to either overlap 
or leave an air gap to avoid coincident surface problems. Overlap = bad, 
air gap = an entirely different situation from the one being simulated. 
Better to just say that if you are entering the marble you are exiting 
the water. But when you exit the marble, what do you exit into? Could be 
air, could be water...just check to see if the point is still "inside" 
the water object?

If you can guarantee that the marble is completely immersed, a ray could 
just check each surface against the last surface it hit to detect an 
exit, but if it pokes through the surface...similar to the "glass of 
water" situation.

Maybe a new type of "immersion" CSG would be helpful, some kind of 
half-merge: surface A (water) does not exist inside surface B (marble), 
but surface B does exist inside surface A.
immerse {
    FLUID_OBJECT
    IMMERSED_OBJECTS
}

Maybe separate ior entirely from the surfaces...say "this area of space 
has glass ior, this area has water, everything else has air". Whenever a 
surface is hit, check the ior at a tiny distance to each side. I don't 
really like this solution, but I think it would work.

Maybe at the CSG stage, the ior on each side of the surface could be 
computed and saved...

immerse {
    Water
    GlassCup
}

 ___ air ___
|g _|___|_  |
|l| |wat| | |
|a| |er | | |
|s| |___| | |
|s|_______| |
|___________|

A ray entering through the side of the glass and exiting either through 
the water (a) or the other side of the glass (b):
1: Start in air, hit the glass surface.
2: Hit the water surface, ignore because still inside glass object, but 
set "containing medium" to the water object.
3: Hit the glass surface again, exit to containing medium (the water).
4a: Hit the water. It is the containing medium, so exit into the next up 
medium (air).
4b: Hit the glass again, go from containing medium (water) to glass.
5b: Hit the water surface, inside glass so ignore, but exit containing 
medium to next up (air).
6b: Hit the glass surface, exit to containing medium (air).

This would require the immerse CSG, but it would work in every 
(realistic) situation I've thought of.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

In article <3d3edcb6@news.povray.org>, Micha Riser <mri### [at] gmxnet> 
wrote:

> AFAIR the discussions about this problem the suggested why to do this is 
> make the water overlap the glass. Because leaving a space between will 
> cause multiple reflections. However I don't know if the overlaping is 
> handled as wished in that case.

Which is exactly what I was talking about...


> It is in the nature of merges to overlap.Otherwise you could just as well 
> use union. It is even more in the nature of intersection memebers to 
> overlap ... otherwise you have a null object. So it would be natural to 
> assume at parsing time that merge/intersection do overlap and always issue 
> a warning when iors are different.

Ah, I see what you are saying now. That would apply to all non-unions, I 
think. And maybe different amounts of transparency as well as differing 
iors. And a "nowarn" flag to turn off the warnings for those cases where 
it is intentional.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

In article <3d3ed6fa@news.povray.org>, Micha Riser <mri### [at] gmxnet> 
wrote:

> But how would you combine the sample values to the final value? Average 
> would be much too dark. Sum of course depends on the number of samples.. 
> One would kinda have to estimate the number of all possible paths by 
> measuring the samples trace depth and then mulitplicate the average by that 
> number.

The sum should do the job...it would be darker than you would get by 
tracing all the paths, but ideally the paths that are skipped would have 
little contribution anyway. The first few samples are what would really 
determine the color, the "root" of the tree would fill in first, it is 
the furthest branches that would get left out. A simple scaling factor 
could compensate for that, maybe automatically depending on depth.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

In article <3d3eda9b$1@news.povray.org>,
 "TinCanMan" <Tin### [at] hotmailcom> wrote:

> Here it is necessary to double up your surfaces so the surface of the water
> is slightly outside the surface of the glass. ie, the ray exits the glass
> into air and then into the water.  There is no way to avoid increasing the
> number of surfaces in this case if you want it to work correctly. For
> something completely immersed int the water (or glass for that matter) this
> isn't necessary (in case you think this is contradicatory to my previous
> post).

That is a different situation, where the fluid doesn't "wet" the glass 
and a layer of air is trapped between the two. That is a very easy case, 
POV definitely doesn't have any trouble with that one, but water doesn't 
usually do that.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

On Wed, 24 Jul 2002 12:38:17 -0500, Christopher James Huff wrote:
> In article <3d3edcb6@news.povray.org>, Micha Riser <mri### [at] gmxnet> 
> wrote:
> 
>> AFAIR the discussions about this problem the suggested why to do this is 
>> make the water overlap the glass. Because leaving a space between will 
>> cause multiple reflections. However I don't know if the overlaping is 
>> handled as wished in that case.
> 
> Which is exactly what I was talking about...

It's handled correctly except for the very rare case where a ray enters
the water object without leaving the glass object.  If your surfaces are
close enough together, that almost never happens and AA will fix it if it
does.

POV keeps a list of all interiors it's inside, and when it hits another face
that has the same interior, it removes that interior from the list.  If it
wasn't the last interior, though, the IOR doesn't change.  That effectively
makes the glass faces that are inside the water "disappear" from the point
of view of refraction/TIR, though of course any textures will still be 
computed.

-- 
#local R=rgb 99;#local P=R-R;#local F=pigment{gradient x}box{0,1pigment{gradient
y pigment_map{[.5F pigment_map{[.3R][.3F color_map{[.15red 99][.15P]}rotate z*45
translate x]}]#local H=pigment{gradient y color_map{[.5P][.5R]}scale 1/3}[.5F
pigment_map{[.3R][.3H][.7H][.7R]}]}}}camera{location.5-3*z}//only my opinions

Post a reply to this message

In article <slr### [at] fwicom>,
 Ron Parker <ron### [at] povrayorg> wrote:

> It's handled correctly except for the very rare case where a ray enters
> the water object without leaving the glass object.  If your surfaces are
> close enough together, that almost never happens and AA will fix it if it
> does.

You mean where it just skirts the edge of the water object where it 
overlaps but doesn't touch the inner surface of the glass?


> POV keeps a list of all interiors it's inside, and when it hits another face
> that has the same interior, it removes that interior from the list.  If it
> wasn't the last interior, though, the IOR doesn't change.  That effectively
> makes the glass faces that are inside the water "disappear" from the point
> of view of refraction/TIR, though of course any textures will still be 
> computed.

I see...I think. ;-)
Seems slightly similar to my immersion CSG, only ignoring the ior 
instead of removing the entire surface, and quite a bit more general. 
I'll just have to try to implement it for my own tracer, then I'll 
understand it completely.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

On Wed, 24 Jul 2002 12:49:10 -0400, TinCanMan quoth:

>> One thing that has been bothering me is the "glass of water" type
>> situation...I'm not sure POV handles it correctly or how to model it
>> correctly.
>>
>>
> Here it is necessary to double up your surfaces so the surface of the
> water is slightly outside the surface of the glass. ie, the ray exits
> the glass into air and then into the water.  There is no way to avoid
> increasing the number of surfaces in this case if you want it to work
> correctly. For something completely immersed int the water (or glass for
> that matter) this isn't necessary (in case you think this is
> contradicatory to my previous post).
> 
> -tgq
 
If you could create the glass without an inner surface (perhaps by using
clipped_by), you would get the most realistic performance, since the ray
would go directly from glass to water, without passing through a layer of
air.

-- 
Mark

Post a reply to this message

On Wed, 24 Jul 2002 21:06:53 -0500, Christopher James Huff wrote:
> In article <slr### [at] fwicom>,
>  Ron Parker <ron### [at] povrayorg> wrote:
> 
>> It's handled correctly except for the very rare case where a ray enters
>> the water object without leaving the glass object.  If your surfaces are
>> close enough together, that almost never happens and AA will fix it if it
>> does.
> 
> You mean where it just skirts the edge of the water object where it 
> overlaps but doesn't touch the inner surface of the glass?

Right.  A very rare case indeed.

-- 
#macro R(P)z+_(P)_(P)_(P+1)_(P+1)+z#end#macro Q(C,T)bicubic_patch{type 1u_steps
6v_steps 6R(1)R(3)R(5)R(7)pigment{rgb z}}#end#macro _(Y)#local X=asc(substr(C,Y
,1))-65;<T+mod(X,4)div(X,4)9>-2#end#macro O(T)Q("ABEFUQWS",T)Q("WSXTLOJN",T)#
end O(0)O(3)Q("JNKLCGCD",0)light_source{x 1}// ron### [at] povrayorg

Post a reply to this message

In article <pan### [at] gtenet>,
 Mark Wagner <mar### [at] gtenet> wrote:

> If you could create the glass without an inner surface (perhaps by using
> clipped_by), you would get the most realistic performance, since the ray
> would go directly from glass to water, without passing through a layer of
> air.

If you cut away the water surface, the ray never "enters" the water 
object. If you cut away the glass surface, it won't leave the glass 
object until it reaches the other side of the cup, if it exits through 
the top of the cup it will never become "outside" the cup.

As Ron Parker explained though, when there is an overlap the glass/water 
transition is handled as it should be and the ior of the redundant 
surface is ignored, so you don't need any special CSG. Still, there are 
two extra surfaces in the body of the glass...that just bugs me, having 
6 surfaces where 4 should be sufficient.

Maybe it would be possible to specify interior transitions on a 
per-surface basis...instead of a "water object" and a "glass object", 
the glass of water situation would be 3 separate surfaces: glass-air, 
glass-water, and water-air. The modelling would be more difficult...it'd 
probably only be worth it for a scene with a lot of glasses and bottles 
of liquids (a lab or bar?) or if it was somehow automatically generated 
(back to the immerse CSG?). Maybe a good trick for a real-time raytracer 
though.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message