[Bf-python] Texture module

alex mole nal at blueyonder.co.uk
Tue Nov 11 20:13:43 CET 2003


Hi

I'm working on the draft API, but I have a couple of style questions:

1. Tex.stype means different things depending on what the texture type 
is [if type is CLOUD, stype=0 means "Default", if type is MARBLE, 
stype=0 means "Soft marble", etc]. Should the python API handle this by:

   a) defining an Texture.STypes constant dictionary and returning ints
      for the user to check [a bit like Material.Modes where several
      keys have the same value]
        pros: simple to code API
        cons: harder to code python, possibilty for invalid values to
              be put into stype

   b) interpret the value internally and return an appropriate string
      [for the previous example, return 'default' or 'soft' or whatever]
        pros: simpler to code python, chance for python to validate
              input and raise exceptions if necessary
        cons: much more work to code API


2. Many fields of Tex are bitfields. Should these be returned as 
bitfields for the user to check [as with NMFace.flags], or as a tuple of 
strings. Again the tradeoff is between simplicity to code API vs 
simplicity to code scripts. Also interpreting the data means that we get 
a chance to raise an exception if something doesn't make sense.
[It would be nice to say "if 'interpol' in m.imageflags: ..."]



What are your thoughts?


Alex




Michel Selten wrote:
> On Sat, 2003-11-08 at 05:38, alex mole wrote:
> 
>>OK. I guess I'll try to implement it then [I need it by tuesday... :)]
> 
> 
> great!
> 
> 
>>I'll hack something together just now but after tuesday I'll look at the 
>>interface more carefully and submit a draft API to this list.
> 
> 
> that would be great. With a draft API presented, we can discuss it!
> 
> 
>>My plan is really just to wrap the underlying Tex and MTex structs [with 
>>one class for each], and modify Material so that it can return its 
>>textures as a list. Does that sound like a reasonable idea?
> 
> 
> That's exactly what I had in mind when trying to get started. I just
> never got around at implementing it. You could take a look at how the
> Armature module was implemented. It has a sub-module Bone. This
> mechanism is something similar as to how the Texture module should be
> implemented in the API.
> 
> If I were you, I would look at some present modules as a reference, and
> go from there. The Camera module seems to be the starting point for a
> lot of new Python developers ;)
> 
> If you need help getting the new module initialized correctly, build
> issues, just mail the list.
> 
> With regards,
> 	Michel
> 
> 
> 
> _______________________________________________
> Bf-python mailing list
> Bf-python at blender.org
> http://www.blender.org/mailman/listinfo/bf-python
> 



________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs Email
Security System. For more information on a proactive email security
service working around the clock, around the globe, visit
http://www.messagelabs.com
________________________________________________________________________



More information about the Bf-python mailing list