[ REQ 5096]: Vertices :)

[jsp at betz.biostr.washington.edu]

polylistP.h

    typedef struct Vertex
    {
	    HPoint3	pt;
	    ColorA	vcol;
	    Point3	vn;
    }  Vertex;

    typedef struct Poly
    {
	    int	n_vertices;
	    Vertex	**v;
	    ColorA  pcol;
	    Point3	pn;
    }  Poly;

    struct PolyList
    {
	    GEOMFIELDS
	    int	n_polys;
	    int	n_verts;
	    Poly	*p;
	    Vertex	*vl;
	    int	flags;
	    int	seq;		/* for 4D->3D tforms */
    #  define	  PL_HASVN	0x1	/* Per-vertex normals (vn) valid */
    #  define	  PL_HASPN	0x2	/* Per-polygon normals (pn) valid */
    #  define	  PL_HASVCOL	0x4	/* Per-vertex colors (vcol) valid */
    #  define	  PL_HASPCOL	0x8	/* Per-polygon colors (pcol) valid */
    #  define	  PL_EVNORM	0x10	/* Normals are everted */
			    /* For 4-D points, see geomflags & VERT_4D */
    };

I used this sort of layout in Skandha 1-3, but got sick of
the inflexibility.  People wanted to tack on on custom
per-vertex information and then map it to color flexibly at
will and such.

After scratching my head a bit, I switched to implementing
commonlisp-style arrays (float/int/short/byte/bit, 0-7
dimensions, fill pointers) and then representing this sort
of information as a linklist of named, same-shape arrays.
(Using lisp keywords for names, so as to be able to do fast
word comparisons instead of strcmp()s.)

This logically provides sort of a tabular format with
heterogenously-typed columns (I call it a graphic relation),
or you can think of it as an array of tuples implemented as
a tuple of arrays...

E.g., for the above structure, one might have a linklist of
arrays:

  :vtx-x (floats)   \
  :vtx-y (floats)    \  Vertex.pt
  :vtx-z (floats)    /
  :vtx-w (floats)   /

  :vtx-r (float)    \
  :vtx-g (float)     \  Vertex.vcol
  :vtx-b (float)     /
  :vtx-a (float)    /

  :vtx-nx (float)    \
  :vtx-ny (float)     } Vertex.vn
  :vtx-nz (float)    /

This has the advantages:

 -> It is easy to drop unwanted columns from the table,
    e.g., if polygon normals are not wanted.  I work
    with large enough meshes (<= ~500,000 polygons --
    detailed neuroanatomy models &tc) that space is
    not a completely irrelevant consideration.

 -> It is easy to add new columns to the table, to
    represent temperature or stress or whatever.
    Since the system graphics primitives use the
    columns they know, and ignore the rest, this
    doesn't damage anything or require major rehacking.

 -> It is easy to implement a set of pointwise lisp
    operators that take column names as operand and
    destination fields.  This makes it easy to
    interactively set vertex color to some new function
    of vertex temperature or such and view the results.
    (Since the inner loop is in C, not lisp, it's fast.)

 -> The resulting datatype is flexible enough to be used for
    a variety of things.  A 2-D relation with three byte
    arrays named :pix-r :pix-g :pix-b makes a dandy
    implementation for images.  (Add :pix-a if you're in an
    expansive mood.)  Use them for textures, too, and really
    get your money's worth :). If the image is monochrome,
    drop :pix-r and :pix-b to save space/time, hacking your
    image-draw primitives to default those two channels to
    :pix-g if they are missing.  A 3-D short array makes a
    fine container for MRI voxel data.  Add a second bit,
    byte or short array if you want to classify voxels by
    some criterion.  Add a couple more if you have
    multimodal data.  (I'm currently playing with registered
    arterial/venous/anatomy MRIs of my head.:) The basic
    pointwise operators can be applied to all of them...

Given the above datastructure generalization and a more
macho lisp, you'd have basically everything I've built in
Skandha4, and I could maybe stop re-inventing wheels
*hopefulgrin*. (The underlying systems are otherwise fairly
similar... I'm missing lots of neat geometry tools you've
built, of course... some of my section-editing and perhaps
animation stuff might go a bit beyond what you provide.)

BTW, I'm still puzzling out the story on shared memory in
Geomview.  I see comments that it was present in Minneview
and is missing in Geomview, and #if 0'd stuff that may be
coming or going, hard to tell ... when working with
megapolygon surfaces or 256^3 voxel sets, it's nicer to
share memory than stuff them through pipes by value...

Maybe that's getting too far outside your charter, though.