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

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

>>> 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

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

>> 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

nemesis <nam### [at] gmailcom> wrote:
> light_source { 3*<1,3,1> 1 area_light x,z,2,2 adaptive 0 jitter }

  That reminds me of a conversation I had in another forum where someone
basically made the claim that if you double the resolution of a video (in
both axes, making each frame have 4 times as many pixels), encoding it to
x264 would require four times as much bitrate in order to preserve the same
quality as the original (because, you know, four times as many pixels equal
four times the needed bitrate).

  I countered that in my experience scaling up the video and then encoding
it requires next to no upscaling of the bitrate in order to preserve the
same visual quality. (Claiming that quadrupling the amount of pixels would
require quadruple amount of bitrate is as silly as claiming that quadrupling
the size of a text file would make it compress to four times the size of the
original text file compressed.)

  He was determined to prove me wrong, so he took an original 256x192 pixels
video (showing gameplay of a console game) and scaled it up to 1600x1200
and encoded it to x264 with the same bitrate (and seemingly without
fine-tuning any other parameters). The end result had slightly more visual
artifacts than the original.

  The original question was whether it would be possible to double the
resolution of the video without enlarging file size, and he "proved" my
affirmative allegation wrong by taking a video and making it over *six*
times larger, resulting in *slightly* more visual artifacts.

  (Amusingly, while he tried to prove my allegation wrong, he inadvertedly
also succeeded in proving wrong the allegation that doubling the video
resolution would require four times as much bitrate to preserve the same
visual quality. He made the video over six times larger and with the same
bitrate there were only slightly more visual artifacts.)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Well, no, I disagree. How do you find the size of an array at runtime? 
> 
>   It's a constant integral value, hence known at runtime.

If you ask for it, the compiler will give you some value that's unassociated 
with the array that happens to contain the size of the array, sure.

>> That's exactly why you have to pass it around along with the pointer.
> 
>   Now you are confusing dynamically allocated arrays with static arrays.
> They are not the same thing.

Not at all. My point is that in many languages, you can ask an array for its 
size, regardless of where you use it. Because of the fact that arrays are 
not first class in C, you cannot talk about an array except where the name 
of the array is in scope. So, in order for a subroutine to know how big is 
the array you've passed in, you have to pass in the size separately.

strcpy() has no way of doing what strncpy() does, and you need an extra 
argument to strncpy() that may or may not be the size of the destination 
array. Hence, there's no way to get the size of an array at runtime.

Certainly C knows the size of a dynamically allocated array at runtime 
*better* than it knows the size of a statically allocated array at runtime.

>> Hmmm... If you put an array in a struct, can you ask 
>> "sizeof(myrecord.thearray)" and get an appropriate size?
> 
>   Yes, actually.
> 
>> I suppose you 
>> could, but still I wouldn't count that as such.
> 
>   "As such"? What? Runtime? sizeof() always works at compile time.

That's what I'm saying. sizeof() works at compile time. Hence, there's no 
way to ask what the size of an array is at runtime, whether it's static or 
not. The only way to get the size of an array is if the *declaration* of the 
array is in scope.

-- 
Darren New, San Diego CA, USA (PST)
   Forget "focus follows mouse." When do
   I get "focus follows gaze"?

Post a reply to this message

I don't want to prove anyone wrong, just pointing out that with 
sufficiently low samples graininess is noticeable in pov's area lights.

Of course pov is several times faster than any unbiased algorithm.  Then 
again, the more light transport phenomena you try to simulate with pov, 
the more it approaches unbiased algorithms "speed".

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

Orchid XP v8 wrote:
> 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.

Arguably that program and POV-Ray do not do the same thing and do not 
give the same results, so comparing both is a bit misleading. POV-Ray 
does not do it in minutes... It does a different, less accurate 
approximation.

-- 
Vincent

Post a reply to this message

Orchid XP v8 escreveu:
> I haven't yet seem a GPU renderer that can render actual curves.

Seemingly there's no such need for them when triangle meshes are so 
flexible, fast and look just the same.  (at the expense of memory)

> Also, 
> can any of these unbiased renderers handle scattering particle media yet?

Why would it not handle?  Lux handles participating media, but just the 
path tracer integrator, not bidir.  Not much used of course because I 
guess it's insanely slow.

BTW, real-time scattering media will be soon enough in games from some 
tech I've seen from Microsoft.

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message