 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] yahoo com" }
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
|
|
| |
| |
|
|
From: Zeger Knaepen
Subject: Re: More methods? was Re: anti-aliasing
Date: 14 Feb 2002 07:45:57
Message: <3c6bb185@news.povray.org>
|
|
|
| |
| |
|
|
> 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
|
|
| |
| |
|
|
|
|
| |
|
|
