[Bf-committers] re: per vertex properties

[Ton Roosendaal]

Hi,

As promised, a quick review! Comments inserted below.


> PER-VERTEX PROPERTIES
> *********************
>
> This document discusses some of the design ideas and implementation  
> issues with
> this feature.
>
> GENERAL IDEA
> ------------
>
> The idea is to extend the current property mechanism in a way that  
> allows the
> assignment of properties to single vertices in a mesh.
>
> Because assigning properties to large numbers of vertices some  
> convenience
> features should be provided. For this purpose I suggest the creation of
> "property sets" which group individual properties. Property sets can  
> be shared
> between vertices. Each vertex can be assigned a couple of property sets
> simultaneously. The idea is to manage the property sets in stack so  
> that
> properties can be overridden.

I think, for better understanding by others, you should start with a  
real functional description. Question to be answered is; "what can I,  
as a user, do with it", or "what can I use it for, and how".

The example below is not very convincing, it's hard to imagine why  
someone wants to assign such info to a vertex... maybe to a face?
And still the question remains, if this is something that should work  
on large groups of vertices (faces) like a material, or that this is an  
editor for real per-vertex unique things.

>
> EXAMPLE
> -------
>
> [Note that this is a completely arbitrary example :-)]
>
> Create a property set named "basicarmour"
> Add a property named "armour", type integer, value 1000
> Add a property named "shiny", type integer, value 0
>
> Create a propety set named "shinyarmour"
> Add a property named "shiny", type integer, value 1
> Add a property named "reflective", type integer, value 1
>
> Create a sphere and select a vertex.
>
> Assign the property set "basicarmour" to the vertex
>
> This means that the vertex will in effect have the following  
> properties and
> values:
>
> - "armour", type integer, value 1000
> - "shiny", type integer, value 0
>
> Add a property named "armour", type integer, value 10 to the vertex
>
> Then the visible property values for the vertex look like this:
> - "armour", type integer, value 10
> - "shiny", type integer, value 0
>
> Note that the property set "basicarmour" is unchanged
>
> Assign the property set "shinyarmour" to the top of the stack for this
> vertex.
>
> Then the visible property values would look like this:
> - "armour", type integer, value 10
> - "shiny", type integer, value 1
> - "reflective", type integer, value 1
>
(snipped)

> struct bPropertySet {
>   char name[32];
>   struct bProperty *prop; /* properties are stored in a linked list */
> };
>
> struct bPropSetLink {
>   struct bPropertySet *pset;
>   struct bPropSetLink *next;
> };

In Blender we use ListBases for it. So it can look like:

struct bPropertySet {
	char name[32];
	ListBase allprops;
};

the API for it (addlink, remlink, etc) is used everywhere in Blender.  
It has nice functions to free entire lists, save them to disk, etc.

> struct bVertexProperties {
>   struct MVert *vert; /* Vertex this struct is assigned to */
>   struct bProperty *local; /* properties that are assigned only to  
> this vertex*/
>   struct bPropSetLink *propsets; /* a linked list pointing to all the  
> property
>                                     sets that are assigned to this  
> vertex */
> };
>
> NOTE: Is it a good idea to refer to a vertex like that? How else could  
> it be
> done? Adding a pointer to the MVert struct seems a bit too heavy to me.

Better not do it, rule is not to store pointers in data, except for the  
so-called "Library Data" in Blender, which all start with the uniform  
ID struct.
Use in index number instead...

I also don't understand well what you'll do with this struct... I can  
also imagine that a "property set" just is of type bProperty itself...  
and that you make another definition structure for how these sets are  
defined & stored.

Properties in Blender can be of arbitrary size, there's already code in  
Blender that handles it... it could be written a tad nicer, but it  
works.

>
> NEW DNA STRUCT MEMBERS
> ----------------------
>
> in the Mesh struct:
>   void *vertexprop; /* pointer to an array of bVertexProperties */
>   struct bPropSetLink *allpsets; /* a linked list of all property sets  
> in this
>                                     mesh */

Hurms... it could be nice if we can find a way to have PropertySets  
defined at a higher level. These sets look to me as something that is  
re-used a lot.
In Blender, typical could be to assign it to a Scene... and offer a  
method to copy/paste sets, or copy it to another Scene.



>
> REQUIRED FUNCTIONS
> ------------------
>
> [NOTE: I use C++ syntax on purpose to keep the primitves short]
>
> /* Functions for manipulating property sets */
> bPropertySet *PSetCreate(Mesh *mesh);
> void PSetDestroy(Mesh *mesh, bPropertySet *pset);
> void PSetAddProp(bPropertySet *pset, bProperty *prop);
> void PSetRemoveProp(bPropertySet *pset, bPropertySet *prop);
>
> bProperty *PSetFind(bPropertySet *pset, char *name);
>
> /* Functions for manipulating vertex properties */
> bVertexProperties *VPropCreate(Mesh *mesh, MVert *mvert);
> void VPropDestroy(Mesh *mesh, bVertexProperties *props);
> void VPropAddSet(bVertexProperties *vertexprops, bPropertySet *pset);
> void VPropRemoveSet(bVertexProperties *vertexprops, bPropertySet  
> *pset);
> void VPropAddProp(bVertexProperties *vertexprops, bProperty *prop);
> void VPropRemoveProp(bVertexProperties *vertexprops, bProperty *prop);
>
> bProperty *VPropFind(bVertexProperties *vertexprops, char *name);
>
> A couple of additional functions could be needed. But this list should  
> cover the
> basic functionality.
>
> TODO: Where to put these functions

next to property.c, in propertyset.c i would think?

>
> TODO: What about Python interface?
>

Dunno... get Michel, Guignot or Willian involved for advice!

---

Final notes:
- find the common interest from people. The target 'being able to  
extend all data in Blender with custom properties (attributes) might  
catch more interest. Such a system  then first could work on the main  
(Library) blocks in Blender, such as
   - Mesh
   - Object (already does)
   - Material
   - etc

- Keep a single Property system, whether its a 'string' property or a  
'set' property... it can be presented uniform to a user.

- to allow properties in 'derived data' (beziers, vertices, faces, etc)  
you can also think of a generic approach. I can think of 2 ways:
    - with a sort of Material method (giving verts/faces/curves an index  
to an array which has properties). This allows grouping, but not  
overlaps...
    - create a new special Property type, which has a 'type' and 'index'  
code in it. These then can reside in the main Library block (mesh,  
curve) and point using 'type' to face/vert/curve and using 'index' to  
the index # internal. This can satisfy just the special cases game  
developers need, to assign portals or so.
    However... it will be hard one to manage with the current EditMode  
concept, when remodeling the Mesh indices can potentially change.

(need to think this over! We also have to talk to game engine  
developers and people who'll work on external renders for their  
requirements)

- most important: do you really want this system for bf-blender, or do  
you want one for yourself mostly (or a small team of people). Having a  
'special Blender release' really isn't taboo, or a bad thing todo. I'd  
be happy to host such projects, and advise how to remain compatible.

Just my 2 cents. We'll talk again after Sig. Don't hesitate to have the  
discussion here, and at the funboard mailinglist...

-Ton-

------------------------------------------------------------------------ 
--
Ton Roosendaal  Blender Foundation ton@blender.org  
http://www.blender.org