Ron Parker wrote:
> Keep in mind that blobs don't actually texture the individual elements.
> I think they texture each intersection based on a weighted average of
> the textures on the components that contributed to that intersection,
> though I'll admit that that's one area of the code that I don't have
> memorized yet.

Hmm... I think you're right.
Perhaps there might be a flag in an element to prevent it from blending
textures?
Actually, it seems to me that a decent tree would need the leaves to be
something separate anyway, since there's little point in blending in the
leaf shape with the branch shape. Two separate isoblobs would do the
trick... but how would that be built via a macro?
All idle speculation at this point. I can do only limited work on the
isoblob idea this week, and anyway I've only *just* begun to look into
the idea. But it's an idea that I *really* like.

Lummox JR

Post a reply to this message

Sounds like a Very Good Idea. It would be wonderful for all sorts of
organic shapes.

Post a reply to this message

On Wed, 30 Jun 1999 23:56:43 -0400, Lummox JR wrote:
>Perhaps there might be a flag in an element to prevent it from blending
>textures?

I don't think you could.  How would you color the "neck" that connects
two components?  It's not really a part of either component.

>Actually, it seems to me that a decent tree would need the leaves to be
>something separate anyway, since there's little point in blending in the
>leaf shape with the branch shape. Two separate isoblobs would do the
>trick... but how would that be built via a macro?

I think you'd just need two macros.  One that generates the branch 
structure and puts blobby elements where the branches would be, and one
that generates the same branch structure and puts blobby elements where
the leaves would be.

>All idle speculation at this point. I can do only limited work on the
>isoblob idea this week, and anyway I've only *just* begun to look into
>the idea. But it's an idea that I *really* like.

Another idea, and one that might be better able to leverage the blob code:
add an isosurface component to the existing blob syntax.  Then you can use
the existing blob algorithms when the only components in range are the usual
spherical and cylindrical ones, and kick it into repeated-subdivision mode
only when there's a complex component in range, passing the existing 
isosurface code a custom-made function that is the sum of the functions for 
the relevant components.  Ideally, you'd find some way to cache the 
custom-made function for a while in case the same set of components gets hit 
again soon, but that's just an implementation detail.

Post a reply to this message

Ron Parker wrote:
> Another idea, and one that might be better able to leverage the blob code:
> add an isosurface component to the existing blob syntax.  Then you can use
> the existing blob algorithms when the only components in range are the usual
> spherical and cylindrical ones, and kick it into repeated-subdivision mode
> only when there's a complex component in range, passing the existing
> isosurface code a custom-made function that is the sum of the functions for
> the relevant components.  Ideally, you'd find some way to cache the
> custom-made function for a while in case the same set of components gets hit
> again soon, but that's just an implementation detail.

That's quite true; that could work. Only then there's the problem of
isosurfaces with different bounding shapes, etc. Also, I suspect that
including mixed element syntax could slow things down when only one form
or the other was needed.
For most cases, I think a simple isoblob might make more sense. Any
shape that would use that many functions together would likely be meant
to look rather different from the artificial shape types in a blob;
isoblobs would probably be used only for organic shapes, like trees, or
else for shapes that use toruses and other unsupported blob components.

Lummox JR

Post a reply to this message

Ron Parker wrote:
> While you're in there, add a conical component.

I've done a little bit of preliminary math on the conical blob component
idea. It shouldn't be excessively difficult to add.
The result won't look *entirely* conical, because the r function looks
like this:

r^2 = (x^2+y^2)+(1-z)^2

I think the sides of the cone, when r<1, will curve inward a little bit.
I haven't done a complete analysis of the curve; just some rough figures
on paper. Still, it ought to do.
I also did a little math on the idea of a paraboloid element; why not?
Then "r" is defined thusly:

r^2 = (x^2+y^2)+(1-z)

