Well, I've been looking through the Superpatch source code for a while
now, but from it I've gotten the distinct impression that anything not
currently possible in POV-Ray can be added with enough time and
imagination.
So is it possible now to add a primitive that can be used to do trees?

This isn't totally out of the blue. I do have a *vague* idea of how to
implement something like this, at least in abstract. No doubt many of
you are familiar with LParsers; why not create an lparse primitive that
can be made to create complex objects? Each object could have its own
random "seed" for the compilation process, wherein the Lparsing would be
done, creating a list of objects. Consider a structure like this:

struct LPARSE_STRUCT {
  ...	/* The usual object stuff */
  /* Random seed is not included here because it is used at compile-
     time only */
  LPARSE_DATA *Data;  /* Pointer to the parent object */
  LPARSE_OBJ *Obj;    /* First in a linked list of sub-objects */
}

struct LPARSE_DATA {
  LPARSE_BRANCH *Branch;  /* First in a linked list of branch objects */
}

struct LPARSE_BRANCH {
  <whatever datatype works> instructions;  /* LParser instructions */
  OBJECT *Obj;
  LPARSE_BRANCH *next;
}

struct LPARSE_OBJ {
  /* This is a pointer to the object, not the actual object. In theory,
     this could save a lot of memory. */
  OBJECT *Obj;
  /* Transformed from <0,0,0> of the lparse object's base */
  Transformation *Trans;
  LPARSE_OBJ *next;
}


The idea is this: The LPARSE_BRANCH is a type of object, only one
defined per lparse object. This object is referred to many times, and
exists in many places, within the LPARSE_OBJ list--but it's scaled and
rotated and translated in different ways in each LPARSE_OBJ structure.
Now when POV-Ray parses the scene and sees an lparse primitive, it will
set up the random seed and automatically create the list of LPARSE_OBJ
object pointers and their transformations.
Bounding boxes are of course important.
When rendering, the renderer will first look for the bounding box of the
main object. If it intersects that, it then checks all the objects in
the LPARSE_OBJ list, transformed properly into place. If it intersects
any of those, they are checked as if they're part of the list.

There are of course conceptual flaws. I haven't made a new primitive
before, so I'm not sure of all that's involved. But also, I'm not even
sure an object can be referenced like that in many different places,
with different transformations--can it?
As an example of what this primitive could do, I submit this pseudocode:

#declare tree=lparse {
    orientation_fwd y	// these vectors will get transformed
    orientation_right x //  during lparsing
    max_depth 7         // to keep the lparser from going berserk
    bounded_by {cylinder {...}}
    branch {           // tree trunk/branch
        instructions "..."   // heck, they're complicated
        object{...}
        }
    branch {           // twig--followed by a number of leaves
        instructions "..."   // similar to the ones above
        object{...}
        }
    branch {object{...}}  // leaf
    }

This, at present, is beyond my capability to add to the source code; yet
I suspect there's more than one person out there with the expertise to
do it.
The only severe worry is scale; there has to be some way of sending size
information to a branch, so it knows how it should be scaled down, or
how long or wide it should be. But a leaf, on the other hand, should
remain more or less the same scale always.

The thought of rendering a scene with real-looking trees in the
background really gets to me. If it could be done with a minimal amount
of memory per tree, yet still allowing each to be subtly different, why
not try it?
Any takers?

Lummox JR

Post a reply to this message