"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