[Bf-committers] re: per vertex properties

[Gregor Mückl]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Mittwoch, 23. Juli 2003 21:08 schrieb 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.
>

I know that this example is not very convincing. I made it up in a hurry. But 
I actually have use cases, where per-vertex and per-edge properties make 
sense and per-face properties don't.

One of them is generating whole streets (including street crossings, traffic 
signs and traffic lights) from a single mesh that is used as a street plan. 
The edges would carry information on the type/width of the street to place 
there and the vertices would carry information about the street crossings.

Another one is building waypoint graphs for game AI. Computer-controlled 
characters can be moved safely along edges which carry additional information 
like the "cost" of traveling that way so that the AI is able to determine the 
fastest route (i.e. the path in the graph with the lowest cost) between two 
locations.

A third one are so-called trigger planes. This is some sort of invisible 
geometry (simple polygons suffice in most cases) that is used for collision 
detection against the player. In the case of a collision a certain event is 
generated (most game engines would fire a script at that point, which could 
then show a cut scene or release some more of those really nasty enemies from 
behind a dark corner). In that scenario you would assign parameters to a face 
that are then used by a game engine to execute that script.

These are the use cases that gave me the motivation to tacke this feature as I 
will need it in the game project I'm on. This game project is my primary 
motivation. But there a conflict arises between the need to have a solution 
available soon and the comunity wishing for that feature to be properly 
implemented.

[original example gone]

> > 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.
>

OK, noted that.

> > 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...
>

See below for a comment on index numbers.

> 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.
>

bVertexProperties is supposed to be the link between a vertex and the 
properties assigned to it. This struct is in this current form rather 
inflexible. I'd therefore propose a replacement that would work for edges and 
faces as well.

Defining property sets as a certain type of properties generates trouble 
because you can easily make traversal algrithms recurse endlessly. Just 
create a pair of global property sets that have properties of type "property 
set" that reference each other.

I think that global property sets containing lists of "normal" properties are 
the way to go. At least it's easier to understand.

> 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.

That has occurred to me too.

> 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.
>

Maybe that's a solution. How would you handle that in the UI?

> > 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!
>

The first reaction I got from Willian was that this shouldn't be a problem. 
I'll try to stay in touch with them.

>
> 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
>

Hm... this is way beyond the scope of the changes I initially imagined. 
There's no way I can implement all this (at least by myself). I can make a 
start with per-vertex/edge/face properties and leave the rest (materials, 
textures, lamps, etc.) to others.

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

This will lead to confusion and technical trouble. See above.

> - 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.

No, this is nowhere near sufficient (look at my use cases above - they are 
very real).

>     However... it will be hard one to manage with the current EditMode
> concept, when remodeling the Mesh indices can potentially change.
>

That gave me headaches, too. How are TFaces and MFaces kept in sync at the 
moment? They share the very same problem.

> (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)
>

I come from the game engine side :-). But I cannot speak for the renderers.

> - 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.
>

I fear that there will be no way to remain sufficiently compatible if I 
forked. "Sufficiently" in this case means that properties should also be 
preserved when the file is migrated to an official blender that has a similar 
property system.

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

Actually I wanted to have this discussion. But I don't know how to migrate 
this to the funboard... this discussion is far too technical at the moment.

> -Ton-
>

Regards,
Gregor
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/Hw4OTN1O8kLyTwsRAiPOAJwLDXXqRArapca3KzKpskyYHsP7BwCgpS4I
6n7tBzr0749NsYbO455la3U=
=fTnS
-----END PGP SIGNATURE-----