[Bf-python] NMesh and Vert Colors

[Willian Padovani Germano]

On Wed, 2003-05-28 às 16:14, John Harris wrote:
> To make my question short, why does the verticy color data have to be 
> accessed though faces. Wouldn't it make more sence to have the virtex 
> color data as a property of the verticies?  Thanks John Harris.

In NMesh each face has a pointer to a list of vertices and another to a
list of vertex colors.  Looks like a simple way to grab the whole thing,
though you're right it is a vertex property.  Both ways are easy to
parse with python, but for 3d file formats where there's a section for
vertices, another for faces (indices to the vertex list) and another
section for vertex colors, it's faster to have it the way it is now. 
They were probably thinking about n-gons.  Supporting VRML2 was a
marketing goal for Blender, some of their decisions may have come from
there -- I don't know.

BTW, NMesh faces store 
Look at this related comment from opy_nmesh.c (NMesh.c in exppython):

/* TODO: get rid of double storage of vertex colours. In a mesh,
 * vertex colors can be stored the following ways:
 * - per (TFace*)->col
 * - per (Mesh*)->mcol
 * This is stupid, but will reside for the time being -- at least until
 * a redesign of the internal Mesh structure */

It's easy to find comments in the source files about how Blender needs
urgently a redesign of its kernel.

BTW, another comment:

  /* This stuff here is to tag all the vertices referenced
   * by faces, then untag the vertices which are actually
   * in the vert list. Any vertices untagged will be ignored
   * by the mface_from_data function. It comes from my
   * screwed up decision to not make faces only store the
   * index. - Zr
   */

That's one thing that'll probably be changed when I get the chance to,
it's obviously better to make faces store indices and not pointers to
vertices.

--
Willian, wgermano at ig.com.br