[Bf-python] Re: Mesh modes

[Campbell Barton]

The problem I have with not using bitfields is this..
Faces and edges are fairly fine grained- Most other areas Lamps, objects 
etc - Its not so important to me.
but for faces here is an example of why bitfields are an advantage....

Say an importer needs to import a large mesh between 5 and 50meg.
You have an object that was properties defined.. So you build a bitflag 
for 10k of faces.
for f in me.faces:
   f.mode = mymode

# Rather then the slower...
mymode = (1,1,0.....)
for f in me.faces:
   f.texface=mymode[0]
   f.tiles=mymode[1]
   f.light=mymode[2]
   f.twoside=mymode[3]
   f.alpha=mymode[4]


Another solution that would be good, would be to have a  face function 
that copied values from another face.
face = me.faces[0]
face.alpha=1
face.texface=1
face.light=1
face.tiles=1
for f in  me.faces:
   f.copyMode(face)

# This gets around using mode




Joseph Gilbert wrote:
> Ken Hughes wrote:
>
>>> 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.
>>
> If your going to check the input by value you have to perform a valid 
> check on all the settable flags.
>
>>>
>>> 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?
>>
> I believe we will go with boolean properties and drop flags and modes.
>
>> Ken, not checking should be good :) IMHO (Faces too - causes similar 
>> errors to mesh)
>
> No. Not checking is not good. Setting inappropriate flag values on an 
> object can cause internal problems.
>
>> However flags can be very usefull esp when storing data for later 
>> use.....
>
> Exactly. One perfect reason for not allowing users to set un-checked 
> flag values.
>
>> eg...
>> faceModes = [f.mode for f in me.faces]
>
> This reminds me of a python principle:
> "If the implementation is hard to explain, it's a bad idea"
>
> I agree though that getting rid of a returnable list (whether 
> flag/mode etc) is a disadvantage in that it makes the API less 
> pythonic imho.  You can't do:
> for x in list:
> instead you need to test a bunch of boolean values
> if x.y and x.z and x.w and x.p and x.z:
>
> However, building and settings lists is more complex when your talking 
> about bitfields etc. then a simple boolean.  Go fish. :/
>
>
>


-- 
Campbell J Barton

133 Hope Street
Geelong West, Victoria 3218 Australia

URL:    http://www.metavr.com
e-mail: cbarton at metavr.com
phone: AU (03) 5229 0241