[Bf-python] Re: Mesh modes

Ken Hughes khughes at pacific.edu
Tue Jan 31 05:49:25 CET 2006


Ken Hughes wrote:
> Campbell Barton wrote:
> 
>> Ken some problems setting mesh mode- have had the same problem
>> http://www.elysiun.com/forum/viewtopic.php?t=58639 -
>>
>> I have the same problem on a simple mesh with 2.4.1
>>
>> mesh.mode = tempMe.mode
>> ValueError: invalid bit(s) set in mask
>>
>> According to DNA_mesh_types.h
>> ME_TWOSIDED = 4
>> ME_AUTOSMOOTH = 32
>> ME_NOPUNOFLIP = 2
>>
>> What is currently in the tempMe.mode is off by one. I set each mode 
>> one by one in the ui and did the export with a print of the tmpMe.mode 
>> to see them.
>>
>> If you change the code mesh.mode = tempMe.mode to mesh.mode = 
>> tempMe.mode - 1 it works.
>>
>> Any ideas on why it's off by one?
> 
> 
> It's not off by one, it's off by a ton.  There are many other bits missing:
> 
> /* me->flag */
> #define ME_ISDONE        1
> #define ME_NOPUNOFLIP    2
> #define ME_TWOSIDED        4
> #define ME_UVEFFECT        8
> #define ME_VCOLEFFECT    16
> #define ME_AUTOSMOOTH    32
> #define ME_SMESH        64
> #define ME_SUBSURF        128
> #define ME_OPT_EDGES    256
> 
> so the range-checking code in Mesh is complaining because it's not 
> looking for all of them.

Actually, the fix for this is either to (a) add more values in the 
range-checking for the mesh.mode setter or (b) not do any checking. 
Seeing as how this is a bitmask, I'm favoring right now not doign any 
checking since this interface will change in the API refactor.

Which brings up the question, what was the decision for handling 
bitmasks in the new API?  Neither of the wiki pages on the refactor seem 
to lists any decision.  Have none been made?

Ken



More information about the Bf-python mailing list