[Bf-python] Mesh Layers

[Campbell Barton]

Martin Poirier wrote:
> --- Campbell Barton <cbarton at metavr.com> wrote:
>
>   
>> for people who dont read the CVS logs, heres some
>> additions that may need some looking into.
>>
>> Variable names an functionality 
>>
>> exposed CustomData_get_active_layer_index in
>> BKE_customdata.h (needed by python to get the active
>> layer)
>>   
>>   added python api stuff to deal with Color and
>> UV/Image layers.
>>   
>>   me.activeUvLayer - int
>>   me.activeColorLayer - int
>>   me.totUvLayers - int
>>   me.totColorLayers - int
>>   
>>   me.addUvLayer()
>>   me.addColorLayer()
>>   me.removeUvLayer()
>>   me.removeColorLayer()
>>   
>>   Variable names may need changing.
>>     
>
> You should capitalize the Vs in UV. It's a coordinate
> system, not word, so case doesn't apply as it does to
> other words. Also, please use total, not tot.
> Obfuscating a name for two letters is not worth it.
>
> activeColorLayer and activeUVLayer are read/write I
> assume?
>
> If no layers are present, active should be -1. (it
> would follow the Python convention for absent
> indexes). 
>
> Trying to set the active values to anything out of the
> usable range should raise a ValueError.
>
> Any change to the active values for mesh with no
> layers should raise an error (that is implied by the
> previous suggestion, but maybe the error message
> should be different).
>
>   
>> At the moment adding always makes a new layer at the
>> end array and removing always removes the active
>> layer.
>>     
>
> removeUVLayer(index) and removeColorLayer(index) (with
> index default to current if absent) would be nice.
>
> (although in this case, remove is not usually used
> with index, pop has no place here I think, since the
> layer is not returned)
>
> When removing the current layer, should be changed to
> the following one (following iterator logic, IIRC),
> looping back to the first one if the last one is
> removed.
>
>
>
> -------------
>
> Just a thought, wouldn't it be better to have layers
> object instead? With access like that:
>
> me.UVLayers  -> layers object
> len(me.UVLayers) -> total (PySequence_Length)
> me.UVLayers[n] -> access to layer n
> (PySequence_GetItem)
> del me.UVLayers[n] -> remove layer n
> (PySequence_DelItem)
> me.UVLayers.active = n -> set active layer to n
> (custom method) 
>
> All other methods of the sequence protocol should
> fail.
>
> Opinions?
>
> Martin
>   

Thanks for the feedback, initialy I was going to add remove(index) but 
it fell by the wayside...
Uv ->  UV, good rationale. tot -> total ok too.

activeColorLayer and activeUVLayer - both w/r ints.
active is -1 if no layers exist.
setting out of the range raises an error.
- need to make a different error for no layer meshes. good point.

agree on removing, Ill have to look into that, see how customData 
functions do it and use them to work as you suggest.


More interestingly having me.UVLayers is somtrhing I thaught of but I 
cant justify yet
because your not accessing the data through me.UVlayers, its just a way 
to add, remove, get/set active layer.

what would the value of me.UVLayers[0] be?

It looks liek layers will eventually have names (brecht is saying he'll 
add it and there seems to be some code that deals with names alredy) so 
maybe
me.UVLayers[0] = 'LayerName'
name = me.UVLayers[0]

Probably have

me.UVLayers.new() # or add() or insert()
me.UVLayers.copy(layer_index)

problem with defining a new pytype is that people will expect it to do 
stuff like

me_a.UVLayers = me_b.UVLayers
or
me.UVLayers[0] = me.UVLayers[1]

and where does it all end?,
In this case I prefer a few commands that do explicit operations on the 
layers rather then wrapping them into a new pytype that has missing 
functionality,
but well see how it goes.

- Cam