Hi, there!

I wonder how large a povray rendered image can be?

While 1280x1024 fits on an A4-page nicely at 150 dpi, what about renders at 
higher resolutions? What are the limits?

What is the largest image you have rendered and how long did it take?

Post a reply to this message

TC wrote:

> What is the largest image you have rendered and how long did it take?

I've rendered stuff for Zazzle at silly resolutions. (It takes a *long* 
time with a 32-bit CPU.)

Let me go check... Yeah, that was 8,000 x 6,000 pixels.

Post a reply to this message

TC schrieb:
> 
> I wonder how large a povray rendered image can be?
> 
> While 1280x1024 fits on an A4-page nicely at 150 dpi, what about renders at 
> higher resolutions? What are the limits?

Sky's the limit!

Ah well, main memory actually is.

I did a 20,000x10,000 pixels render recently. On my 6-GB 64-bit XP 
machine POV-Ray went unstable, but my 6-GB 64-bit Linux machine did the job.

Note that the output buffer needs 4 bytes per pixel and color channel 
(invariably buffering the data in 32-bit floating point format before 
converting to whatever the output file format holds), for a total of 12 
or 16 bytes per pixel (can't tell off the top of my head whether space 
for an alpha channel is always reserved or not), so the aforementioned 
resolution needs some 2 GB of output buffer alone.

> What is the largest image you have rendered and how long did it take?

Rendering times are too strongly influenced by the scene to make any 
absolute statement here that would help you.

The 20,000x10,000 render, for instance, did take no more than 7 minutes; 
but it was only a montage step to merge two other renders - something 
that would take just a few seconds at "sane" resolutions.

As a rule-of-thumb, expect a render with twice the resolution (i.e. four 
times the pixels) to simply take about four times as long; or, more 
generally, multiplying the resolution by N will multiply your rendering 
times by N^2. Maybe a bit lower I'd guess, as some caching mechanisms 
may become more effective (provided you keep the overall level of detail 
unchanged), but probably not much. Radiosity may actually bog down the 
render more at higher resolution if you set always_sample to on (which 
is generally a bad idea but happens to be the default).


(BTW, why did you post this in povray.off-topic?)

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Sky's the limit!

  Note that many image formats have a limit of 65536x65536 pixels. (I don't
know if PNG has such a limit.)

  As for POV-Ray itself, I bet the limit is 2147483648x2147483648 pixels
(or maybe even 4294967296x4294967296 pixels).

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>   Note that many image formats have a limit of 65536x65536 pixels. (I don't
> know if PNG has such a limit.)

According to the official PNG specification [which I just happen to have 
on my work PC], the size of the image is specified by the IHDR chunk. 
The maximum value for the width and height in pixels is explicitly 
specified to be  2^31 - 1 (even though the fields are 4-byte unsigned 
integers). It is plausible that some programs might incorrectly support 
2^32 - 1 though.

>   As for POV-Ray itself, I bet the limit is 2147483648x2147483648 pixels
> (or maybe even 4294967296x4294967296 pixels).

