[Bf-committers] tfaces, makesdna and custom blobs

Jean-Luc Peurière jlp at nerim.net
Tue Feb 21 01:31:37 CET 2006


Le 20 févr. 06 à 22:51, Brecht Van Lommel a écrit :

>
> Hey,
>
> Brecht Van Lommel wrote:
>> But I was thinking, if we break forward compat anyway, we might as  
>> well,
>> you know, break it properly. Like allowing a custom blobs of data  
>> to be
>> attached to verts, edges, and faces, without unified handling of  
>> uv's, colors,
>> vertex groups, and user defined data, for meshes, nurbes,  
>> lattices, .. .
>> That's maybe a bit ambitious, and will further delay multiple UV  
>> sets for
>> those who really want it (hi Campbell :). It doesn't seem impossible,
>> but clearly won't be for 2.42 then.
>> Good idea? Bad idea?
>
> I think it's best to rewrite this now properly, instead having to  
> change things
> again later. So I started drafting a design:
> http://mediawiki.blender.org/index.php/BlenderDev/CustomElementData
>
> Comments and ideas welcome.


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.

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.

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

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

-- 
JLuc 


More information about the Bf-committers mailing list