"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