>   I don't think there's an analytical solution for the intersection of a cone
> and any given mathematical surface.
>   You have probably heard about raytracers which use cones instead of rays,
> but those raytracers most probably support just triangles (the intersection
> of a cone and a triangle is possible and rather easy to calculate).
Nope, never heard of.  But I can imagine it isn't easy to find the intersection
of a cone and any surface.  However, all you need to know is if there could be
an intersection.  Isn't it easier to find out that the cone cannot intersect the
surface than to find out if it does intersect?  And if it is possible that it
intersects, maybe that's reason enough to supersample the pixel?  I mean: you
don't have to find the intersecting points, maybe you don't even have to find
out if there is an intersection.  I might be enough to know there is no
intersection, and maybe that's easy to find out?  I'm not very good in
mathematics, so I'm probably just talking nonsense...

cu!
--
camera{location-z*3}#macro G(b,e)b+(e-b)*(C/50)#end#macro L(b,e,k,l)#local C=0
;#while(C<50)sphere{G(b,e),.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1
;#end#end L(y-x,y,x,x+y)L(y,-x-y,x+y,y)L(-x-y,-y,y,y+z)L(-y,y,y+z,x+y)L(0,x+y,
<.5,1,.5>,x)L(0,x-y,<.5,1,.5>,x)               // ZK http://www.povplace.be.tf

Post a reply to this message

> > And what happens when the ray is reflected or refracted?
> not much :)
That's the problem. The cone had to change its size.

> > I don't think that it is possible to implement a method which works only
for
> > a few types of objects.
> but maybe enough types to make it worth implementing?
An implementation would be too complex and the number of supported types too
small (as Warp said).

> > Also, the cone is represented by a second order equation (IIRC), but the
ray
> > is only a first order equation.
> I never said it would be fast :)
The quality decreases drastically when using an approximation.

Post a reply to this message

Timothy R. Cook <tim### [at] scifi-fantasycom> wrote in message
news:3C6AEDA7.FAE8DA49@scifi-fantasy.com...
>
> So the only way to get anything done in the world is to do it
> yourself, even if other people have more aptitude with what you
> want changed?

Or pony-up some cash. Not a suggestion in this particular case, but an
acceptable second method for getting something done.

 -Shay

Post a reply to this message

Shay wrote:
> Or pony-up some cash. Not a suggestion in this particular case,
> but an acceptable second method for getting something done.

How much would the POV team consider an acceptable donation, and
where do I send the cheque? ;)

-- 
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 in message
news:3C6D662E.D59F2D7E@scifi-fantasy.com...
> How much would the POV team consider an acceptable donation, and
> where do I send the cheque? ;)

$500 send to:
Pov Team
c/o Shay
3434 34th street
Somecity, SS 44444

 -Shay

Post a reply to this message

> How much would the POV team consider an acceptable donation, and
> where do I send the cheque? ;)

This has been asked before, seriously, and the answer is (IIRC) that the
Team cannot accept money. Now, if you would like to hire one of the members
of the Team and let them spend their time programming POV, I don't think
they would object, given the right salary and working conditions. :)

Post a reply to this message

Zeger Knaepen wrote:

 > And if it is possible that it intersects, maybe that's reason
 > enough to supersample the pixel?  I mean: you don't have to find
 > the intersecting points, maybe you don't even have to find out if
 > there is an intersection.  I might be enough to know there is no
 > intersection, and maybe that's easy to find out?  I'm not very
 > good in mathematics, so I'm probably just talking nonsense...
 >

To put it in a wierd way: what you request is allmost that what povray
does. The only difference beeing: povray's AA triggers on color
changes, not on ray-hits-different-object.
After a "trigger condition" is detected, a search process startes by
shooting more and more rays to get the location of the trigger
condition more precise.

That means: one could consider to change povray, so that it starts AA,
if the next intersection hit on a different object than the previous
one. But in most cases, detection of object changing is a weaker
condition than detecting a color change (because the latter can also
happen by texturing, lighting or media). So, if color-change-triggerd
AA is not satisfactory in some cases, I would guess, 
object-change-triggerd AA will be as well not satisfactory in
even more cases.

