Christopher James Huff wrote:
> And now you have to project it, with perspective, onto a plane,

Oops, forgot perspective.  NEVERMIND!

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

Ron Parker wrote:
> Ahh, but you need to think even further outside the box: what does a
> negative transmit do?

A black hole? ;)
-- 
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

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3c6ade73@news.povray.org...
> Ben Chambers <bdc### [at] yahoocom> wrote:
> :>   Does it work for reflections/refractions as well?-)
>
> : Does the current method?  I was under the impression that supersampling
was
> : done only on the rays shot from the view plane, and not on reflection /
> : refracted rays.
>
>   Of course it works for reflections/refractions. If the pixel color
> difference threshold is reached, then another ray is shot from the camera.
> This ray will (probably) also reflect/refract from the same object, thus
> sampling whatever is reflected/refracted.

But you're still talking about rays from the camera.  I thought you meant
that reflected / refracted rays themselves were supersampled :)

...Chambers

Post a reply to this message

"Christopher James Huff" <chr### [at] maccom> wrote in message
news:chr### [at] netplexaussieorg...
> In article <3c6ad4df@news.povray.org>,
>  "Ben Chambers" <bdc### [at] yahoocom> wrote:
>
> > Such a setting belongs in the INI file, not in the scene.
>
> The .ini file is no place for an object-specific attribute.

But it ~is~ the place to place instructions for how to sample a scene.

> Hairs, any kind of cabling, ropes or strings, screens or gratings, chain
> link fences, stars, cracks (like in floors or walls), wood, small
> text...I could come up with more.

You're right, of course, I just wasn't being creative at the time I wrote it
:)

> You can usually get good results with
> with the existing adaptive method, but not always.

True, as with everything.  Another method would be good, not because the
current method is impossible to use, but just to have another tool in your
belt :)

...Chambers

Post a reply to this message

"Christopher James Huff" <chr### [at] maccom> wrote in message
news:chr### [at] netplexaussieorg...
> In article <3C6AE046.5D095B2C@scifi-fantasy.com>,
>  "Timothy R. Cook" <tim### [at] scifi-fantasycom> wrote:
>
> > So because it can't be done for everything, it isn't done at all.
>
> It would be very difficult, probably requiring a rewrite, and about the
> only thing it would work for would be triangles and polygons. Even
> spheres would probably be too difficult...where's the edge of an
> unevenly scaled and rotated sphere?

Easy.  Rotate and scale the eye, and then it becomes a normal sphere :)

> And then you have things like the
> different camera types, camera normals, etc, which would make it
> unuseable for any object...

No, just some objects.  And besides, most (all?) objects have bounding
shapes which can be used for the guesswork :)

> It is simply not worth implementing for the few cases it would actually
> be any help.

I disagree here, but I don't know how much work would be required in the
implementation.

...Chambers

Post a reply to this message

"Timothy R. Cook" <tim### [at] scifi-fantasycom> wrote in message
news:3C6AF52E.61011A6C@scifi-fantasy.com...
> Rune wrote:
> > Unless it's something extremely simple, like, say, changing the
> > way transmit works outside of the 0 to 1 range to a more logical
> > behavior.
>
> How exactly DOES transmit work, anyways?  Amount of light able
> to pass through the object?  0 being none, 1 being all...more
> than 1 being...the object adds light to that passing through it?
> That would be cool.  If that's how it works, I wanna try that
> out!

That's how it used to work (don't know if it still does), I used that effect
for a while :)

...Chambers

Post a reply to this message

"Ron Parker" <ron### [at] povrayorg> wrote in message
news:slr### [at] fwicom...
> Correction: it deals with edges that are within a pixel of the edge of the
> bounding box.  This is a far cry from all edges, even for simple boxes and
> cylinders (consider rotation.)

Hmm... good point... perhaps something along the lines of a stencil buffer?
Though, you would need a bit-plane for every object, so it would gobble up
huge amounts of RAM.

...Chambers

