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