Jerry wrote:
[snip]
> Makes some pretty cool shapes (especially when used with blobs) but it is
> nowhere near making real trees yet.

Interesting....
Ideally, though, I think to get a forest of realistic trees, some sort
of mutant isosurface with component lists is needed. Something like a
blob, perhaps, in its ability to ignore certain elements that can't
intersect the ray. The up side is that if it's done like a blob, it can
be possible to texture the individual elements.

Lummox JR

Post a reply to this message

On Tue, 29 Jun 1999 23:34:14 -0400, Lummox JR wrote:
>Ron Parker wrote:
>> Uh... a blob _is_ an isosurface.  It's just a specialized one that
>> has been optimized to be faster to compute than a general isosurface.
>
>True, true.
>I was thinking, though, something along the lines of both: Something
>with a blob's clipping capabilities, and the ability to hold multiple
>components, yet using the power of functions.

Isosurfaces can be used in CSG.  In some cases you'll have to tell it
explicitly to find all intersections to get it right, but it will work.

>Ironically, right now I'm looking through the blob code, seeing if
>there's a way to add a torus-shaped component. Imagine the
>possibilities. 

While you're in there, add a conical component.

Post a reply to this message

On Tue, 29 Jun 1999 23:40:09 -0400, Lummox JR wrote:
>Jerry wrote:
>[snip]
>> Makes some pretty cool shapes (especially when used with blobs) but it is
>> nowhere near making real trees yet.
>
>Interesting....
>Ideally, though, I think to get a forest of realistic trees, some sort
>of mutant isosurface with component lists is needed. Something like a
>blob, perhaps, in its ability to ignore certain elements that can't
>intersect the ray. The up side is that if it's done like a blob, it can
>be possible to texture the individual elements.

I was thinking just this last night as I was driving across town to an
appointment, thanks to you (cue the "You Know You've Been Raytracing Too 
Long" thread...)

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.

Post a reply to this message

On 30 Jun 1999 09:56:28 -0400, par### [at] fwicom (Ron Parker) wrote:

<snip>
>
>While you're in there, add a conical component.  

Polygonal, too.


Peter Popov
ICQ: 15002700

Post a reply to this message

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

Cones should work out, although I had to give up on toruses.
Problem is, density is a 4th-order polynomial, and density of a torus
can't be defined that way; it can't even be fudged easily. I think
2nd-order object types are the limit.
Well, there's always isosurfaces.

Right now I'm checking to see if maybe I can't create an "isoblob" type
that mixes the two. This is a bit weighty a task, I know, but the idea
is solid.
The concept is not only that the isoblob will contain some simple
structures like a blob, but that each will have a function (or rather, a
pointer thereto), a special bounding object, etc. The bounding objects
will be handled just like the blob types, but within each interval of
influence will be an addition of density functions (weighted by a
strength value).
I think this may be vaguely within my capability. It will take some
serious combinations of the isosurface and blob code, but most of the
work is already done in some way or another. I seem to understand most
of the blob code I've looked through, which is encouraging.

The main idea here, BTW, is that an isoblob will be able to contain
*many* components, perhaps built by a macro, many of them using the same
functions. (The only catch is that there might need to be a
non-translated vector input to the function as well as translated, to
take advantage of functions like noise3d() in blob space rather than in
component space.)

Lummox JR

Post a reply to this message

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