[Bf-committers] Re: Patch: fixes and additions to python, IpoCurve

Ken Hughes khughes at pacific.edu
Fri Jan 21 08:29:27 CET 2005

On Wed, 19 Jan 2005 at 12:02:50,  Stephen Swaney wrote:

> On Wed, Jan 19, 2005 at 08:33:19AM -0800, Ken Hughes wrote:
>>Here is a patch to source/blender/python/api2_2x/Ipo.c and
>>source/blender/src/editipo.c which do the following:
>>* allow IPOs for material texture channels and world channels to
>>    be added ('addCurve()') and retrived ('getCurve() and getCurves()')
>>* cleaned up the search for named IPO curves (use a binary search,
>>    and uses string/attribute structures instead of individual
>>    strcmp() calls)
>>* fixed inconsistency between Lamp Energy IpoCurve names (you could
>>    add 'Energy' but get 'Energ')
>>* fixed bug in naming of World.MistSta IpoCurve
> It's in progress.  Apologies for the lack of updates.
> A couple thoughts:
> I think we need to make the curve names and values available in the
> API.  Probably thru a dictionary.

I'd thought about that, but hadn't got that deep into how things
work to put it in.  I looked at Texture.c and see how it works
there, and tested my comprehension by adding a CameraFlag dict
to the Blender.Ipo class.  And I think I see how to check for
valid inputs with EXPP_map_getShortVal(). So I can follow through
and add dicts in for the IpoCurves to handle this is that's OK.
But it raises some questions:

* Should there be a separate dictionary for each curve type, or
just one big dict with all of them?
* Should there be a dictionary for the material and world
channels which includes all possible values (i.e.,
OfsX0, OfsX1, ..., OfsX9, OfsY0, .... etc?)  Seems like
overkill, but I can't see another way without adding a
separate method to get/add those curve types.

> The search stuff does need some cleanup!  However, for a small number
> of items, a binary search is no faster than a linear one and also
> requires the data to be sorted.  Keeping it sorted concerns me.  A
> dictionary is another candidate solution here and ties in with the
> first thought.

Agreed; seemed like a good deal at the time, but then I had some more
coffee and woke up.  I'll just put back in the linear search.

> I didn't commit the new texture channel stuff yet because it wasn't
> obvious to me what it was doing.  ( some study on my part will fix
> this! A comment or two wouldn't hurt either. )  Having a test script
> would be Real Nice, both to verify the code and to make my lazy life
> easier!
> Code with lots of magic numbers imbedded in it makes me twitchy.

I'd be happy to add some extra comments to the new code.  I'll also
attach the script I used to test things, but I found it didn't work in 
the current CVS code since there are some bugs.


More information about the Bf-committers mailing list