Any theories on how many GB of RAM would be required to render that? 
(Assuming you turn off the display preview - apparently some people 
don't know you can do this...)

Post a reply to this message

Invisible wrote:
> Any theories on how many GB of RAM would be required to render that?
> (Assuming you turn off the display preview - apparently some people
> don't know you can do this...)

In theory, POV-Ray needs to store (width*2) pixels. libpng may need to store
a bunch more rows at once while compressing.

Post a reply to this message

>> Any theories on how many GB of RAM would be required to render that?
>> (Assuming you turn off the display preview - apparently some people
>> don't know you can do this...)
> 
> In theory, POV-Ray needs to store (width*2) pixels. libpng may need to store
> a bunch more rows at once while compressing.

libpng only needs the current and previous row to run the pixel filter. 
I have no idea what the DEFLATE compressor needs. (Other than a complete 
redesign...) All assuming you're not going to generate interlaced PNG, 
that is.

I note that to store (2^31 - 1) x (2^31 - 1) pixels, where each pixel 
requires exactly 4 bytes, requires about 18 exabytes of storage. (!!)

http://www.wolframalpha.com/input/?i=(2^31+-+1)^2+*+4+bytes

Note: 1 exabyte = 1,000 petabytes = 1,000,000 terabytes (or thereabouts).

Nobody has anything approaching that amount of disk space, never mind RAM.

Also, if POV-Ray achieves a million pixels per second (highly unlikely), 
that gives us...

http://www.wolframalpha.com/input/?i=(2^31+-+1)^2+%2F+1000000+*+1+second

...almost 150 millennia. So it seems pretty moot to me. :-P

Post a reply to this message

Invisible wrote:
> libpng only needs the current and previous row to run the pixel filter.
> I have no idea what the DEFLATE compressor needs. (Other than a complete
> redesign...) All assuming you're not going to generate interlaced PNG,
> that is.

Well, with antialiasing off, it should be possible (in theory) to produce an
interlaced PNG with O(1) memory too. You'd have to modify POV-Ray to
compute the pixels in the same order they're stored in the PNG file.

Post a reply to this message

Warp schrieb:

>   As for POV-Ray itself, I bet the limit is 2147483648x2147483648 pixels
> (or maybe even 4294967296x4294967296 pixels).

On contemporary x64 machines, the limit will be much smaller - some 4e6 
x 4e6 pixels; more than that, and you'll crash through the 256 TeraByte 
address limit (contrary to legend, contemporary x64 processors only 
support 48-bit addresses, despite the architecture being designed for 
future extensibility to full-fledged 64-bit addresses).

Windows will not allow more than some 7e5 x 7e5 pixels (8 TB), while 
Linux will not go beyond some 3e6 x 3e6 pixels (128 TB) due to 
per-process address space limits.

Post a reply to this message

Nicolas Alvarez schrieb:

> In theory, POV-Ray needs to store (width*2) pixels. libpng may need to store
> a bunch more rows at once while compressing.

Hum... yes, for POV-Ray 3.6 this is true. I was thinking of POV-Ray 3.7 
only.

Post a reply to this message

Invisible schrieb:

> So it seems pretty moot to me. :-P

A bit, yes. :-)

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> > In theory, POV-Ray needs to store (width*2) pixels.

  Is that so even if you don't use antialiasing?

> > libpng may need to store
> > a bunch more rows at once while compressing.

> libpng only needs the current and previous row to run the pixel filter. 
> I have no idea what the DEFLATE compressor needs.

  Compression algorithms almost invariably use a buffer for the data, and
this buffer is often surprisingly small (like some tens of kilobytes).
(This means that most compression algorithms will *not* find and compress
repetitions which are gigabytes apart from each other. This is for the
simple reason that the compression routine has to use only a limited amount
of memory and be relatively fast.)

  Some modern algorithms might use larger buffers (like some megabytes),
but they nevertheless don't achieve enormously better compression ratios
(for some reason there seems to be some kind of cutoff point after which
enlarging the compression buffer does not improve the compression of average
data significantly, but slows down the compression more than it's worth).

  The problem with compressing exabytes of data is not the compression
algorithm itself, but the file format into which the compressed data is
stored. (Theoretically if the data is compressed as a stream then there
shouldn't be any theoretical limit to how much data you can compress.
However, if the file format has headers and other data expressing the
amount of compressed data, you may run into limitations.)

> I note that to store (2^31 - 1) x (2^31 - 1) pixels, where each pixel 
> requires exactly 4 bytes, requires about 18 exabytes of storage. (!!)

  Depends on what those pixels contain, and how smart your compression
algorithm is. If the image is completely filled with black pixels, using
a smart compression algorithm could compress it down to some tens of
bytes. (Actual compression algorithms, however, often fail to do this
because of the limited compression buffer. Some of the most naive
algorithms achieve surprisingly poor compression ratios when the input
is full of the same byte value. Other smarter algorithms are more capable
of taking advantage of this.)

  Of course if your image actually contains something meaningful, the
best you can hope to compress (losslessly) is something like to 1/10th
of the original size.

  I don't think many file systems even support files which are exabytes
large.

-- 
                                                          - Warp

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Warp schrieb:

> >   As for POV-Ray itself, I bet the limit is 2147483648x2147483648 pixels
> > (or maybe even 4294967296x4294967296 pixels).

> On contemporary x64 machines, the limit will be much smaller - some 4e6 
> x 4e6 pixels; more than that, and you'll crash through the 256 TeraByte 
> address limit (contrary to legend, contemporary x64 processors only 
> support 48-bit addresses, despite the architecture being designed for 
> future extensibility to full-fledged 64-bit addresses).

> Windows will not allow more than some 7e5 x 7e5 pixels (8 TB), while 
> Linux will not go beyond some 3e6 x 3e6 pixels (128 TB) due to 
> per-process address space limits.

  But those are not limitations of POV-Ray, they are limitations of the
hardware and/or operating system.

  If POV-Ray were to be compiled on a system without those limitations,
it could probably achieve images of those sizes (in theory, of course,
because in practice it would take millenia to render such an image, as
noted elsewhere).

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> clipka <ano### [at] anonymousorg> wrote:
> > Warp schrieb:

> > >   As for POV-Ray itself, I bet the limit is 2147483648x2147483648 pixels
> > > (or maybe even 4294967296x4294967296 pixels).

> > On contemporary x64 machines, the limit will be much smaller - some 4e6 
> > x 4e6 pixels; more than that, and you'll crash through the 256 TeraByte 
> > address limit (contrary to legend, contemporary x64 processors only 
> > support 48-bit addresses, despite the architecture being designed for 
> > future extensibility to full-fledged 64-bit addresses).

> > Windows will not allow more than some 7e5 x 7e5 pixels (8 TB), while 
> > Linux will not go beyond some 3e6 x 3e6 pixels (128 TB) due to 
> > per-process address space limits.

>   But those are not limitations of POV-Ray, they are limitations of the
> hardware and/or operating system.

>   If POV-Ray were to be compiled on a system without those limitations,
> it could probably achieve images of those sizes (in theory, of course,
> because in practice it would take millenia to render such an image, as
> noted elsewhere).

  Actually, thinking about it, you confused me.

  POV-Ray doesn't need to keep the entire image in memory in order to render
it (after all, POV-Ray was developed on systems with limited amount of memory,
yet was able to render images larger than any conceivable RAM size back then).

  Thus it's perfectly possible for POV-Ray to render a 2^31 x 2^31 pixels
large image even on a system which limits memory addresses to be smaller
than that.

  (Of course you won't be able to *save* that image anywhere because you
would encounter limitations in the file system. But that doesn't stop
POV-Ray from *rendering* the image.)

-- 
                                                          - Warp

Post a reply to this message

>> libpng only needs the current and previous row to run the pixel filter.
>> I have no idea what the DEFLATE compressor needs. (Other than a complete
>> redesign...) All assuming you're not going to generate interlaced PNG,
>> that is.
> 
> Well, with antialiasing off, it should be possible (in theory) to produce an
> interlaced PNG with O(1) memory too. You'd have to modify POV-Ray to
> compute the pixels in the same order they're stored in the PNG file.

If you generate a PNG image without any fancy filtering, then you don't 
need any extra memory except for the DEFLATE compressor. But usually PNG 
files use filtering to increase compression. (I don't know, but I'd 
*hope* libpng provides a way to control this...) If filtering, you may 
need the previous row of pixels [only].

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> If you generate a PNG image without any fancy filtering, then you don't 
> need any extra memory except for the DEFLATE compressor. But usually PNG 
> files use filtering to increase compression. (I don't know, but I'd 
> *hope* libpng provides a way to control this...) If filtering, you may 
> need the previous row of pixels [only].

  I think PNG has options to filter with the previous row, the previous
column, or both. I assume that if you choose to filter with the previous
column only, you don't need to store the previous row of pixels in memory
at all. (I don't know if libpng optimizes in this way, but at least in
theory I think it could be possible to implement png compression like that.)

-- 
                                                          - Warp

Post a reply to this message

>> libpng only needs the current and previous row to run the pixel filter. 
>> I have no idea what the DEFLATE compressor needs.
> 
>   Compression algorithms almost invariably use a buffer for the data, and
> this buffer is often surprisingly small (like some tens of kilobytes).
> (This means that most compression algorithms will *not* find and compress
> repetitions which are gigabytes apart from each other. This is for the
> simple reason that the compression routine has to use only a limited amount
> of memory and be relatively fast.)
> 
>   Some modern algorithms might use larger buffers (like some megabytes),
> but they nevertheless don't achieve enormously better compression ratios
> (for some reason there seems to be some kind of cutoff point after which
> enlarging the compression buffer does not improve the compression of average
> data significantly, but slows down the compression more than it's worth).

DEFLATE is ancient. I doubt it needs a lot of space. Most particularly, 
the space required by DEFALTE is *unrelated* to the dimensions of the 
PNG image. The PNG spec says the pixel data is optionally "filtered", 
and then fed to DEFLATE as raw data, which DEFLATE then compresses in 
the usual way.

>   The problem with compressing exabytes of data is not the compression
> algorithm itself, but the file format into which the compressed data is
> stored.

>> I note that to store (2^31 - 1) x (2^31 - 1) pixels, where each pixel 
>> requires exactly 4 bytes, requires about 18 exabytes of storage. (!!)
> 
>   Depends on what those pixels contain, and how smart your compression
> algorithm is.

I was thinking more of the amount of RAM required if you were to store 
the entire thing uncompressed. I would expect any half-decent 
compression algorithm to improve on this significantly.

>   I don't think many file systems even support files which are exabytes
> large.

I agree.

(Maybe Google BigFile or whatever the hell it's called?)

Post a reply to this message

Warp wrote:

>   Thus it's perfectly possible for POV-Ray to render a 2^31 x 2^31 pixels
> large image even on a system which limits memory addresses to be smaller
> than that.
> 
>   (Of course you won't be able to *save* that image anywhere because you
> would encounter limitations in the file system. But that doesn't stop
> POV-Ray from *rendering* the image.)

No - geological time stops you from rendering it. ;-)

Post a reply to this message

Warp wrote:

>   I think PNG has options to filter with the previous row, the previous
> column, or both.

Yes.

Each row can be filtered in one of these ways (or not filtered at all). 
The choice is independent per row.

> I assume that if you choose to filter with the previous
> column only, you don't need to store the previous row of pixels in memory
> at all.

Yes.

> (I don't know if libpng optimizes in this way, but at least in
> theory I think it could be possible to implement png compression like that.)

Indeed - I have no idea if libpng has an option to control this...

Post a reply to this message

Warp wrote:
>   I don't think many file systems even support files which are exabytes
> large.

There are a number that support 2^64 clusters, I think. People are beginning 
to realize that if you actually need more than 2^64 clusters, you're not 
going to want to copy that all over to a new file system when you run out of 
space. :-)

Both NTFS and VFS in theory support up to 8 exabytes on a partition.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Both NTFS and VFS in theory support up to 8 exabytes on a partition.

  Actually wikipedia claims that NTFS supports partitions and files of
16 exabytes. That's a bit better than ReiserFS which supports "only"
8 terabytes.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> If you generate a PNG image without any fancy filtering, then you don't
>> need any extra memory except for the DEFLATE compressor. But usually PNG
>> files use filtering to increase compression. (I don't know, but I'd
>> *hope* libpng provides a way to control this...) If filtering, you may
>> need the previous row of pixels [only].
> 
>   I think PNG has options to filter with the previous row, the previous
> column, or both. I assume that if you choose to filter with the previous
> column only, you don't need to store the previous row of pixels in memory
> at all. (I don't know if libpng optimizes in this way, but at least in
> theory I think it could be possible to implement png compression like
> that.)

You need to store the previous row in POV-Ray anyway, to know if you need to
antialias the current pixel :)

Post a reply to this message

Thank you all for your posts. Quite an insight.

> (BTW, why did you post this in povray.off-topic?)

Because it was just an idle thought. I saw some pov-rendered posters. I then 
pondered upon resolution and pixel-sizes for an A0-poster and wondered how 
far you can realistically go. And how long it would take.

I realize of course that render-time is dependent on the scene to be 
rendered. I just hoped to get to know if render-time behaves proportionally 
to the numer of pixels to be rendered or if render time increases 
exponentially with the number of pixels at really high resolutions.

Do you have any experience?

Furthermore I did not wish to bother anybody with this who might be occupied 
with productive work. Whoever is browsing through povray.off-topic is 
probably somewhat bored and wishes to pass time (probably until the current 
render finishes) ;-)

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailcom> wrote:
> You need to store the previous row in POV-Ray anyway, to know if you need to
> antialias the current pixel :)

  Not in 3.7, which renders one small square at a time.

