![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Invisible
Subject: Re: 99 lines of C++ for an unbiased ray tracer
Date: 15 Jan 2010 11:50:39
Message: <4b509cdf@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> That image is the result of 30 minutes of
> rendering in my computer (a virtually grainless result would have taken
> days).
Or a GPU implementation...
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp escreveu:
> nemesis <nam### [at] gmail com> wrote:
>>>>> http://warp.povusers.org/images/smallpt.jpg
>>>> did you make it coincident with the surface?
>>> I have hard time deciding whether that was humorous or a serious question.
>
>> serious. Did you put right where the left sphere surface would hit?
>
> Unbiased monte-carlo rendering sends rays in a random fashion. It starts
> extremely grainy, but the graininess gets reduced over time as the number
> of samples gets increased. That image is the result of 30 minutes of
> rendering in my computer (a virtually grainless result would have taken
> days).
I know. I'm concerned about that huge circular, pure white light
artifact next to the wall, aren't you? Looks like a bug, which is why I
thought you posted the picture.
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: nemesis
Subject: Re: 99 lines of C++ for an unbiased ray tracer
Date: 15 Jan 2010 11:53:04
Message: <4b509d70@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp escreveu:
> That image is the result of 30 minutes of
> rendering in my computer (a virtually grainless result would have taken
> days).
and no, you don't need days to get grainless result anymore than what
you would need with povray and area lights and radiosity. Specially for
such a simple scene. Though a pure simplified path tracer is very slow.
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
nemesis wrote:
> I know. I'm concerned about that huge circular, pure white light
> artifact next to the wall, aren't you? Looks like a bug, which is why I
> thought you posted the picture.
It's a light source. It's what illuminates the rest of the scene.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Invisible
Subject: Re: 99 lines of C++ for an unbiased ray tracer
Date: 15 Jan 2010 11:58:01
Message: <4b509e99@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
nemesis wrote:
> and no, you don't need days to get grainless result anymore than what
> you would need with povray and area lights and radiosity.
Er, no, POV-Ray uses an utterly different algorithm for this. In
particular, it uses a shedload of statistical tests to reduce the number
of samples taken. *This* program just endlessly resamples everything
until all the randomness averages out; this is orders of magnitude slower.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: nemesis
Subject: Re: 99 lines of C++ for an unbiased ray tracer
Date: 15 Jan 2010 12:25:14
Message: <4b50a4fa@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible escreveu:
> nemesis wrote:
>
>> I know. I'm concerned about that huge circular, pure white light
>> artifact next to the wall, aren't you? Looks like a bug, which is why
>> I thought you posted the picture.
>
> It's a light source. It's what illuminates the rest of the scene.
oh good. I thought it was a ghost. silly me.
really, this topic went surreal by now...
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible escreveu:
> nemesis wrote:
>
>> and no, you don't need days to get grainless result anymore than what
>> you would need with povray and area lights and radiosity.
>
> Er, no, POV-Ray uses an utterly different algorithm for this. In
> particular, it uses a shedload of statistical tests to reduce the number
> of samples taken.
Povray still shows a lot of graininess for insuficient samples. Lots of
samples still get very slow rendering.
> *This* program just endlessly resamples everything
> until all the randomness averages out; this is orders of magnitude slower.
But that's for a pure simple path tracer. There are far smarter
samplers out there, most notably Metropolis Light Transport, that are
able to converge the image much faster.
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>>> and no, you don't need days to get grainless result anymore than what
>>> you would need with povray and area lights and radiosity.
>>
>> Er, no, POV-Ray uses an utterly different algorithm for this. In
>> particular, it uses a shedload of statistical tests to reduce the
>> number of samples taken.
>
> Povray still shows a lot of graininess for insuficient samples. Lots of
> samples still get very slow rendering.
It doesn't show graininess, it shows patchiness. Because it reuses a
single sample for multiple pixels. That means it needs to take about one
millionth of the number of samples that this program takes. Hence, a
*slight* speed difference.
>> *This* program just endlessly resamples everything until all the
>> randomness averages out; this is orders of magnitude slower.
>
> But that's for a pure simple path tracer. There are far smarter
> samplers out there, most notably Metropolis Light Transport, that are
> able to converge the image much faster.
...which still has nothing to do with *this* program.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: nemesis
Subject: Re: 99 lines of C++ for an unbiased ray tracer
Date: 15 Jan 2010 13:37:37
Message: <4b50b5f1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Orchid XP v8 escreveu:
>>>> and no, you don't need days to get grainless result anymore than
>>>> what you would need with povray and area lights and radiosity.
>>>
>>> Er, no, POV-Ray uses an utterly different algorithm for this. In
>>> particular, it uses a shedload of statistical tests to reduce the
>>> number of samples taken.
>>
>> Povray still shows a lot of graininess for insuficient samples. Lots
>> of samples still get very slow rendering.
>
> It doesn't show graininess, it shows patchiness.
#default {pigment { rgb .8 } finish { ambient .2 diffuse .8 }}
union {
plane { y 0 }
sphere { <2,1> 1 }
sphere { <-2,2> 2 }
light_source { 3*<1,3,1> 1 area_light x,z,2,2 adaptive 0 jitter }
light_source { 3*<-3,1,-2> .5 area_light x,z,2,2 adaptive 0 jitter }
rotate y*40
rotate -x*30
translate <0,-1,8>
}
plenty of graininess in the shadow edges. And, yes, plenty of
patchiness as for radiosity if used with few samples.
> Because it reuses a
> single sample for multiple pixels. That means it needs to take about one
> millionth of the number of samples that this program takes. Hence, a
> *slight* speed difference.
Which will mean nothing if it doesn't move on to GPU like everyone else
and begins eating dust for such slow and more realistic renderers.
> ...which still has nothing to do with *this* program.
ah, I thought you were talking about unbiased renderers in general.
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> Because it reuses a single sample for multiple pixels. That means it
>> needs to take about one millionth of the number of samples that this
>> program takes. Hence, a *slight* speed difference.
>
> Which will mean nothing if it doesn't move on to GPU like everyone else
> and begins eating dust for such slow and more realistic renderers.
The GPU has been producing graphics far faster than POV-Ray for decades.
It's only now that it can start to do the sorts of things that POV-Ray
can do.
I haven't yet seem a GPU renderer that can render actual curves. Also,
can any of these unbiased renderers handle scattering particle media yet?
>> ...which still has nothing to do with *this* program.
>
> ah, I thought you were talking about unbiased renderers in general.
No, I was just pointing out that this particular program may take many
hours to render something that POV-Ray does in minutes because POV-Ray
uses a totally different algorithm.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |