 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote:
My car needs washing.
I'll leave the Palmolive(R) by the curb,
but you'll have to bring your own water.
dik
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron, my images lack originality. Please fix this ASAP...
Margus
Ken wrote:
>
> TonyB wrote:
>
> > Can you do something about rendering times? I really would like to see at
> > least a 50% increase there. ;)
>
> And Ron while you are at it could you please get Pov to read those
> 30 meg triangle mesh files off of my old seagate mfm hard drive faster
> than it is now ?
>
> Thanks bunch,
>
> --
> Ken Tyler
>
> mailto://tylereng@pacbell.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 03 Jul 1999 03:50:17 +0300, Margus Ramst <mar### [at] peak eduee>
wrote:
>Ron, my images lack originality. Please fix this ASAP...
>
>Margus
>
Ron,
I need to add one more item to your list of things to do: Be sure to
have a happy July 4th weekend! :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
TonyB wrote:
>
> BTW, I remember somebody mentioned that the thingy that reports the PPS
> (+AM2) is buggy, can you get that done?
>
Perhaps this is an old story but what would be really helpful is an estimate of
the rendertime left. That could be updated on each row, for instance.
I've made a (tiny) standalone program to calculate this but actually that is
rather silly.
Remco
http://www.xs4all.nl/~remcodek/vic.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
It wouldn't be very meaningful, since speed may vary greatly over different
sections of the image. Only way I can imagine would be to render the image with
progressive refinement, i.e. render ever Nth line, then every (N/2)th line etc.
I'm not sure how easy this would be.
Margus
Remco de Korte wrote:
>
> TonyB wrote:
> >
> > BTW, I remember somebody mentioned that the thingy that reports the PPS
> > (+AM2) is buggy, can you get that done?
> >
> Perhaps this is an old story but what would be really helpful is an estimate of
> the rendertime left. That could be updated on each row, for instance.
> I've made a (tiny) standalone program to calculate this but actually that is
> rather silly.
>
> Remco
> http://www.xs4all.nl/~remcodek/vic.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 02 Jul 1999 14:47:29 -0400, TonyB
<ben### [at] panamaphoenixnet> wrote:
>> as a bonus, I'll throw in my 75% speedup for layered crackle textures at
>> no extra charge.
>
>Can you do something about rendering times? I really would like to see at
>least a 50% increase there. ;)
I got you a 75% decrease on rendering time if you use layered crackle
textures. What more do you want? :)
>BTW, I remember somebody mentioned that the thingy that reports the PPS
>(+AM2) is buggy, can you get that done?
The POV-Team has a patch for this. I don't know if it will make it
into the 3.1g Windows release or not. Even if it doesn't, I'll make a
mental note to fix it in the superpatch.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Margus Ramst wrote:
>
> It wouldn't be very meaningful, since speed may vary greatly over different
> sections of the image. Only way I can imagine would be to render the image with
> progressive refinement, i.e. render ever Nth line, then every (N/2)th line etc.
> I'm not sure how easy this would be.
>
> Margus
I don't agree. It's quite meaningful to me to see whether a render will be
finished the same day or two days later. That's something you can calculate for
yourself, which is what I'm doing now, but POV has the data already at hand.
This would be even more meaningful with animations.
You could use a straightforward calculation (based on PPS) or a more advanced
one (based on a series of PPS-data).
So long,
Remco
http://www.xs4all.nl/~remcodek/vic.html
>
> Remco de Korte wrote:
> >
> > TonyB wrote:
> > >
> > > BTW, I remember somebody mentioned that the thingy that reports the PPS
> > > (+AM2) is buggy, can you get that done?
> > >
> > Perhaps this is an old story but what would be really helpful is an estimate of
> > the rendertime left. That could be updated on each row, for instance.
> > I've made a (tiny) standalone program to calculate this but actually that is
> > rather silly.
> >
> > Remco
> > http://www.xs4all.nl/~remcodek/vic.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I got you a 75% decrease on rendering time if you use layered crackle
> textures. What more do you want? :)
=) Can you give a small explanation on how you got this speed increase? (black
magic, voodoo and/or miracles don't count).
> The POV-Team has a patch for this. I don't know if it will make it
> into the 3.1g Windows release or not. Even if it doesn't, I'll make a
> mental note to fix it in the superpatch.
How come the Team doesn't mention these things? Oh, and thank you Mr. Parker,
I'm looking forward to getting my PPS correctly reported. =)
--
Anthony L. Bennett
http://welcome.to/TonyB
Graphics rendered
by the Dreamachine.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In most cases it would give a general time frame, but an experienced user can
probably guess it more accurately himself. Extreme cases are not rare in POV
renderings. A small part of the image may take up most of the time. Linear PPS
calculation (or even one based on previous data) can _not_ take this into
account. And POV can't predict the number of rays it has to trace for a
particular pixel or line.
Like I said, a progressive histogram approach might do the trick. It would hold
the added advantage of showing a progressively refined preview of the entire
scene before rendering is done. I would certainly consider this an useful
option.
Adding render time calculation based on time spent & PPS should be trivial. I
can only guess, but perhaps the very reason it hasn't been done already is the
inaccuracy of this method in raytraced scenes.
Margus
Remco de Korte wrote:
>
> I don't agree. It's quite meaningful to me to see whether a render will be
> finished the same day or two days later. That's something you can calculate for
> yourself, which is what I'm doing now, but POV has the data already at hand.
> This would be even more meaningful with animations.
> You could use a straightforward calculation (based on PPS) or a more advanced
> one (based on a series of PPS-data).
>
> So long,
>
> Remco
> http://www.xs4all.nl/~remcodek/vic.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Margus Ramst wrote:
>
> In most cases it would give a general time frame, but an experienced user can
> probably guess it more accurately himself. Extreme cases are not rare in POV
> renderings. A small part of the image may take up most of the time. Linear PPS
> calculation (or even one based on previous data) can _not_ take this into
> account. And POV can't predict the number of rays it has to trace for a
> particular pixel or line.
> Like I said, a progressive histogram approach might do the trick. It would hold
> the added advantage of showing a progressively refined preview of the entire
> scene before rendering is done. I would certainly consider this an useful
> option.
> Adding render time calculation based on time spent & PPS should be trivial. I
> can only guess, but perhaps the very reason it hasn't been done already is the
> inaccuracy of this method in raytraced scenes.
>
> Margus
>
It could be optional and it doesn't have to be very accurate (though the
accuracy would become better towards the end).
Imagine this: you set up a scene and start rendering. POV starts parsing; in
some cases this may take a while. You walk away, come back after some time,
check how far the pic is rendered, have a peek at the PPS. There's no way you
can tell how long it is going to take to finish the render (I'm talking about
non-trivial rendering times here) as long as you don't know how long the parsing
took.
Also, as I said in an earlier message, it would be nice to have _some_ idea of
what to expect, especially in a rendering that takes several days (like in 0
PPS-scenes or animations).
I didn't say it would be accurate, I just said it would be nice to have an
indication, an estimate (which is, by definition, inaccurate, isn't it?)
I just have the problem I'm not experienced enough to be able to outguess even a
rough estimate by the engine.
Bye,
Remco
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
