![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/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 <nam### [at] gmail com> 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
|
![](/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 wrote:
> Darren New <dne### [at] san rr com> 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/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Vincent Le Chevalier
Subject: Re: 99 lines of C++ for an unbiased ray tracer
Date: 15 Jan 2010 14:48:58
Message: <4b50c6aa$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/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 15:03:58
Message: <4b50ca2e@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |