Major language change in 2.4?

Coding Python Support
#1

i got told today by some user of a script of mine that it does no more work on blender 2.40 final. i poked through the code but it does not make sense at all. the following code:

  		self.bones.append( DEBone( self.armature.bones[index].name, index ) )

produces error:

Traceback (most recent call last):
File “<string>”, line 663, in fileDialogCallback
File “<string>”, line 398, in export
File “<string>”, line 351, in initExporterObjects
File “<string>”, line 242, in initAddVertFaceEdge
AttributeError: ‘NoneType’ object has no attribute ‘name’

armature is the armature object i have in the scene and is the armature data, not the armature object. ‘index’ simply iterates over 0 'til length of bones list. the strange thing here is that the ‘bones’ list seems to store a ‘None’ object as bone.

i have no idea how it can happen that the armature has a ‘None’ bone object? has the interface majorly changed or is there a bug in the new python modul?

( i can not test myself as blender 2.40 is not yet in gentoo portage )

#2

There are a couple possible reasons for this that I can think of:
Blender 2.40 is the first release to use Python 2.4.
The armature code has been majorly rewritten.

#3

Blender 2.40 is the first release to use Python 2.4.

True, but kinda, sorta irrelevant.

The armature code has been majorly rewritten.

Quite true and very important. Blender’s armature code has been rewritten. Since BPy talks to that code in an intimate way, it too is changing. Old stuff will break. You can get help on the developer’s forums and mailing lists.

i have no idea how it can happen that the armature has a ‘None’ bone object?

One way for that to happen is if a method like bones[index], for example, returns None for an index out of range instead of throwing an exception. (Disclaimer: this is only an example - I did not look at the Bone code) Then, when you do bones[index].name you are really doing None.name which gives the exception you see.

We are starting an API cleanup to fix some of these problems and remove some inconsistencies.

Hint: if you have a list of length len, the list index runs from 0 to len-1. Three cheers for iterators that free us from the tyranny of counting things.

#4

that’s true, and heavily welcome. in this situation though i need the index iteration as i need to iterate (later on) over two arrays of the same length (i’m kinda building my own bone list with informations i need for proper exporting), hence the iteration is:

for index in range( len( self.mesh.bones ) ):

works well in 2.37.

as soon as there is a new api online i can start fixing that stuff. i already assumed things changed as otherwise i can not imagine how a ‘None’ object gets under my fingers in a list generated by blender :wink:

#5

for index in range( len( self.mesh.bones ) ):
works well in 2.37.

This is the correct way to index over a list. The range() func automagically does the 0 to len-1 thing.

i already assumed things changed as otherwise i can not imagine how a ‘None’ object gets under my fingers in a list generated by blender :wink:

The new Bone API is definitely a Work In Progess! What you are seeing is a bug.

Armature.bones is a dictionary whose keys are the bone names. Right now, for an invalid key like A.bones[0], it is returning None instead of throwing a KeyError exception. This should be corrected in the forthcoming bug-fix release.

Online doc for 2.40 is here:
http://www.blender.org/documentation/240PythonDoc/index.html

#6

can you forward that bug-report to the right places? i only know this place here.

#7

I too am having problems running scripts written for 2.37 in 2.40. I have struggled through some of the changes to the Armature module and have now run into difficulties with the getVertexInfluences module. This returns an empty list [] :frowning: . Is there a quick fix?

#8

Hi we will have 2.41 out in a bit less than a week which is to fix API stuff among other things.

For bug reports you should use the blender bug tracker

http://projects.blender.org/tracker/index.php?group_id=9&atid=125

(you will need to create an account before you can report the bugs though…)

LetterRip

#9

I noticed that you have written code to generate normal maps

http://sourceforge.net/forum/forum.php?forum_id=525059

Ideasman has written a sculpting script that allows sculpting similar to zbrush (myself and Michael Schardt wrote an earlier sculpting script but Ideasmans incorporates a number of nice improvements).

https://blenderartists.org/forum/viewtopic.php?t=56101

It might be a great idea to integrate your normal map generation code with Blender. Then one could create the base mesh, sculpt in the detailed information, and create the normal map all in one package.

LetterRip

#10

has this bug been filed already? i’m sorry to ask but i have never used bug trackers like this. i just don’t know how to use them ( i can program you entire game engines but with bug trackers i’m on warpath :expressionless: )

Ideasman has written a sculpting script that allows sculpting similar to zbrush (myself and Michael Schardt wrote an earlier sculpting script but Ideasmans incorporates a number of nice improvements).

https://blenderartists.org/forum/viewtopic.php?t=56101

i’ll have a look at this one. it sounds very promising and usefull.

It might be a great idea to integrate your normal map generation code with Blender. Then one could create the base mesh, sculpt in the detailed information, and create the normal map all in one package.

the idea is good but there’s a small catch: performance. i had to make a couple of c++ hacks to get a reasonable speed out of it. my dragon armor already takes around half a minute to produce a 2048x2048 normal/height map of only the torso+neck. python is horribly slow for raw math performance. i could turn this into python but that would be very slow, unless i could do something like a c+±python module and use this. that though would require installing a system-wide python normal map module and link it into the script. i have never worked with python c++ modules before. i could take some read and do it though. furthermore a preview is not possible unless blender learns tangent-space normal-maps. the current 2.37 version does support only object-space normal maps and that is useless. will the new blender version have tangent-space normal maps?

#11

Hi - I meant integrate your code directly into the core code as an internal library - you can use C or C++. The sculpting script is hoped/planned to be ported to C as well (If you can help with that great - if not I think I can probably do it). Tangent space normal maps should come hopefully in the release after 2.41 - if sculpting and a normal map generator are integrated it would definitely put a fire on to get that part of the coding done.

LetterRip

#12

As to the python bugs - I will make sure they both get corrected in the next release,

LetterRip

#13

i’ll have a look at it… currently i’m though rather busy with other stuff.