 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I don't know if any of you have seen this link or not, I found it at the
Povray website. The page explains some new Monte Carlo lighting model,
the results of which look very nice. Look at the light under the door on
the image there!
--
Samuel Benge
E-Mail: STB### [at] aol com
Visit the still unfinished isosurface tutorial:
http://members.aol.com/stbenge
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"SamuelT." wrote:
>
> I don't know if any of you have seen this link or not, I found it at the
> Povray website. The page explains some new Monte Carlo lighting model,
> the results of which look very nice. Look at the light under the door on
> the image there!
You mean this one ?
http://graphics.stanford.edu/papers/metro/
--
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Whoops! Thanks Ken! That's what I get for quitting the caffeine :)
Ken wrote:
> "SamuelT." wrote:
> >
> > I don't know if any of you have seen this link or not, I found it at the
> > Povray website. The page explains some new Monte Carlo lighting model,
> > the results of which look very nice. Look at the light under the door on
> > the image there!
>
> You mean this one ?
>
> http://graphics.stanford.edu/papers/metro/
>
> --
> Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
> http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
--
Samuel Benge
E-Mail: STB### [at] aolcom
Visit the still unfinished isosurface tutorial: http://members.aol.com/stbenge
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>
>http://graphics.stanford.edu/papers/metro/
Hm... is it possible that this will be implemented in Povray?!
Simen.
>
>--
>Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
>http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Simen Kvaal wrote:
>
> >
> >http://graphics.stanford.edu/papers/metro/
>
> Hm... is it possible that this will be implemented in Povray?!
I heard a couple of Team members mention that it looked interesting.
I guess it remains to be seen whether the process is compatible with
the programs current structure and if it will offer any advantages
of the current methods being employed, that and someone to write
the code.
--
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 08 May 2000 01:07:03 -0700, Ken wrote:
>
>
>Simen Kvaal wrote:
>>
>> >
>> >http://graphics.stanford.edu/papers/metro/
>>
>> Hm... is it possible that this will be implemented in Povray?!
>
>I heard a couple of Team members mention that it looked interesting.
>I guess it remains to be seen whether the process is compatible with
>the programs current structure and if it will offer any advantages
>of the current methods being employed, that and someone to write
>the code.
I think it looks interesting, but the last time I read it (over a year ago,
so I might be remembering incorrectly) it appeared that it is fundamentally
incompatible with the POV notion of rendering everything from top to bottom,
left to right. I believe a fundamental part of its function is that it
generates pixels in completely random order.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
These are my opinions. I do NOT speak for the POV-Team.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8 May 2000 09:44:15 -0400, ron### [at] povrayorg (Ron Parker)
wrote:
>I believe a fundamental part of its function is that it
>generates pixels in completely random order.
Would this be completely impossible to meld with POV-Ray? I know it
would certainly be a complication, but it still might be possible. I
guess the main questions are whether this technique is so much better
in either quality or speed to make it worth the extra trouble.
Does anyone really know how accurate or speedy this type of radiosity
is, compared to that in Mega-POV? Can we find out?
Later,
Glen Berry
( Remove the "7" from 7no### [at] ezwvcom to email me. )
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Glen Berry <7no### [at] ezwvcom> wrote in message
<9QoXOX81ZhACXmHd2iIS2wGK67Tm@4ax.com>...
>On 8 May 2000 09:44:15 -0400, ron### [at] povrayorg (Ron Parker)
>wrote:
>
>>I believe a fundamental part of its function is that it
>>generates pixels in completely random order.
>
>Would this be completely impossible to meld with POV-Ray? I know it
>would certainly be a complication, but it still might be possible. I
>guess the main questions are whether this technique is so much better
>in either quality or speed to make it worth the extra trouble.
I've been working on getting POV to render images in random order, and the
problems I've run into are:
1) Antialiasing method 1: Random order means that the program can't compare
the color of the current pixel to the colors of the neighboring pixels when
it is rendered. The solution I'm going to use is to do an antialiasing pass
through the image after the first rendering pass is complete.
2) Antialiasing method 2: Random render order means it will be difficult to
re-use the data from previously-rendered pixels, slowing rendering down.
3) Saving in any of the compressed file formats: All of the supported
compressed formats expect pixel data to be provided in top-to-bottom,
left-to-right order. The workaround I plan to use is to save the file in
uncompressed TGA, then compress the file into the final format once
rendering is completed.
4) Continued tracing: POV normally determines where to continue rendering
from by finding the first line in the image file that ends with a black
pixel. With a random rendering order, many lines will end with black
pixels. My solution is to record which pixel was rendered last in the image
file. This pixel is then used to determine which pixel to render next.
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 17 May 2000 01:29:43 -0400, "Mark Wagner"
<mar### [at] gtenet> wrote:
>I've been working on getting POV to render images in random order, and the
>problems I've run into are:
>1) Antialiasing method 1: Random order means that the program can't compare
>the color of the current pixel to the colors of the neighboring pixels when
>it is rendered. The solution I'm going to use is to do an antialiasing pass
^^^^^^^^^^^^^^^^^^^^
>through the image after the first rendering pass is complete.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Amen brother!
>4) Continued tracing: POV normally determines where to continue rendering
>from by finding the first line in the image file that ends with a black
>pixel. With a random rendering order, many lines will end with black
>pixels. My solution is to record which pixel was rendered last in the image
>file. This pixel is then used to determine which pixel to render next.
You'll have to remember the seed as well (but you already know that,
don't you :) )
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usanet
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Peter Popov wrote in message ...
>>4) Continued tracing: POV normally determines where to continue rendering
>>from by finding the first line in the image file that ends with a black
>>pixel. With a random rendering order, many lines will end with black
>>pixels. My solution is to record which pixel was rendered last in the
image
>>file. This pixel is then used to determine which pixel to render next.
>
>You'll have to remember the seed as well (but you already know that,
>don't you :) )
Actually, the way I'm doing it, the pixel IS the seed!
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
