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

Margus Ramst wrote:
> 
> 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.

Indeed, it's antialiasing that's the problem. A scene at 1/8 resolution
will render 64x quicker than a scene at full res with no antialiasing,
but throw in the antialiasing and that time would be much more: Perhaps
50%, 100%, 200%, or worse.

Lummox JR

Post a reply to this message

On the Macintosh version, you can set the pass size, the largest is
every 128'th pixel, it halves it at each pass up to a minimum pass, then
does the rest of the render.

For example: the max pass is 8, the min pass it 4. It will start out
rendering every 8th pixel, then do every 4th, then it will do the rest
of the rendering.

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

Margus Ramst wrote:
> 
> 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.

Indeed, it's antialiasing that's the problem. A scene at 1/8 resolution
will render 64x quicker than a scene at full res with no antialiasing,
but throw in the antialiasing and that time would be much more: Perhaps
50%, 100%, 200%, or worse.

Lummox JR

Post a reply to this message

On Sun, 04 Jul 1999 18:48:56 GMT, par### [at] fwicom (Ron Parker) wrote:

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

Even better, I've gotten yet another speed boost out of crackle that 
can help even if your textures aren't layered.

The scene I used to benchmark the above, a simple sphere with a
layered crackle texture, went from 4:18 to 1:54 (only a 50% decrease
in time; I misremembered my results) with the first change, and it's
now down to an even 1:30.  That's on a 486 SLC 66; your mileage WILL
vary.  The version without the layered texture, with just a plain
crackle, went from 1:12 to 1:05 on the Linux SVGA superpatch.  The
difference in gains is explained by the realization that the denser
your crackle is, the more you'll gain, and the second texture in the
layer was scaled to .2.

Post a reply to this message