Post a reply to this message

Ben Chambers wrote:
> 
> "Christopher James Huff" <chr### [at] maccom> wrote in message
> news:chr### [at] netplexaussieorg...
>
> Easy.  Rotate and scale the eye, and then it becomes a normal sphere :)
> 

But then your distribution to anti-alias should still be modified 
according to the transformation, because what would be a regular grid
would not stay so on the other side of the transformation.
You moved the problem from the object to the camera.
The number of camera is half the number of objects, but I'm not sure
adding transformation to antialiasing in camera is simpler...

> > And then you have things like the
> > different camera types, camera normals, etc, which would make it
> > unuseable for any object...
> 
> No, just some objects.  And besides, most (all?) objects have bounding
> shapes which can be used for the guesswork :)

Not all. Plane do not, and they are often used in CSG... which
came back to the eternal problem to compute the smallest bounding box
for any CSG.

And guessing is just another way to take samples...

Post a reply to this message

Peter Popov wrote:
 
> You're always welcome to solve for the formula defining the
> intersection of a complex isosurfaces with noise, and a atanh julia
> fractal :)

You, pervert ;-)
And people just think that raytracing is just about 
reflective sphere on checkered plane.
Or checkered sphere on reflective plane.

Post a reply to this message

Peter Popov wrote:
> You're always welcome to solve for the formula defining the
> intersection of a complex isosurfaces with noise, and a atanh julia
> fractal :)

I remember my HS chemistry book that had a small portion of
Heisenberg's uncertainty formula, and an image of the solution
to the whole thing...if THAT can be done, I'm sure a complex
isosurface with noise and an atanh julia fractal could be done ;)

-- 
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 remember my HS chemistry book that had a small portion of
> Heisenberg's uncertainty formula, and an image of the solution
> to the whole thing...if THAT can be done, I'm sure a complex
> isosurface with noise and an atanh julia fractal could be done ;)

Well, you know, of course, that there is no general analytical solution to
find the roots of a polynome of sufficient degres (sufficient being more
than 4, IIRC). Nevertheless, it is possible to make an image of any polynome.

And some integration are impossible to perform mathematically, whereas computing
the value is done more easily. And some other, when using Mapple, take a very long
time and are really very long.

To go with the suggested method, you would have to stay as much as possible
analytic, avoiding all numerisations. I believe you would need to cross
the code of Mapple with a renderer. The interesting possible result would
be a RGBA formula for each pixel, this formula being dependent on all the
scene setting (objects, positions, textures, ior and so on).
The good thing is: you render once, and unless you remove/add an object or
replace a texture to drastically, you get 'instant-rendering' of multiple
variant (animation without #if/#switch, test of various mapping, variation
of IOR...)
The bad thing is: their is one enormous formula per pixel, and the time to 
evaluate it is also enormous.

The problem of anti-aliasing vs moire is badly answered with only a method
which use a discret ray.
If every object had a method to which a container ray(*) could be tested and
the answer was not the intersection point, but the amount of section intersected,
then it would be easier.

But there is a big gotcha: transforming a line in object space always result in
a line. But transforming a container ray, you might end up with very strange figure,
and the math are not easy.

(*): imagine a semi-infinite box (limited by only 5 perpendicular planes)

Post a reply to this message

Warp wrote:
> ...
> You are welcome to suggest an algorithm for that.
> ...

I've noticed the POV-team requests source code for things a lot. What
exactly is it that their coders *do*? Bundle it all together?
[j/k]

-- 
signature{
  "Grey Knight" contact{ email "gre### [at] yahoocom" }
  site_of_week{ url "http://digilander.iol.it/jrgpov" }
}

Post a reply to this message

"Ben Chambers" wrote:
> > How exactly DOES transmit work, anyways?  Amount of light able
> > to pass through the object?  0 being none, 1 being all...more
> > than 1 being...the object adds light to that passing through it?
> > That would be cool.  If that's how it works, I wanna try that
> > out!
>
> That's how it used to work (don't know if it still does), I used
> that effect for a while :)