That one should keep more of a true shape as r gets lower.
In each of these, I think I'll need to add a way to cap off both ends,
and create a flat plane there (or really, more like the cylinder
element's cap hemispheres).
Because of that, the ideal cone would actually have a density of 1 all
through the center, but that's not possible because of the math
involved. The formula would be r^2=(x^2+y^2)/z^2 -- and since r^4 and
r^2 are both used in a fourth-order equation, things would get kind of
tricky. There'd be no real way to isolate r^2, either, and still get any
kind of a polynomial, which was my problem with the torus idea.
Gads, this stuff gets hairy....

Lummox JR

Post a reply to this message

Hmmm ... I read this group now a while, and I think the treeIdea is not as
bad ...
especially the idea that not only to use cylinders but blobs for use as the
branches is important, I think ...
But there I got an Idea to offer ...

Why Use the Tree in the Geometrics Part of PoV?? Why create a Geometric
Object ???

Can't we use it as a kind of Media ???
I think this way: I just create a hollow cube, assignin' a texture with a
media. This media is computed by the new tree-Algo with will (with the right
DensityMap) show a nice tree. One Pro would be that, by adding an noise to
this, you can create a relative natural taste of it ...

But I'm sure there are enough Contras to this(just thinking on the speed).


Now it's on you, the masters, to decide about this dumb Idea of a novice ;-)

PS.: Sorry 'bout my bad english ... I'm from germany, you see...

Post a reply to this message

"Jan Walzer" <nos### [at] informatikuni-hallede> writes:

> Hmmm ... I read this group now a while, and I think the treeIdea is not as
> bad ...
[...]
> Can't we use it as a kind of Media ???

You're not the first one to come up with this idea. It has already be
phrased by Kajiya and Kay in "Rendering Fur with Three Dimensional
Textures", Computer Graphics, Volume 23, Number 3, July 1989.

I'm currently working more or less (read: less) on an implementation
of the fur that is presented in this paper. A short film of a furry
torus can be seen at http://www.povray.willhalm.de/tracegallery/ .

In my opinion, this approach has a lot of potential. Apart from fur,
I think that grass and forests can be renderered this way. Of course,
someone must first find an adequate lighting model for these objects.
However, you should be aware that this method will only work for 
distant views.

> PS.: Sorry 'bout my bad english ... I'm from germany, you see...

dito.

Thomas

-- 
http://thomas.willhalm.de/ (includes pgp key)

Post a reply to this message

> > Can't we use it as a kind of Media ???
>
> You're not the first one to come up with this idea. It has already be
> phrased by Kajiya and Kay in "Rendering Fur with Three Dimensional
> Textures", Computer Graphics, Volume 23, Number 3, July 1989.
Where to get this paper ?

[...]
> In my opinion, this approach has a lot of potential. Apart from fur,
> I think that grass and forests can be renderered this way. Of course,
> someone must first find an adequate lighting model for these objects.
> However, you should be aware that this method will only work for
> distant views.
hmmm ... but am I right, about the rendertime ...
I've thougt about the last night, and found that therefore the "steps in the
media" (or how was it called) have to be massivly increased, to get all the
branches of a high-detailed tree, don't they?
The standard for this is AFAIK 10 steps, and how can this make a good tree ?

Post a reply to this message

> I'm currently working more or less (read: less) on an implementation
> of the fur that is presented in this paper. A short film of a furry
> torus can be seen at http://www.povray.willhalm.de/tracegallery/ .
maybe there's something wrong with your link ???

Post a reply to this message

In article <387ba7f6@news.povray.org>, "Jan Walzer" 
<nos### [at] informatikuni-hallede> wrote:

> hmmm ... but am I right, about the rendertime ...
> I've thougt about the last night, and found that therefore the "steps in 
> the
> media" (or how was it called) have to be massivly increased, to get all 
> the
> branches of a high-detailed tree, don't they?
> The standard for this is AFAIK 10 steps, and how can this make a good 
> tree ?

I really think the best use of a density pattern to make a tree or grass 
would be in an isosurface, which is actually slightly similar to media 
in some ways. And their render speed is usually quite tolerable, 
although complex ones with a lot of very small details can be slow.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message