 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"gramirosimancas" <nomail@nomail> wrote in
news:web.3f4d28bf8f004971d63a77300@news.povray.org:
> Thorsten Froehlich wrote:
[snip]
> In the 2d case where "pyramid raytracing" is used successfully in many
> vector drawing programs and render libs there is an alias removal bost
> while compared to bad libraries that do simple pixel sampling
> (equivalent to 3d raytracing).
> An example library that does this kind of antialiasing in the 2d world
> is http://www.levien.com/libart/
>
> No current antialias method in povray can cope with a simple checker
> surface at any distance while using pyramid raytracing have always best
> results at any distance. If you use a checker structure with a program
> that uses libart you'll see there's no energy lost at any distance (i.e.
> the picture is neither completely black nor completely white.
Although I am far from being qualified to add to this discusion, I would be
very curious to see such a picture.
--
(MIKA) Marc Champagne
marcch.AT.videotron.DOT.ca
Montreal, CANADA
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
just add +d50 to the POV-Ray's command-line and you'll have about the same
results a with using full pixel squares
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Apache" <apa### [at] hotmail com> wrote in
news:3f4d46ac$1@news.povray.org:
> just add +d50 to the POV-Ray's command-line and you'll have about the
> same results a with using full pixel squares
+d is video mode, and I guess most of us are using default of 0,
what does 50 stand for?
I believe video mode will affect only the render windoe and not image
output quality.
I'm scanning the docs, but it may take a while before I find anything.
Thanks
--
(MIKA) Marc Champagne
marcch.AT.videotron.DOT.ca
Montreal, CANADA
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <web.3f4d28bf8f004971d63a77300@news.povray.org>,
"gramirosimancas" <nomail@nomail> wrote:
> >Actually, I don't think you will get any improvement using pyramid tracing.
>
> Theorically you will get _full improvement_ (or _best results_).
You misunderstand the theory. By integrating analytically, you get
results only limited by precision. But analytic forms of the
computations will often be far more computationally expensive, and for
some objects/textures, are simply not possible.
Intersecting a pyramid with a shape gives you a complex volume. Using
this to render an image is tough. You would probably be reduced to
tracing rays against the volume to find the silhouettes of the various
shapes involved and approximate the average color seen. There is no way
it would help with texturing, at least, not with anything like the
texturing POV uses. It's useful for things like audio simulation, and
probably for some specific highly accurate optics computations, but not
for general image rendering. As a way for "perfect antialiasing", I
think you're on the wrong track.
> In the 2d case where "pyramid raytracing" is used successfully in many
> vector drawing programs and render libs there is an alias removal bost
> while compared to bad libraries that do simple pixel sampling (equivalent
> to 3d raytracing).
> An example library that does this kind of antialiasing in the 2d world is
> http://www.levien.com/libart/
This is a *very* different case, involving much simpler mathematics. It
has very little application to 3D projection onto a 2D image.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <web.3f4d2f8a8f004971d63a77300@news.povray.org>,
"gramirosimancas" <nomail@nomail> wrote:
> > You make it sound like pyramid tracing could be possible in the first
> >place.
>
> I have not found any real impediment. It may be just hard.
Impractically hard. It is workable for restricted cases, but not for a
complex and flexible program such as POV.
> What's the problem?
> Just think this way:
> Instead of using a single ray, think the integral over the square pixel.
> Like instead sampling the value of a 1d function you take the integral
> between two sampling points.
You make it sound so simple...but it is far from simple. I find it
extremely unlikely you will ever get any improvement, because you will
end up resorting to sampling far too often.
> What I don't know is if these integrals are analytical in every case, as I
> haven't done any mathematics except in the 2d case where it works with
> lines and splines (but as you know this is much simpler)
Yes, it is much simpler. Try thinking about how it would work in 3D for
a bit. This is *very, very* different!
> You say this would be hard, but you also know this is not impossible.
Right, it's not impossible, if you drop all the "strange" things.
Meaning pretty much all of POV.
Pyramid tracing does not apply to POV.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
gramirosimancas wrote:
> I think it would be like moving from calculating a point to moving to a
> surface integral (with all the boundary cases).
One problem with this approach that occurs to me immediately is that,
depending on how complex a texture is or how many surfaces occur
inside your rectangular area, the surface function might not be
continuous, so integrating might present challenges to say the least.
--
Steve Martin, CPBE CBNT
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <web.3f4d28bf8f004971d63a77300@news.povray.org> ,
"gramirosimancas" <nomail@nomail> wrote:
> I think you are wrong.
>
> In the 2d case where "pyramid raytracing" is used successfully in many
> vector drawing programs and render libs there is an alias removal bost
> while compared to bad libraries that do simple pixel sampling (equivalent
> to 3d raytracing).
> An example library that does this kind of antialiasing in the 2d world is
> http://www.levien.com/libart/
Intersections in two dimensional are relatively easy for the "average" type
of object. However, even for two dimensional geometry, in particular
certain functions, you cannot exactly determine the area even for tiny
subsections.
As far as the three dimensional case is concerned, the equations to
determine the surface area of many of the primitives supported by POV-Ray
are, well, mathematically not even solvable at all. The isosurface object
is ideal to create such functions, but the problem is not limited to this
object type. If you don't believe me, just consider looking into the "tube"
created by one of those functions (from your average math book) that has an
infinite surface area. Now imagine your pyramid is exactly on the tube's
axis...
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <web.3f4d28bf8f004971d63a77300@news.povray.org> ,
"gramirosimancas" <nomail@nomail> wrote:
>>To the contrary, you only end up with extremely difficult intersection
>>algorithms and still have to use some kind of averaging over the surfaces
>>you find as they have textures.
>
> That's the point in using pyramid tracing: "the averaging over the surfaces
> even with textures". I thought you know what is was talking about.
How do you create an average over a sample area you cannot determine? If
you cannot get the surface area, you cannot compute an average. And even if
you can get the surface area, you cannot compute the average color for all
kinds of textures because many of the textures used in POV-Ray have
properties similar to fractals. Not to mention the fractal patterns...
> No current antialias method in povray can cope with a simple checker surface
> at any distance while using pyramid raytracing have always best results at
> any distance. If you use a checker structure with a program that uses
> libart you'll see there's no energy lost at any distance (i.e. the picture
> is neither completely black nor completely white.
No, they can deal with it very well. If you take 256 or more samples per
pixel (using method 1), you will get a correct result for a eight bits per
color component image at the horizon. That is, if the surface pattern is
exactly white and exactly black within the sampled pixel, you will get a 50%
gray pixel result.
Or in short, there is an upper bound for the number of samples you need to
take for any color space resolution in case of the checker pattern.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff <cja### [at] earthlinknet> wrote:
> Right, it's not impossible
I wouldn't say that. There are many problems which are not solvable
analytically. One classical example is modelling the orbits of a three-body
gravitational system: There's no analytical function which would give
you the location of a body at any given time. You have to calculate
it numerically (ie. approximating it iteratively).
In the same way, not all functions/surfaces have an integral. If you
need to integrate over them, you need to make a numerical approximation.
Thus, it might very well be impossible in the general case. (Which means
that there's no other solution but to approximate the real solution by
taking samples.)
Another point is that it's probably not worth the efforts and resources.
--
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3f4e007c@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> Christopher James Huff <cja### [at] earthlinknet> wrote:
> > Right, it's not impossible
>
> I wouldn't say that. There are many problems which are not solvable
> analytically. One classical example is modelling the orbits of a three-body
> gravitational system: There's no analytical function which would give
> you the location of a body at any given time. You have to calculate
> it numerically (ie. approximating it iteratively).
Read the message I was responding too...it talked about solving it
numerically. Actually, read my message: I made it quite clear what I was
saying. Using pyramid tracing may be possible in theory, but would make
things impractically difficult and would have almost zero quality
benefit, since most things would have to be broken down and solved
numerically anyway, and a big impact on rendering speed.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