You forget to take into consideration the object's own color. Transmit 0
gives all of the object's own color, transmit 1 none, and transmit >1 ...

I suggest you have a look at this samle scene in POV-Ray 3.5:
scenes\textures\pigments\transmitfx.pov

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Jan 20)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

On Thu, 14 Feb 2002 11:27:33 +0000, Grey Knight <s16### [at] namtarqubacuk>
wrote:
> I've noticed the POV-team requests source code for things a lot.

Not exactly source code. Rather theory connected with request. CG is a
science. POV-Ray isn't developed at university. Real Life not leaves time for
personal research probably.

> What exactly is it that their coders *do*?

IMO they are there for free gadgets ;-)

> Bundle it all together?

From povray.f-a-q: "POV-Ray 3.5 is a work that will be somewhat similar to the
unofficial compile known as MegaPov." So what is MegaPOV ? From its site:
"MegaPov (formerly UVPov, SuperPatch, and MultiPatch) is a cooperative work by
members of the POV-Ray community."

But don't forget great work of all such things like incredible functions
features and all other things listed in 2.6. Note also hard work around bugs
sended to povray.beta-test.

Personally I like thinking that POV-Ray Team members
are The Elders of POV-Ray Community.

ABX

Post a reply to this message

>   You are welcome to suggest an algorithm for that.
Please correct me as soon as I make a stupid mistake :)
Is it possible to compute the intersection of a cone and the objects in the
scene?  Not the intersecting points, but the fact if there is an intersection or
not.
If this is possible, you could shoot cones instead of rays.  If the cone
intersects an object, but the ax of the cone (the traced ray with ordinary
raytracing) doesn't, that pixel should be supersampled.
Might not be possible for every object (isosurfaces for example), but maybe for
enough objects to make it worth implementing?

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

> Because that's how recursive AA works; instead of blindly supersampling
> everything within a pixel's area, the algorithm attempts to find edges
> and only use the samples that are needed to better define those edges,
> while interpolating the rest.

The doc says:
"If the resulting colors differ more than the threshold amount additional
samples will be taken."
If it's really "more", only four samples per pixel would be taken. But as
more samples are taken, the meaning is "at least", so it should reach the
maximum number of subdivisions and samples.

Post a reply to this message

> If this is possible, you could shoot cones instead of rays.  If the cone
> intersects an object, but the ax of the cone (the traced ray with ordinary
> raytracing) doesn't, that pixel should be supersampled.
> Might not be possible for every object (isosurfaces for example), but
maybe for
> enough objects to make it worth implementing?

And what happens when the ray is reflected or refracted?
I don't think that it is possible to implement a method which works only for
a few types of objects.
Also, the cone is represented by a second order equation (IIRC), but the ray
is only a first order equation.

Post a reply to this message

> And what happens when the ray is reflected or refracted?
not much :)

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

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

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

On Wed, 13 Feb 2002 22:12:31 -0800, Ben Chambers wrote:
> 
> "Ron Parker" <ron### [at] povrayorg> wrote in message
> news:slr### [at] fwicom...
>> Correction: it deals with edges that are within a pixel of the edge of the
>> bounding box.  This is a far cry from all edges, even for simple boxes and
>> cylinders (consider rotation.)
> 
> Hmm... good point... perhaps something along the lines of a stencil buffer?

But then you have a chicken-and-egg problem: how do you produce that buffer
without tracing rays, at least for most objects (including CSGs).

-- 
#macro R(P)z+_(P)_(P)_(P+1)_(P+1)+z#end#macro Q(C,T)bicubic_patch{type 1u_steps
6v_steps 6R(1)R(3)R(5)R(7)pigment{rgb z}}#end#macro _(Y)#local X=asc(substr(C,Y
,1))-65;<T+mod(X,4)div(X,4)9>-2#end#macro O(T)Q("ABEFUQWS",T)Q("WSXTLOJN",T)#
end O(0)O(3)Q("JNKLCGCD",0)light_source{x 1}// ron### [at] povrayorg

