Christopher James Huff wrote:
> The point is this just isn't necessary...just don't put your lights
> on a surface! That situation never occurs in reality and there is
> no reason to bother handling it.

In all technicality, EVERY light in reality is occuring on a surface...

;)

-- 
Tim Cook
http://empyrean.scifi-fantasy.com

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------

Post a reply to this message

Thanx everyone, i figured out my problem and fixed it
~Nick

Post a reply to this message

Timothy R. Cook <tim### [at] scifi-fantasycom> wrote:
> But the light (if we're talking about a point light) is a known
> single point!  It's easy to test if it's on the surface!

  No, it isn't.
  You can test wether a point is inside or outside the object, but you
can't test if it's exactly on the surface.

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

In article <3CA4D442.D0395B13@scifi-fantasy.com>,
 "Timothy R. Cook" <tim### [at] scifi-fantasycom> wrote:

> In all technicality, EVERY light in reality is occuring on a surface...

More like *most* lights in reality *are* surfaces. Putting a 
light_source on a surface does nothing to imitate this.
And there are many cases where no surface is involved. Fire, for example.

Also, in reality, there is no such thing as a point light source. They 
only exist because they are so much faster to compute.

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

Warp wrote:
> You can test wether a point is inside or outside the object, but you
> can't test if it's exactly on the surface.

Er, if you can test if a point is inside or outside the object, you
can test if it's exactly on the surface (i.e. point is neither
inside nor outside the object, or both, it must be coinciding)

-- 
Tim Cook
http://empyrean.scifi-fantasy.com

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------

Post a reply to this message

On Fri, 29 Mar 2002 17:47:32 -0500, "Timothy R. Cook"
<tim### [at] scifi-fantasycom> wrote:

>Er, if you can test if a point is inside or outside the object, you
>can test if it's exactly on the surface (i.e. point is neither
>inside nor outside the object, or both, it must be coinciding)

No you can not. There's such a thing as limited floating point
precision. You may *assume* a point is on a surface but there is no
guarantee. For you, acos(sqrt(2)/2) may be equal to pi/4, but for a
computer it is not. Computers just can't deal with infinitely long
numbers.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

Peter Popov wrote:
> Computers just can't deal with infinitely long numbers.

Where's the fun in that?  *sigh*  I want a computer that can
handle infinitely long numbers...
-- 
Tim Cook
http://empyrean.scifi-fantasy.com

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------

Post a reply to this message

Timothy R. Cook <tim### [at] scifi-fantasycom> wrote:
> Er, if you can test if a point is inside or outside the object, you
> can test if it's exactly on the surface (i.e. point is neither
> inside nor outside the object, or both, it must be coinciding)

  Nope. I'm not talking about theory here, but about how it is implemented
in the POV-Ray source code.
  Functions which tell whether a point is inside a specific primitive or
not (these are necessary for CSG) return just two values: Either the point
is inside or it isn't.

  And as someone else already said, also floating point accuracy doesn't
allow telling whether a point is exactly on a surface, even if we have
a simple surface where this test would be trivial (eg. a sphere).
  For example, suppose that we have a sphere of radius 10 and we want to
test whether the point <10,0,0> is exactly on its surface. We would make
a test like: (sqrt(10^2+0^2+0^2) == 10)
  However, the test (sqrt(100) == 10) will most probably return false due
to floating point inaccuracies (you can test it if you want if you know C
and have a compiler).
  Equality is usually done with an epsilon value (ie.
abs(sqrt(100)-10) < epsilon), but this doesn't tell you whether the
point is exactly on the surface, outside it, or inside it. Using this
kind of test can tell you if the point is extremely close to the surface
but it won't tell you that if it isn't, if it is inside or outside it.


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

Warp wrote:
>   However, the test (sqrt(100) == 10) will most probably return false due
> to floating point inaccuracies (you can test it if you want if you know C
> and have a compiler).
>   Equality is usually done with an epsilon value (ie.
> abs(sqrt(100)-10) < epsilon), but this doesn't tell you whether the
> point is exactly on the surface, outside it, or inside it. Using this
> kind of test can tell you if the point is extremely close to the surface
> but it won't tell you that if it isn't, if it is inside or outside it.

Well that sucks.  Intel/AMD need to severly upgrade their FPUs.

-- 
Tim Cook
http://empyrean.scifi-fantasy.com

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------

Post a reply to this message

Timothy R. Cook <tim### [at] scifi-fantasycom> wrote:
> Intel/AMD need to severly upgrade their FPUs.

  To what?

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