-- 
                                                          - Warp

Post a reply to this message

Invisible escreveu:
> TC wrote:
> 
>> What is the largest image you have rendered and how long did it take?
> 
> I've rendered stuff for Zazzle at silly resolutions. (It takes a *long* 
> time with a 32-bit CPU.)
> 
> Let me go check... Yeah, that was 8,000 x 6,000 pixels.

That`s truly insane!  Some fractal, I guess?

how about render time?  Days, weeks or months? :)

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

Post a reply to this message

Nicolas Alvarez wrote:

> You need to store the previous row in POV-Ray anyway, to know if you need to
> antialias the current pixel :)

I was under the impression that with AA enabled, *all* pixels are 
supersampled. (But with adaptive supersampling, it shoots 4 rays before 
deciding whether to supersample further...)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

>> Both NTFS and VFS in theory support up to 8 exabytes on a partition.
> 
>   Actually wikipedia claims that NTFS supports partitions and files of
> 16 exabytes. That's a bit better than ReiserFS which supports "only"
> 8 terabytes.

Does this amount of storage actually exist somewhere? (E.g., what kind 
of space does somebody like Google or Amazon have?)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
>>
>>   Actually wikipedia claims that NTFS supports partitions and files of
>> 16 exabytes. That's a bit better than ReiserFS which supports "only"
>> 8 terabytes.
> 
> Does this amount of storage actually exist somewhere? (E.g., what kind
> of space does somebody like Google or Amazon have?)
> 

Well, I have 2 terabytes at home and AFAIK that's not uncommon these
days. Thinking from there, I think Google or Amazon really does have at
least exabytes.

XFS also seems to support 8 exabytes, so I won't have a problem when
upscaling the array some day :p.

-Aero

Post a reply to this message

>> Does this amount of storage actually exist somewhere? (E.g., what kind
>> of space does somebody like Google or Amazon have?)
> 
> Well, I have 2 terabytes at home and AFAIK that's not uncommon these
> days. Thinking from there, I think Google or Amazon really does have at
> least exabytes.

Yes, 1 or 2 TB HDs are on sale if you have the cash.

Note that before you get to exabytes you must first pass through 
petabytes - we're talking about *two* scale units, not just one.

Given that a single drive can hold 1 TB, it's not infeasible that 
somebody could amass 1,000 of those in a data-center somewhere. That 
would give you 1 PB. But 1 EB? Is that really possible yet?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> Nicolas Alvarez wrote:

> > You need to store the previous row in POV-Ray anyway, to know if you need to
> > antialias the current pixel :)

> I was under the impression that with AA enabled, *all* pixels are 
> supersampled. (But with adaptive supersampling, it shoots 4 rays before 
> deciding whether to supersample further...)

  Nope. What do you think the factor after the +a option means?

-- 
                                                          - Warp

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> Given that a single drive can hold 1 TB, it's not infeasible that 
> somebody could amass 1,000 of those in a data-center somewhere. That 
> would give you 1 PB. But 1 EB? Is that really possible yet?

  But that would not be 1 petabyte as one partition. It would be 1 petabyte
of disk storage in total, among many smaller drives/partitions.

-- 
                                                          - Warp

Post a reply to this message

>> I was under the impression that with AA enabled, *all* pixels are 
>> supersampled. (But with adaptive supersampling, it shoots 4 rays before 
>> deciding whether to supersample further...)
> 
>   Nope. What do you think the factor after the +a option means?

The threshold for deciding whether or not to subdivide further...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Warp wrote:
> Orchid XP v8 <voi### [at] devnull> wrote:
>> Given that a single drive can hold 1 TB, it's not infeasible that 
>> somebody could amass 1,000 of those in a data-center somewhere. That 
>> would give you 1 PB. But 1 EB? Is that really possible yet?
> 
>   But that would not be 1 petabyte as one partition. It would be 1 petabyte
> of disk storage in total, among many smaller drives/partitions.

...unless you can find a RAID controller that supports 1,000 array 
elements. o_O

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> >> I was under the impression that with AA enabled, *all* pixels are 
> >> supersampled. (But with adaptive supersampling, it shoots 4 rays before 
> >> deciding whether to supersample further...)
> > 
> >   Nope. What do you think the factor after the +a option means?

> The threshold for deciding whether or not to subdivide further...

  No, it's the threshold for starting antialiasing in the first place.
The comparison is against neighbour pixels.

-- 
                                                          - Warp

Post a reply to this message

Warp schrieb:

>   If POV-Ray were to be compiled on a system without those limitations,
> it could probably achieve images of those sizes

even then, 2e9 x 2e9 wouldn't quite be reached (unless you'd have a >64 
bit system), some 1e9 x 1e9 would be the limit then.

(Again, speaking of POV-Ray 3.7. I don't think anyone would want to 
render such a big image without multiprocessor support ;-))

Post a reply to this message

Warp wrote:
> Orchid XP v8 <voi### [at] devnull> wrote:
>>>> I was under the impression that with AA enabled, *all* pixels are 
>>>> supersampled. (But with adaptive supersampling, it shoots 4 rays before 
>>>> deciding whether to supersample further...)
>>>   Nope. What do you think the factor after the +a option means?
> 
>> The threshold for deciding whether or not to subdivide further...
> 
>   No, it's the threshold for starting antialiasing in the first place.
> The comparison is against neighbour pixels.

OK, I didn't know that...

So yes, POV-Ray will need to buffer some of the neighboring pixels. :-}

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Warp schrieb:
> 
>   Actually, thinking about it, you confused me.
> 
>   POV-Ray doesn't need to keep the entire image in memory in order to render
> it (after all, POV-Ray was developed on systems with limited amount of memory,
> yet was able to render images larger than any conceivable RAM size back then).

I'm too much involved in 3.7 development to have 3.6 anywhere on the 
radar ;-)

At present, the architecture of POV-Ray 3.7 does not allow for writing 
image output before rendering has actually finished, so the whole smash 
must be buffered.


>   (Of course you won't be able to *save* that image anywhere because you
> would encounter limitations in the file system. But that doesn't stop
> POV-Ray from *rendering* the image.)

You'd probably have to disable preview as well :-)

Post a reply to this message

TC schrieb:

> I realize of course that render-time is dependent on the scene to be 
> rendered. I just hoped to get to know if render-time behaves proportionally 
> to the numer of pixels to be rendered or if render time increases 
> exponentially with the number of pixels at really high resolutions.
> 
> Do you have any experience?

So far, I haven't seen any significant exceptions to the rule-of-thumb 
that render time is proportional to the number of pixels.

Post a reply to this message

clipka wrote:

> So far, I haven't seen any significant exceptions to the rule-of-thumb 
> that render time is proportional to the number of pixels.

...not forgetting that there are scenes where the parse-time dwarfs the 
render-time. ;-)

(And then there's things like radiosity pre-trace, photon mapping, etc.)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
> Does this amount of storage actually exist somewhere? (E.g., what kind 
> of space does somebody like Google or Amazon have?)

I'd guess maybe about a million drives with maybe 250G each, tops? I'd read 
somewhere they had a half-million computers, and they all use commodity 160G 
drives, so something like that. What does that turn out to? 250 peta bytes?



-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Warp wrote:
>   But that would not be 1 petabyte as one partition. It would be 1 petabyte
> of disk storage in total, among many smaller drives/partitions.

One partition spread amongst many disks. :-)  Actually, I think Windows 
calls it a "volume", while a partition is part of a disk, a volume holds a 
file system.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Orchid XP v8 wrote:
> ...not forgetting that there are scenes where the parse-time dwarfs the 
> render-time. ;-)

But probably not on an 8000x3000 resolution picture. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

On Thu, 22 Oct 2009 13:57:41 -0700, Darren New wrote:

> Orchid XP v8 wrote:
>> Does this amount of storage actually exist somewhere? (E.g., what kind
>> of space does somebody like Google or Amazon have?)
> 
> I'd guess maybe about a million drives with maybe 250G each, tops? I'd
> read somewhere they had a half-million computers, and they all use
> commodity 160G drives, so something like that. What does that turn out
> to? 250 peta bytes?

There was an article recently about someone at Google talking about 
needing to manage 10 million machines....

Jim

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> So far, I haven't seen any significant exceptions to the rule-of-thumb 
> that render time is proportional to the number of pixels.

  I'm sure once could artificially construct a scene which renders fast
at one resolution but extremely slow if you make the resolution even
slightly larger (by having some extremely-slow-to-render detail be so
small that no ray hits it at the lower resolution).

-- 
                                                          - Warp

Post a reply to this message

Jim Henderson wrote:
> There was an article recently about someone at Google talking about 
> needing to manage 10 million machines....

Your numbers are probably closer to mine, assuming it wasn't a "we plan 
systems in ways that we can manage 10 million, even tho at the moment we 
have only 1." :-)  My numbers are old and estimated from outside the company.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Warp schrieb:

>   I'm sure once could artificially construct a scene which renders fast
> at one resolution but extremely slow if you make the resolution even
> slightly larger (by having some extremely-slow-to-render detail be so
> small that no ray hits it at the lower resolution).

On average, that will not change a thing. So you'd have to make the 
detail not only particularly small, but also place it strategically.

But a scene coded so that the detail level is driven by the image_height 
and image_width variables would do - which would even make sense in some 
cases, especially for fractal geometry.

Post a reply to this message

On Thu, 22 Oct 2009 17:25:56 -0700, Darren New wrote:

> Jim Henderson wrote:
>> There was an article recently about someone at Google talking about
>> needing to manage 10 million machines....
> 
> Your numbers are probably closer to mine, assuming it wasn't a "we plan
> systems in ways that we can manage 10 million, even tho at the moment we
> have only 1." :-)  My numbers are old and estimated from outside the
> company.

I think it might've actually been something along those lines, actually - 
I'll have to see if I can find the reference again.

Jim

Post a reply to this message

> But a scene coded so that the detail level is driven by the image_height 
> and image_width variables would do - which would even make sense in some 
> cases, especially for fractal geometry.

Doesn't the detail level change automatically with image_width / 
image_height?

A texture should produce a higher level of detail automatically.

Or do you mean something like #NoOfTreesToPlant= image_width*image_height / 
AnyReasonableNumber?

Can image_width be accessed in povray?

Post a reply to this message

>> I've rendered stuff for Zazzle at silly resolutions. (It takes a 
>> *long* time with a 32-bit CPU.)
>>
>> Let me go check... Yeah, that was 8,000 x 6,000 pixels.
> 
> That`s truly insane!  Some fractal, I guess?

Nah, just some marbles.

In fact:

http://www.zazzle.com/marbles_print-228982257548484115

Also:

http://www.zazzle.com/mist_print-228771069264566889

> how about render time?  Days, weeks or months? :)

I think it took about a day. It's a pretty simple scene...

Post a reply to this message

TC schrieb:

> Doesn't the detail level change automatically with image_width / 
> image_height?
> 
> A texture should produce a higher level of detail automatically.

Procedural textures, as used by POV-Ray, inherently provide unlimited 
detail anyway, regardless of resolution.

> Or do you mean something like #NoOfTreesToPlant= image_width*image_height / 
> AnyReasonableNumber?

Yes, something along those lines.

> Can image_width be accessed in povray? 

Yes, of course. It is commonly used to make sure the camera parameters 
match the output image aspect ratio, as in:

   camera {
     ...
     up    y
     right x*image_width/image_height
   }

but it can be used for any other purpose you deem fit.

Post a reply to this message