Post a reply to this message

In article <3C6B9F25.61E87BF7@namtar.qub.ac.uk> , Grey Knight 
<s16### [at] namtarqubacuk>  wrote:

> I've noticed the POV-team requests source code for things a lot. What
> exactly is it that their coders *do*? Bundle it all together?
> [j/k]

Fix the bugs in the code we get! ;-)

    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

Grey Knight wrote:
> ...
> [j/k]

Just replying to my own post to point something out. I could get in
serious trouble if that post was taken the wrong way...

-- 
signature{
  "Grey Knight" contact{ email "gre### [at] yahoocom" }
  site_of_week{ url "http://digilander.iol.it/jrgpov" }
}

Post a reply to this message

On Thu, 14 Feb 2002 02:44:09 -0500, "Timothy R. Cook"
<tim### [at] scifi-fantasycom> wrote:

>I remember my HS chemistry book that had a small portion of
>Heisenberg's uncertainty formula, and an image of the solution
>to the whole thing...if THAT can be done, I'm sure a complex
>isosurface with noise and an atanh julia fractal could be done ;)

Who says it wasn't sampled?

Come on, sight is a set of functions of three dimensions: u and v of
the retina and t of time. They are continuous functions both in domain
and range. The only generic way to integrate a continuous function
over some interval is numerically, by sampling.


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

Post a reply to this message

On Thu, 14 Feb 2002 11:27:33 +0000, Grey Knight wrote:
> Warp wrote:
>> ...
>> You are welcome to suggest an algorithm for that.
>> ...
> 
> I've noticed the POV-team requests source code for things a lot. What
> exactly is it that their coders *do*? Bundle it all together?

We only write code for stuff that's possible.  When you see me requesting
source code, it's usually for something that has such a high cost/benefit 
ratio as to be unlikely, and it's usually from someone who has no idea of
the complexities involved and does not want to listen to anyone who does.
It's a version of "You think it's so easy?  Why don't you do it?" that is
slightly less vitriolic (usually...)

-- 
#local R=<7084844682857967,0787982,826975826580>;#macro L(P)concat(#while(P)chr(
mod(P,100)),#local P=P/100;#end"")#end background{rgb 1}text{ttf L(R.x)L(R.y)0,0
translate<-.8,0,-1>}text{ttf L(R.x)L(R.z)0,0translate<-1.6,-.75,-1>}sphere{z/9e3
4/26/2001finish{reflection 1}}//ron.parker@povray.org My opinions, nobody else's

Post a reply to this message

On Thu, 14 Feb 2002 13:44:01 +0000, Grey Knight
<s16### [at] namtarqubacuk> wrote:

>Just replying to my own post to point something out. I could get in
>serious trouble if that post was taken the wrong way...

Thorsten smiled, so you're likely out of the woods already :)


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

Post a reply to this message

Timothy R. Cook <tim### [at] scifi-fantasycom> wrote:
: Christopher James Huff wrote:
:> And now you have to project it, with perspective, onto a plane,

: Oops, forgot perspective.  NEVERMIND!

  And add to that all the other type of projections: spherical,
ultra_wide_angle, panoramic, cylindrical, fisheye... Not to talk about
camera ray perturbation (with a normal block).
  The excellent thing about raytracing is that implementing all those types
of projections is laughably easy (while in scanline-rendering it's extremely
difficult to do without serious compromises). The negative side is that it
disallows any optimizations typical to scanline-rendering.

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

Ben Chambers <bdc### [at] yahoocom> wrote:
:>   Of course it works for reflections/refractions. If the pixel color
:> difference threshold is reached, then another ray is shot from the camera.
:> This ray will (probably) also reflect/refract from the same object, thus
:> sampling whatever is reflected/refracted.

: But you're still talking about rays from the camera.  I thought you meant
: that reflected / refracted rays themselves were supersampled :)

  The reflected/refracted rays get "supersampled" by all practical means when
new rays are shot from the camera which are very close to the previous ones.
That's the logical and most practical way of doing it (one reason being that
the change in color may be caused by the reflecting surface itself, not the
thing that it reflects).

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

Ron Parker <ron### [at] povrayorg> wrote:
: On Thu, 14 Feb 2002 11:27:33 +0000, Grey Knight wrote:
:> Warp wrote:
:>> ...
:>> You are welcome to suggest an algorithm for that.
:>> ...
:> 
:> I've noticed the POV-team requests source code for things a lot. What
:> exactly is it that their coders *do*? Bundle it all together?

: We only write code for stuff that's possible.  When you see me requesting
: source code, it's usually for something that has such a high cost/benefit 
: ratio as to be unlikely, and it's usually from someone who has no idea of
: the complexities involved and does not want to listen to anyone who does.
: It's a version of "You think it's so easy?  Why don't you do it?" that is
: slightly less vitriolic (usually...)

  Besides, I didn't ask for source code. I asked for an algorithm. An
algorithm is not necessarily a source code (in fact, it's usually better
to give it in a more human readable form than in plain C).

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

On 14 Feb 2002 10:00:29 -0500, Warp wrote:
> Ron Parker <ron### [at] povrayorg> wrote:
>: We only write code for stuff that's possible.  When you see me requesting
>: source code, it's usually for something that has such a high cost/benefit 
>: ratio as to be unlikely, and it's usually from someone who has no idea of
>: the complexities involved and does not want to listen to anyone who does.
>: It's a version of "You think it's so easy?  Why don't you do it?" that is
>: slightly less vitriolic (usually...)
> 
>   Besides, I didn't ask for source code. I asked for an algorithm. An
> algorithm is not necessarily a source code (in fact, it's usually better
> to give it in a more human readable form than in plain C).

I asked for source code.

-- 
#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{rgbf 1}hollow interior{media{emission 3-T}}}#end 
Z(-x-x.2x)camera{location z*-10rotate x*90normal{bumps.02scale.05}}

Post a reply to this message

Zeger Knaepen <zeg### [at] studentkuleuvenacbe> wrote:
: Please correct me as soon as I make a stupid mistake :)
: Is it possible to compute the intersection of a cone and the objects in the
: scene?

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

-- 
#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 <3c6b54de@news.povray.org>,
 "Ben Chambers" <bdc### [at] yahoocom> wrote:

> > And then you have things like the
> > different camera types, camera normals, etc, which would make it
> > unuseable for any object...
> 
> No, just some objects. 

Nope, all of them. A camera normal will completely screw up any 
calculations you come up with. You would also have to completely rewrite 
it for each projection...some of which are probably also not reversable.
You would pretty much have to reduce the objects to triangles to do it 
for the simplest cases...might as well use a scanline renderer at that 
point.


> And besides, most (all?) objects have bounding
> shapes which can be used for the guesswork :)

Often very loose, and with nowhere close to corresponding to the 
object's edges.


> > It is simply not worth implementing for the few cases it would actually
> > be any help.
> 
> I disagree here, but I don't know how much work would be required in the
> implementation.

Then think about it until you understand. The amount of work would 
probably be greater than rewriting all of POV (and would probably 
require just this), and you would end up with something that does what a 
scanline renderer does, but much slower. Just so you can get 
near-perfect antialiasing of a couple objects, sometimes, and slower 
than the equivalent adaptive settings.

-- 
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 <3c6b5437@news.povray.org>,
 "Ben Chambers" <bdc### [at] yahoocom> wrote:

> But it ~is~ the place to place instructions for how to sample a scene.

These aren't instructions on sampling the scene, but on how to sample a 
specific object. They *can't* go in the .ini file, and don't belong 
there, since they are not scene attributes, but object attributes (or 
possibly texture attributes).

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

>   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