 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ive been trying to make a cone of light that visible, coming from a
flashlight, i really dont know that much yet, ive only had about a month or
so experience with pov-ray. heres the source that im working with, im only
putting the part im having trouble with:
#declare Light_Cone =
cone { <0,1.928,0>, .182
<0,25,0>, 2.5
texture { pigment { White }
finish { ambient 6 }
}
}
light_source {
<0,1.928,0>
color White
spotlight
point_at <0,25,-20>
radius .182
falloff 5.725
looks_like { object { Light_Cone } }
}
the problem is that it doesnt show up at all in rendering. i know thats not
a very much help, but i would appreciate any ideas any one has. thanx!
~Nick~
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Nick Holcomb" <enr### [at] PunkAss com> wrote :
>
> the problem is that it doesnt show up at all in rendering. i know thats
not
> a very much help, but i would appreciate any ideas any one has. thanx!
Where is your camera? Does it look at the cone?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Your cone isn't pointint at the right position.
While your spotlight points at <0,25,-20>, your
cone just points to <0,25,0>. Looks_like doesn't
rotate objects, it just uses them as defined.
And perhaps scaling isn't right, though I'm not
sure without a look at your scene. The cone's
end is only 2.5, but perhaps that is wanted...
Nick Holcomb had this problem:
> #declare Light_Cone =
> cone { <0,1.928,0>, .182
> <0,25,0>, 2.5
> texture { pigment { White }
> finish { ambient 6 }
> }
> }
>
> light_source {
> <0,1.928,0>
> color White
> spotlight
> point_at <0,25,-20>
> radius .182
> falloff 5.725
> looks_like { object { Light_Cone } }
> }
>
--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
You have the cone surface intersecting the light source
cone { <0,1.928,0>, .182
light_source { <0,1.928,0>
It may help if you move the light or end the of the cone just a little.
I found that if a plane intersects a light source some strange things can
happen. Sometimes little black artifacts sometimes it acts like there no light
at all.
--
Have Fun!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3CA2CAA6.20C1614C@joplin.com>,
Leroy Whetstone <lrw### [at] joplincom> wrote:
> I found that if a plane intersects a light source some strange things can
> happen. Sometimes little black artifacts sometimes it acts like there no light
> at all.
This is just another case of the coincident surface problem...POV
doesn't know which side of the surface the light is on, so it
unpredictably gets shadowed by it depending on how the precision errors
work out.
--
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:
> This is just another case of the coincident surface problem...POV
> doesn't know which side of the surface the light is on, so it
> unpredictably gets shadowed by it depending on how the precision errors
> work out.
Why not assume it's on both sides? Or neither...
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
That's the typical coincidence surface problem:
POV-Ray has no means of checking if two
objects actually have coincident surfaces. It just
happens to hit one or the other by random.
This is also true for internal calculations of light,
I guess.
"Timothy R. Cook" wrote:
> Why not assume it's on both sides? Or neither...
--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3CA3AA9A.D891977D@scifi-fantasy.com>,
"Timothy R. Cook" <tim### [at] scifi-fantasycom> wrote:
> Christopher James Huff wrote:
> > This is just another case of the coincident surface problem...POV
> > doesn't know which side of the surface the light is on, so it
> > unpredictably gets shadowed by it depending on how the precision errors
> > work out.
>
> Why not assume it's on both sides? Or neither...
Because then you would never get any shadows. ;-)
POV doesn't know the light is "on" the surface, so it can't just avoid
that surface. If you made the surface shadowless, the problem would go
away, but that has other obvious problems.
--
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:
> POV doesn't know the light is "on" the surface, so it can't just
> avoid that surface.
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!
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3CA3D327.77480C19@scifi-fantasy.com>,
"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!
POV would have to check that point against the bounding box of every
object in the scene, and then against the surface of any objects it
might be on. This would slow things down noticeably, just to handle what
is really a degenerate case.
And then, the correct thing to do would be to always consider the light
shadowed by the object, otherwise you will get wrong shadows with
objects like a torus, where other parts of the object should cast
shadows from a point just above the surface. Of course, this wouldn't be
very useful...it would just slow things as mentioned above, and replace
user complaints about lights not lighting properly with complaints about
lights not lighting at all.
You could also mess around slightly with the depth values, basically
have POV lie to itself it doesn't "see" intersections that are very
close to the light source. 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.
--
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:
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> > Intel/AMD need to severly upgrade their FPUs.
> To what?
To something that can correctly evaluate sqrt(100)==10.
--
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:
> To something that can correctly evaluate sqrt(100)==10.
Any suggestion (which is not 1000 times slower than the current system)?
--
#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:
> > To something that can correctly evaluate sqrt(100)==10.
> Any suggestion (which is not 1000 times slower than the current system)?
I'm an illustration major, not compsci.
--
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" wrote:
>
> I'm an illustration major, not compsci.
So then let the compscis decide what's feasible and what not.
Markus
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Markus Becker <bec### [at] aicossde> wrote:
> So then let the compscis decide what's feasible and what not.
Yeah. We know what you need and what you don't. ;)
Seriously, sometimes something can look pretty simple and obvious and one
tends to think "how come they never have thought of this?". However, usually
when you care to find out about the issue you discover that it's one of
the things first considered and usually quickly discarded as completely
unfeasible. The reasons for discarding it may not always be obvious, but
they are usually very justifiable.
--
#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
|
|
| |
| |
|
|
|
|
| |
