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