For those of you who've gotten wind of my latest folly, the isoblob
primitive, I figured an update is in order.
Yes, it *can* be done. It'll be dog slow when huge numbers of components
interact (careful bounding will be critical), but I think it'll work.
The code is well underway.

The basic concept of the isoblob is to combine the best parts of the
blob and isosurface syntax (isosurfaces are probably best known to
Superpatch users like myself). Instead of blob components, each
component has a specific bounding shape (so far, just a sphere and a
cylinder), and within those bounds is a user-defined density function.
How I'm going to handle functions and parsing yet I don't know. Since
most isoblob shapes will probably use only a handful of functions, and
then transform them into place for each component, it'd be nice to
arrange the syntax as follows:

isoblob {
  function <function1> ...
  [accuracy <accuracy>]
  [max_trace <max_trace>]
  sphere {function <function number>
    <center> <radius>
    strength <strength>
    [transforms]
    }
  cylinder {
    function <function number>
    <end 1> <end 2> <radius>
    strength <strength>
    [transforms]
    }
  [misc. object mods]
  }

So far, the meat of the code is in place. I've adapted isosurface method
1 to (hopefully!) work with the isoblob concept, and most of the methods
for computing normals, field density, etc., are taken care of. Work
remains to be done--next week--on the initialization and destruction of
the different structures, and then on the parsing. That's also where a
bug is likeliest to surface, though, so it's a lot of work to check and
re-check.
Anyone who's looked at the blob and/or isosurface code knows that
altering either one in a meaningful way is a daunting task. Worse, both
primitives are more or less alien to each other in the way they
calculate things. And even worse than that, instead of calculating one
function, it's necessary to calculate several for each little interval.
But, all in all, I think it's coming along nicely.

Why this obsession with isoblobs? Because I want to make trees. The
isoblob will make realistic-looking trees truly possible, albeit not
nearly as fast as a blob would be.
I may yet modify f_func.c and its subsidiary files to allow some
"isoblob space awareness" to the components. (Each component's function
is relative to the component space, not to isoblob space.) I've already
modified those files to include several functions/values like ceil(),
pi, clock, atan2(), and the handy if() (an either-or sort of function),
so what's one more change? (BTW, the function additions are a simple
three-source-file patch if anybody wants it. If you have the latest copy
of the Superpatch source files, these should tack right onto
it--assuming Ron hasn't added them already.)

Lummox JR

Post a reply to this message

Lummox JR heeft geschreven in bericht <377### [at] aolcom>...
>For those of you who've gotten wind of my latest folly, the isoblob
>primitive, I figured an update is in order.
>Yes, it *can* be done.
>...........

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)


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

Looking forward to your results,
ingo
--
Met dank aan de muze met het glazen oog.

Post a reply to this message

On Fri, 02 Jul 1999 01:25:36 -0400, Lummox JR wrote:
>(BTW, the function additions are a simple
>three-source-file patch if anybody wants it. If you have the latest copy
>of the Superpatch source files, these should tack right onto
>it--assuming Ron hasn't added them already.)

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.

If I'm feeling really ambitious, I'll figure out how to make the truetype
code work on non-Unicode-enabled Macintosh fonts again. (ahem!)

Post a reply to this message

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

BTW, I remember somebody mentioned that the thingy that reports the PPS
(+AM2) is buggy, can you get that done?

Thanks, and good luck.

--
Anthony L. Bennett
http://welcome.to/TonyB

Graphics rendered
by the Dreamachine.

Post a reply to this message

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

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] peakeduee>
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

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