|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 30/09/14 19:44, clipka wrote:
>
> I guess that in this case Turing is actually the one to turn to: I
> suspect that the problem of figuring out the time it takes to render a
> POV-Ray scene is in the same ballpark as the halting problem.
>
That was my first instinct. However I considered that Knuth might be
more readable (and he gives examples)
>
> What Knuth might(*) tell you is the efficiency of the various
> optimizations implemented in POV-Ray, and also guesstimates for
> comparatively simple scenes; but the more complex a scene gets, the more
> complex the formula for estimating the runtime will get, and the more
> the error margins will add up, to the point where you have an answer
> that consists of error margins only. (An answer like "1 hour, give or
> take 5 days" doesn't really help, does it ;-))
Oh, I don't know :-) For some reports we read about here, that seems
fairly precise.
>
> (*) Actually, the old-school analysis of execution time is pretty
> outdated anyway,
Yeah, but so am I - I'm still getting to grips with broadband :-D
John
--
Protect the Earth
It was not given to you by your parents
You hold it in trust for your children
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I was wondering if anyone (up to and including developers) knew any way to work
> out how much CPU work/time would be needed to render an image based on its size
> and render options. It seems like it must be possible to find out.
> Thanks,
> Ross
>
>
Hardly possible.
In some cases, simply moving the camera, a light or an object by a
/tiny/ amount can make a huge difference. The same can appen with any
rotation.
Have a transparent object with any ior different than 1? Changing the
ior by 0.01 may cause a significant render time change. It may cause
tons of total internal reflections.
Use blured reflection using averaged normals? What if, in one render,
you now have some large areas with multiple inter-reflection of those
blured surfaces...
You may have a case where adding just one object cause you to exeed the
available RAM and plunge you into swapping hell.
A small, very simple scene can take ages to render, while a very
complexe and huge one can render in minutes, once the parsing is finished.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2014-10-01 18:57, Alain wrote:
> A small, very simple scene can take ages to render, while a very
> complexe and huge one can render in minutes, once the parsing is finished.
Predicting CPU work needed isn't impossible, it just takes exactly the
same length of time as rendering the scene.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 29 Sep 2014 11:31:31 EDT, "cloudyroo" <nomail@nomail> wrote:
>I was wondering if anyone (up to and including developers) knew any way to work
>out how much CPU work/time would be needed to render an image based on its size
>and render options. It seems like it must be possible to find out.
>Thanks,
>Ross
>
Perhaps it could be "roughly estimated" with a mosaic preview, and
adjusting that "roughness estimation" as the mosaic preview gets more
final image pixels rendered.
But without rendering real image pixels I think it's nearly
impossible.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|