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

"TC" <do-not-reply@i-do get-enough-spam-already-2498.com> wrote:
> 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?

I think it was 24000x16000 , can't remember how long it took, though. But
possibly no longer than 30 hours. I have rendered 20000x15000 images quite a few
times (rendertime between 8 and about 25 hours, I think). I do not need them
exactly in that size, but sometimes I only need a part of the image (because
there is much free space around the objects which renders fast of course) and I
sometimes don't know how to put the camera so that it's zoomed in while
maintaining the exactly same perspective. So I cut a part off the image of
later. Another reason for the big images is, that sometimes the antialiazing is
not good enough, so I resize it to a smaller size with a graphics program after
rendering which is much quicker and IMHO even looks better than using a better
antialiasing and time consuming AA setting in POV.
When I use some focal blur I always render the image 2-3 times bigger than I
need with low quality settings, and then downsize it later, because the focal
blur gets more smudged and realistic, I think.
I wouldn't render images in such size with any media or such, because that takes
so long even for small images.
I always have to switch display=off when the image size is more than about
12000x9000 because of the lack of RAM.

I have not much experience with radiosity. If I recollect it correctly the
calculated values are somehow attached to the object and can be stored in a
file? So it possibly doesn't matter much when the image size is increased with
radiosity? Maybe the experts can say more about this :).

When estimating the total render time it also helps me a lot to render some
sample regions (with this "render region" option) both with many objects and
less, and then dividing the final (planned) resolution by the average pps and
again by 3600 which then gives the supposed total render time in hours.


Regards,

Simone

Post a reply to this message

mone schrieb:

> I have not much experience with radiosity. If I recollect it correctly the
> calculated values are somehow attached to the object and can be stored in a
> file? So it possibly doesn't matter much when the image size is increased with
> radiosity? Maybe the experts can say more about this :).

In a perfect world, all radiosity samples you ever need would be 
gathered during radiosity pretrace, which is basically independent of 
screen resolution.

In practice, most people don't set the radiosity parameters high enough 
to have pretrace do a good enough job; in that case, a high-res image 
may add more samples during final trace than a low-res image.

OTOH, even the number of additional samples during final trace just 
grows linearly with the number of pixels.

Another effect that needs to be considered is radiosity sample lookup 
during the final render; in an ideal world the time spent on this would 
increase roughly linearly with number of pixels; however, due to a 
high-res image usually generating more radiosity samples in total, the 
per-pixel time spent on looking up radiosity samples will increase, so 
the total time spent on sample lookup will increase nonlinearly.

All in all, however, I guess time required for radiosity will increase 
sub-linearly with number of pixels in practice, due to pretrace time 
remaining basically unchanged (unless you change radiosity parameters).

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> mone schrieb:
>
> > I have not much experience with radiosity. If I recollect it correctly the
> > calculated values are somehow attached to the object and can be stored in a
> > file? So it possibly doesn't matter much when the image size is increased with
> > radiosity? Maybe the experts can say more about this :).
>
> In a perfect world, all radiosity samples you ever need would be
> gathered during radiosity pretrace, which is basically independent of
> screen resolution.
>
> In practice, most people don't set the radiosity parameters high enough
> to have pretrace do a good enough job; in that case, a high-res image
> may add more samples during final trace than a low-res image.
>

I see. So as a rule of thumb it would be good to use the save_file/load_file
options together with high quality parameters for a low-res image, so the
sampled data can be used again for the high-res image?

Regards,

Simone

Post a reply to this message

mone schrieb:

> I see. So as a rule of thumb it would be good to use the save_file/load_file
> options together with high quality parameters for a low-res image, so the
> sampled data can be used again for the high-res image?

That depends.

Just rendering the scene at low resolution with save_file, and then 
rendering it at high resolution with load_file, will give you not much 
of an advantage; to the contrary: You'll just force POV-Ray to run the 
main render twice (though at low resolution the first time).

It only pays off in case you can somehow manage to simplify the scene in 
a manner that does not affect radiosity calculation much; good 
candidates for this would be minor media  effects, micronormals for 
slightly blurred reflections, or low-res versions of textures. (Make 
sure not to change any actual geometry though.) In that case it's worth 
running the radiosity pretrace with this simplified scene, with low 
resolution to not waste much time on the not-really-main render; for the 
final render, you can then get away with a single, very coarse pretrace 
(IIRC POV-Ray always does at least one pretrace pass, even if you load 
previously generated data).

(Note that with POV-Ray 3.7, the syntax for saving and loading radiosity 
data has changed.)

Post a reply to this message

> It only pays off in case you can somehow manage to simplify the scene in
> a manner that does not affect radiosity calculation much; good
> candidates for this would be minor media  effects, micronormals for
> slightly blurred reflections, or low-res versions of textures. (Make
> sure not to change any actual geometry though.) In that case it's worth
> running the radiosity pretrace with this simplified scene, with low
> resolution to not waste much time on the not-really-main render; for the
> final render, you can then get away with a single, very coarse pretrace
> (IIRC POV-Ray always does at least one pretrace pass, even if you load
> previously generated data).

Ok, Thanks. I hopefully have understood most of it :). I'll keep this in mind
next time when I want to render a high-res radiosity scene.

Regards,

Simone

Post a reply to this message

> I always have to switch display=off when the image size is more than about
> 12000x9000 because of the lack of RAM.

It seems to me like once you try to render at 27000x27000 or above with the 
preview, the POV core crashes and then the preview window shows 
"StretchDIBits() failed!" instead of any image.  POV is then crashed and you 
have use task manager to kill it.

Post a reply to this message