[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