Maybe it will detect the border of a black cat in the night :-)

So, maybe the best way would be, to go on and hack povray
to try it out.

Post a reply to this message

"Timothy R. Cook" wrote:
> 
> Ron Parker wrote:
> > Want it changed?  Stop bitching and start writing code.
> 
> So the only way to get anything done in the world is to do it
> yourself, even if other people have more aptitude with what you
> want changed?

Essentially, yes.

The advantage of the free/open development model is that anyone who
wants to, and can, can modify the code, either for their own purposes,
or for the sake of making general improvements (optimization, debugging,
porting, etc). However, one problem with that model is that it assumes
that anyone who would use the compiled software is *capable* of
successfully modifying it, and this is more often not the case.
Non-programmers are implicitly or explicitly asked to contribute what
they can, but usually the only things they can contribute are
suggestions and bug reports, which the self-appointed caretakers of the
code seem to resent at least as often as they welcome them, since they
represent more work for the programmer. Eventually, the programmers
start rejecting things, either for design reasons, or because they don't
feel that the bugs or suggestions are worth their time to fix. The
coders start to see the non-coders as whiny ingrates, while the
non-coders start to see the coders as arrogant, unreasonable, and/or lazy.

It's a poor situation for both sides, which is why disputes between
coders and non-coders typically boil down to "if you want something done
right, do it yourself".

-Xplo

Post a reply to this message

> To put it in a wierd way: what you request is allmost that what povray
> does. The only difference beeing: povray's AA triggers on color
> changes, not on ray-hits-different-object.
> After a "trigger condition" is detected, a search process startes by
> shooting more and more rays to get the location of the trigger
> condition more precise.
I know, I was just proposing a different kind of "trigger condition" to have a
different anti-aliasing effect.

> That means: one could consider to change povray, so that it starts AA,
> if the next intersection hit on a different object than the previous
> one. But in most cases, detection of object changing is a weaker
> condition than detecting a color change (because the latter can also
> happen by texturing, lighting or media). So, if color-change-triggerd
> AA is not satisfactory in some cases, I would guess,
> object-change-triggerd AA will be as well not satisfactory in
> even more cases.
No, it indeed wouldn't be a good technique to anti-alias textures and lighting,
but isn't this thread about the anti-aliasing of the edges of objects?
And maybe, if you combine the current technique and this technique, you get
better results?

> Maybe it will detect the border of a black cat in the night :-)
hmmm, true, it would indeed anti-alias in places where it's absolutely not
necessary...

> So, maybe the best way would be, to go on and hack povray
> to try it out.
I'm not a programmer, I wouldn't now where to start.

cu!
--
camera{location-z*3}#macro G(b,e)b+(e-b)*(C/50)#end#macro L(b,e,k,l)#local C=0
;#while(C<50)sphere{G(b,e),.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1
;#end#end L(y-x,y,x,x+y)L(y,-x-y,x+y,y)L(-x-y,-y,y,y+z)L(-y,y,y+z,x+y)L(0,x+y,
<.5,1,.5>,x)L(0,x-y,<.5,1,.5>,x)               // ZK http://www.povplace.be.tf

Post a reply to this message

Zeger Knaepen wrote:
> No, it indeed wouldn't be a good technique to anti-alias textures and lighting,
> but isn't this thread about the anti-aliasing of the edges of objects?
> And maybe, if you combine the current technique and this technique, you get
> better results?
> 
> 
>>Maybe it will detect the border of a black cat in the night :-)
>>
> hmmm, true, it would indeed anti-alias in places where it's absolutely not
> necessary...
> 
> 
>>So, maybe the best way would be, to go on and hack povray
>>to try it out.
>>
> I'm not a programmer, I wouldn't now where to start.

without in-depth analysis (and so at a risk to tell nonsense), I
would think this rather easy, and an interesting experiment too.
As soon as I get some time, I will have a look at it.
(but at the moment, I am busy getting my stereo-pov patch ready)

Hermann

Post a reply to this message