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

There is already a "mosaiac preview", at least in the Macintosh version.
This progressively renders the scene, giving a preview which gets higher
resolution with each pass. It shouldn't be too hard to add an estimate
of remaining time to this.

Post a reply to this message

On Sun, 04 Jul 1999 08:44:33 -0400, TonyB
<ben### [at] panamaphoenixnet> wrote:

>> 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).

Crackle textures cache the list of centers.  Formerly, this cache was
in a global structure, so it was shared between all crackles.  If you
had more than one in your scene, particularly if they were layered,
the cache was not valid as often as it could have been.  I made the
cache part of the individual texture information, and there's your
speed increase.  As I said, though, it's only on layered crackle
textures.

>> 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. =)

I mentioned having fixed the problem, in the forum in which the
problem was reported.

Post a reply to this message

Yes, I know (it exists in all versions that output an image while rendering).
Perhaps this would even suffice. But AFAIK mosaic only calculates one
preliminary pass (every 8th pixel or something). What I had in mind though was
something like "render every 8th line, then every 4th, every 2nd etc." i.e.
recursive subdivision. I believe rendering in whole lines is necessary for AA.

Margus

Chris Huff wrote:
> 
> There is already a "mosaiac preview", at least in the Macintosh version.
> This progressively renders the scene, giving a preview which gets higher
> resolution with each pass. It shouldn't be too hard to add an estimate
> of remaining time to this.

Post a reply to this message

Ron Parker wrote:
> Oh, right, thanks for reminding me.  You did send me those, didn't you?
> I hope to make up a new version with that, Edna's bugfixes, the new
> isosurface functions from R. Suzuki, and a few other bugfixes from other
> people sometime this weekend, since I've got three days and all.  And,
> as a bonus, I'll throw in my 75% speedup for layered crackle textures at
> no extra charge.

Might want to wait until I get int_atan2() functioning correctly. I
found out that it's still not quite right, and it needs a little more
work--not much, but I can't get to it until Tuesday since I'm away.

Lummox JR

Post a reply to this message

ingo wrote:
> Imagining what an isoblob will look like is a bit a problem for me. If you take,
> for example, the wood pattern as a function and a cylinder as a component. Will
> the resulting object be a number of tubes inside each other? Or will it be like
> a cylinder with a heavy wood normal? Or something completely different?
> (probably)

If you made the object transparent, it probably would look like a series
of layered tubes, yes, depending on the max trace level.
Mostly my idea was to allow things like random noise and more complex
functions to be thrown into a blob.

> Speaking of trees, would it be possible to use a spline as a function for an
> isoblob?

Anything that works for an isosurface ought to do--so I don't think
splines will work unless you do some tinkering to make a rather complex
function to do it.
Incidentally, the if() function code I sent to Ron should allow
piecewise functions. My function code still needs a tad more work in the
int_atan2() function, but everything else works just fine. The if()
function will work something like this:

#declare ifexample=function{if(x+y,1,0.5)}

The value of this function is 1 where x+y>=0, and 0.5 where x+y<0. It's
*very* handy.

Lummox JR

Post a reply to this message