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