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

I have thought about doing this, but I know way too little about the
POV-Ray source code to even add a keyword, and have only recently
successfully compiled it.

Post a reply to this message

If this feature is implimented, you should be able to specify at what
recursion depth the different types of branches/leaves kick in.

Post a reply to this message

Edward C. wrote:
> 
> If this feature is implimented, you should be able to specify at what
> recursion depth the different types of branches/leaves kick in.

Absolutely. But it's been a long time since I've worked with an LParser,
so I'm not 100% clear on the code I would use to do this. Otherwise I'd
have included some pseudocode for the instructions, too.
My only other thought here is that if POV-Ray can't do the Lparsing,
there should at least be some way to implement the structure itself, so
that memory is used as efficiently as possible for objects lparsed by an
outside program.

Lummox JR

Post a reply to this message

Another thing I think would be a good idea is a built in particle
system, which would simulate fire, smoke, water, etc. Hmm, even an
scene_interaction keyword to make the particles respond to objects in
the scene?

Post a reply to this message

Chris Huff <Chr### [at] compuservecom> wrote:
: Another thing I think would be a good idea is a built in particle
: system, which would simulate fire, smoke, water, etc. Hmm, even an
: scene_interaction keyword to make the particles respond to objects in
: the scene?

  and kinematics and inverse kinematics and physics laws and...

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Chris Huff wrote:
> 
> Another thing I think would be a good idea is a built in particle
> system, which would simulate fire, smoke, water, etc. Hmm, even an
> scene_interaction keyword to make the particles respond to objects in
> the scene?

Well, fire's possible now. I've got a nice campfire scene using some
simple media and isosurfaces (via the Superpatch).

Lummox JR

Post a reply to this message

Yes, but I think a particle system would be more realistic, at least for
animations. I have been writing a pretty nice particle system, but it is
in C++. Maybe I will add it when POV-Ray is converted to C++.

Post a reply to this message

An interesting idea, and possible to implement of course!

But what are the advantages and disadvantages of implementing
L-parsing as a macro vs POV native primitive?  Would we want
to encourage one approach to L-Parsing as decided by the POV
team?

--
Nigel Stewart (nig### [at] eisanetau)  http://www.eisa.net.au/~nigels/
Postgrad Research Student, RMIT University, Melbourne, Australia
All extremists should be taken out and shot.

Post a reply to this message

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

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

Post a reply to this message