 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 14 Feb 2002 02:44:09 -0500, "Timothy R. Cook"
<tim### [at] scifi-fantasy com> 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
|
|
| |
| |
|
|
|
|
| |
|
|
