[Bf-committers] tfaces, makesdna and custom blobs

[Brecht Van Lommel]

Hi,

Jean-Luc Peurière wrote:
> we discussed quite at length with zr about a very similar thing to use as
> selection and properties holders for modifiers that want to add custom
> datas.
> 
> For object mode we were thinking about something similar but in edit mode
> it is quite more complex. one of the key points seemed to be how do you
> insure that all tools will correctly handle vertex/edge/face add or 
> delete ?
> 
> and even if it is not authorized in edit mode (which imho it should), you
> still need to handle editmode changes of the mesh.

This is intended to work as a unified api for practically every module (except
render). This includes edit mode, radiosity and booleans that require the
data to be packed per vertex/edge/face, and not in large arrays.

> that means that you will need either callbacks or some kind of event system
> for each topology change because the tool that will add or remove things
> from the mesh do not know how those properties should be added or
> removed, & unlike the simpler case of tfaces you cannot assume it is interp
> only imho.

> for example on a edge divide, if the initial edge is marked, you want to 
> mark
> the 2 new edges, and this information is not available just from
> surrounding, but from ancestors . And you cannot handle that in the tools
> themselves.

> this may also means we have to move tools acting on topology to Eulers
> like operations, or provide to the property method the previous elements
> which are replaced.

Yes, interp only is not sufficient, as I said, that list of callbacks is far 
from final.
I probably won't be able to figure out what is need in before I actually code
that part, will require some experimenting.

> Can you explain a bit more your ideas about groups ? At first glance i dont
> see how it works efficiently ?

It's the same as vertex groups are done basically (MDeformVert). There's a
dvert array in mesh that for each vertex contains a totweight giving the total
number of groups for that vertex and a void pointer pointing to an array of groups
and their weights for that particular vertex.

This would work similarly for more general groups, except that the size of each
group can be different. But there's a pointer to that group, so to get to the next
group in a vertex you do + group->size.

Not as efficient as layers of course, but not sure how to do it otherwise, and
I have never heard complaints about vertex groups making things slow.
Manipulating groups efficient might require quite some more cooperation of
the code calling the element data API, compared to layers.

> that said, your early design seems to fit the needs rather well.
> Maybe need also to provide accessors/setters methods for a given index ?

Yup, get/set at index will be there.

Thanks for the input.

Brecht.