Chris Huff wrote:
> 
> Primitive Pros:
>     MUCH faster parsing
>     would probably take less memory
>     would be easier to use the object parameters
>     could be made much more powerful
>     would have the standard object syntax

It's not so much the parsing speed that concerns me, as the memory
issue. Objects in POV-Ray are huge; a forest full of Lparsed trees would
be enormous, if each tree consisted of 500 objects. If each tree,
however, merely consisted of 500 transformations and pointers to
objects, and the entire forest only took up 3 or 4 physical objects (the
tree sections) plus the trees themselves, then it might just work.
Plus, the amount of memory used has some effect on the rendering speed.
But it's probably quicker to check for intersections with an internal
array of 500 object pointers and transformations than with 500 other
objects on the whole list.
Also, there is the great advantage that bounding volumes could be
applied to each branch in the same manner (hmm... best make that an
additional item in the array elements), speeding up rendering time
somewhat.

The biggest problems, I think, are these:

1.) Trying to provide parameters to the branch objects. These might be
    made intentionally variable depending on their position, depth in
    the structure, etc. It might actually be necessary to define a
    special type of object for Lparser branches, to allow for this.
2.) Creating seamless intersections. A tree doesn't just look like a
    bunch of tinkertoy cylinders strung together. Rather, it might look
    more like a blob object (hmm.... an interesting idea) with some
    random noise to it. Where a branch goes off from the trunk, there's
    a "neck" to the branch where the trunk curves outward--and when it
    does go in a new direction, the texture smoothly goes with it.
    Perhaps an Lparse blob type of object would be in order?

This actually gives me an idea--it might be possible to update the blob
type to include isosurfaces as per the Superpatch. With that, functions
can be used to affect the density. That might not help with this
particular problem, but I like the idea of what it could do elsewhere.

> Macro Pros:
>     easily updated
>     people without a compiler could modify it
> hmm, that is all I could think of.

I think "easily updated" would apply just as easily to the primitive,
too.

Post a reply to this message

On Mon, 28 Jun 1999 14:02:52 -0400, Lummox JR wrote:

>This actually gives me an idea--it might be possible to update the blob
>type to include isosurfaces as per the Superpatch. With that, functions
>can be used to affect the density. That might not help with this
>particular problem, but I like the idea of what it could do elsewhere.

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.

Post a reply to this message

In article <3776DBE4.5A7D7C7E@eisa.net.au>, Nigel Stewart
<nig### [at] eisanetau> wrote:

>An interesting idea, and possible to implement of course!
>
>But what are the advantages and disadvantages of implementing
>L-parsing as a macro

I just converted an old IFS-fractal type program I wrote *many* years ago
(for OS-9, on a Tandy Color Computer, if anyone remembers) into a macro on
POV. I'll try and post the macro later on. (It is on my home computer, not
my office computer.)

It implements both 'building' the fractal, and 'fading in' to the fractal
(Bernhard's method, or something?)

Makes some pretty cool shapes (especially when used with blobs) but it is
nowhere near making real trees yet.

Jerry

Post a reply to this message

<jer### [at] cerebusacusdedu> <jer### [at] acusdedu> wrote:
> I just converted an old IFS-fractal type program I wrote *many* years ago
> (for OS-9, on a Tandy Color Computer, if anyone remembers) into a macro on
> POV. I'll try and post the macro later on. (It is on my home computer, not
> my office computer.)

Posted in povray.binaries.scene-files under the subject "Fractal Macro".

Jerry

Post a reply to this message

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.

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. Most of it is pretty straightforward, but at the moment
I'm a bit stuck on the math of trying to get the quartic coefficients
right for All_Blob_Intersections. I can't seem to get anything less than
an 8th order equation to work mathematically, even though a 4th order
equation ought to do the trick. I'll keep at it, of course....   :)

Lummox JR

Post a reply to this message

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