Blender Exporter 0.5 Available

#1 Yay! Thanks a lot! :D

#2 Wow... really impressive James! I am dead certain this code will find a use here.

THANK YOU!

-J

#3 I cant export the textures with the meshes. first i've seen that using a material name (or texture one) with the . cause the plugin to be fuzzy when exporting and also when i create a material and mantain the "Material" name on it. however, i select the mesh, i go to the material pane and add a material, in the right pane (Texture pane) i create a new texture, in Map Input i set UV. After i go to the Texture section, and load the image file. in the 3d view i press ALT-F, go to UV editor and load the texture loaded before. now in blender the texture is correctly displayed but when i export there's only the mesh in there. I've tried to use the Update button in the plugin GUI but no changes.
The output window in blender doesnt show any error. but i've seen that i cant delete the generated .dts file after exporting. i've to close Blender. however exporting more times updates the .dts
are there missing steps? i like whery much this plugin, it's a very well done work :)
hope to find a way to resolve my issue

#4 Elvencode,

Could you post a screenshot to better illustrate your problem?
Are you missing meshes in your .dts?

As for the materials, simply make sure you assign Blender Materials to your meshes. Also make sure all the faces in your mesh have been assigned this material too!
If any materials are missing at load time, torque will tell you in the Console.

As for the .dts still being open... Whoops :)
Didn't quite notice that... a simple fix requires you to alter the __del__ function in Dts_Stream.py :

def __del__(self):
		self.clearStreams()
		if self.fs != None:
			self.fs.close()
			self.fs = None

(when copying this in, be sure the tabs indent the text in the correct manner)
I also put this small fix into the exporter scripts on the resource.
I took a quick look at the other functions where i open/close files, and it seems ok :)

If your shape still doesn't export properly, email me the .blend and i'll take a look :)

Thanks,
-James

#5 More info on getting Python and Blender to work on OS X : www.widomaker.com/~katorlegaz/blendertips/python.html

#6 Charles,

Do you use OS X? Did you get it working? :)

#7 Yep - OS X and FreeBSD, I'm still 'in process', I'm still on 10.2, I really need to update. I'll keep you posted.

#8 Well, I have been using the exporter a bit. And have run into a few problems.

1)
If a certain mesh has no vertices, it should not be exported... this is fair enough. But, the script fails due to a "ref-before-assign".

- This I fixed by indenting a little further on the if-statement.


2)
Every surface exported is assumed to have 3 vertices... this is not always the case (????). These surfaces generates an index-out-of-bounds-kinda-error...

- Since I was unable to find the damn 2 verticed-surface I just placed a test on the source, thereby ignoreing surfaces that have less than 3 vertices.


3)
The exporter works fine now, except that now, Torque crashes due to an error in mPlane.h (something about vertices NOT creating a plane...)

- This error I have not been able to fix, and I have a suspecion that its the two-vertice-surfaces lurking... (since they have to be present to get the malformed dts-file).



Have any of you an idea about the sanity of these modification ?, I would like to hear what you think of it.

#9 Two general questions

Why are my collision-meshes are not rendered (could they be...) ?

And why I get at least two detail-levels when I have both collision-meshes and normal meshes, should one not be enough ?

Thx.

#10 Emanuel,

Firstly, your collision meshes.
In the -show tool, you should see them in one of the last detail levels. You should also be able to collide them in-game. You cannot however *see* them in-game, which sort of makes sense :)

The reason you get 2 detail levels is because you need seperate collision details for each convex collision mesh.

Now, your questions.

1) If a certain mesh has no vertices, it should not be exported... this is fair enough. But, the script fails due to a "ref-before-assign"

Where did this occur? I have not yet encountered this bug. Please tell me so i can fix it accordingly.
I have never made any meshes with no vertexes in (since it would be pretty pointless).

2) Every surface exported is assumed to have 3 vertices... this is not always the case (????). These surfaces generates an index-out-of-bounds-kinda-error...

Every surface (or rather, face) is actually assumed to have 3 OR 4 vertices. In the case of 4, it is split into 2 triangles.
I don't quite get the purpose of 2 vertex surfaces (since they would NEVER be seen in the game anyway), so i never encountered this issue.
The maximum vertexes used to make a face in blender is 4 the last time i checked.

3) The exporter works fine now, except that now, Torque crashes due to an error in mPlane.h (something about vertices NOT creating a plane...)

Make sure each of your collision meshes are convex.

Hope that helps,
-James

#11 The reason I got all these "errors" was that I'm not very familar with blender, thus I might have deleted some surfaces/vertices/etc. This is what resulted in the empty surfaces, the 2-point-face, etc.

Here is the "modified" code to get around these situations:

1) The empty mesh

if len(msh.verts) != 0: # No use exporting if no verts  
           tmsh = BlenderMesh(self, msh, meshType, len(self.nodes) -1 ,  self.scaleFactor, MatrixF(cmat))

I have indented until, and including:

# Add Object and mesh to the detail level 
           det.objects.append(o)    
           det.meshes.append(tmsh)    
           print "     Import : %s" % (realname)

2) The 2-point surface

I added a simple if-statment around

177>         self.indices.append(...)
178>         self.indices.append(...)
179>         self.indices.append(...)

like this:

if len(face.v) < 3:
           print "Odd, a surface with less than three vertices... ignoring it"
         else:
           self.indices.append(self.appendVertex(shape,msh,matrix,scaleFactor,face,2))
           self.indices.append(self.appendVertex(shape,msh,matrix,scaleFactor,face,1))
           self.indices.append(self.appendVertex(shape,msh,matrix,scaleFactor,face,0))

3)
I had no collision meshes in the Dts, but I traced down the mesh causing it, and deleted it. Thx to blender I cannot undo that :/


Then a new question, the Dts-importer, is that serious ? I would love to have one, just to be able to import Dts made with 3D max.
If it is, I could write in gui for it making it possible to select the files when importing.

#12 Emanuel,

A better way to stop it from exporting a mesh would be to remove the check from that statement, and place the following at the beginning of the loop (after it gets the msh object) :

if len(msh.verts) == 0:
	continue # skip to next mesh

As for the number of verts in the faces problem, add this check when it is adding the faces, like so :

for face in msh.faces:
	if len(face.v) < 3:
		continue # skip to next face

As for the DTS Importer, i mainly used it to test the shape loading routines. As such, its a bit buggy in places, and by no means complete.

#13 Keep up the good work James, we appreciate it.

#14 First, thanks for working on this as it makes my life much easier. I have run into a few issues with it. The first of which is caused by using constraints in my blender animations which requires me to BAKE my actions before I can export them.

This produces an action called Action.BAKED and the corresponding IPOs are then called Action.BAKED.Hand.R. The script will then try to export for a node called BAKED.Hand.R which doesn't exist. For my specific case, I hacked Dts_Blender_Prefs.SplitIpoName to as follows:

def SplitIpoName(name):
	splitted = name.split(".")
	if len(splitted) < 2:
		print "Un-analysable IPO name :", name
		return None, None
	animation_name = splitted[0]
	bone_name = splitted[2]
	for i in range(3,len(splitted)):
		bone_name += "." + splitted[i]
	return animation_name, bone_name

It would obviously be better if there were a test done on splitted[1] to see if it was equal to "BAKED", but this gets my by for my use right now.

This isn't so much a bug in the exporter as it works as you said, adding something to compensate for the .BAKED. would make it more flexible though. Also, since blender has a limit on name size, I changed my blender to use .B. instead of .BAKED. so if something like this is supported, it'd be nice to have some flexibility on how it was implemented. Maybe drop pieces of the name until it actually matched a bone/node or let you configure pieces to ignore.

I also believe there was a bug in the code though as the line in the for loop use to be:

bone_name += "." + splitted[2]

I changed the 2 index to i.

#15 The second problem I ran into was an index out of range problem in Torque_Util.writeIntegerSet. The length of bits passed into this function was 124, integer divide of 124 by 32 results in 3, but the real answer is 3.875 so use was one too small.

My new code for computing use is as follows:

if  len(bits) >= 32:
		use = (len(bits) + 31) / 32
	else:
		use = 1

This has gotten my exporting working, not sure if torque will accept the output yet, :-).

#16 Todd,

I will try these fixes out.

The bits fix :

Use really needs to be rounded to the next whole number. (i have used round here, but its not quite the right function to use)

use = round(len(bits) / 32)

The ipo fix :

I will have to look into these "BAKED" animation names. However, you could always alterntively rename the ipo's :)
Not sure how that 2 got in there... wierd.

Thanks

#17 Hehe, rename the ipos he says ... well maybe if I didn't have 132 bones I'd consider it, :-).

Btw, Zaz<->Todd, changed my profile.

I considered round() also, but like you said, it isn't really the right funtion as 33 bits needs 2 words and not 1. I noticed a bunch of calls to that function, IntegerWriteSet, also to write 0 bits, which seemed odd to me.

The exported animations sort of worked. My model was animated and I believe sort of the way I animated it. However, the animated model itself was a mess so it was hard to tell, sort of turned inside out. The static model looks fine and always has. I'll play with this more and see what the problem is, it might just be the insane, for a game, weight painting I had to do, lots of overlapped vertex groups.

I'm new to torgue, so I'm just getting started and trying to export some of my old blender animated models and get them working in the game as an exercise. So, I'm not sure if having that many bones is really going to work in torque, its just what I'm playing with now.

How useful supporting BAKED ipos is depends on the complexity of the armatures/skeletons that can be used. The models I'm playing with now were intended for rendered animations and a high degree of realism. I expect that moving these to the game engine will require simpler animations and skeletons/armatures. I could easily be wrong though as I definitely don't have any idea what torque's limitations are for this, either hard or just performance limited.

But supporting BAKED IPOs somehow does allow one the flexibility of using blender to shape your animations with constraints. Even some simple forms of animations would benefit from this, say having two radar dishes linked so they always rotate the same (Copy Rotation constraint), etc.

Another useful option to consider would be the exclusion of certain bones. This would be good with supporting BAKED IPOs. For example, I use a lot of IK constraints. These require a lot of null bones and ik bones to make them work and these bones are only useful for the constraints they are involved in. They don't deform anything, they just move other bones.

My convention is something like ThumbNull.R and IK_Thumb.R, excluding *Null, *Null.* and IK_* would eliminate the export of a lot of useless bones/nodes to torque in my case.

Anyway, if you do something to support any of this stuff, great. If you don't, its likely I'll add something at least to my version of these scripts at some point. If you're interested in changes like this, I'd be happy to get them back to you for inclusion in your version as I'd rather not maintain diffs anyway, :-).

#18 Zaz,

Make sure the ipo names are not too long. Otherwise, blender will clip the name, and thus the exporter will not find the bone (though it returns 0, instead of None, so things sort of mess up. But i fixed that)

I already have a tool to remove nodes from the export process; Add the name of the bones you want to exclude to the "NodeException" section of the .cfg file - Not tested this myself, though it should work (as long as its not animated).

As for the bits, i need something equivalent to the ceil() function. But i can't seem to find it in python...

If you do have any more improvements, throw them my way :) - I am currently waiting on a few things before i release yet another update.

#19 Yeah, I ran into the name limit issue with the ipos. I had to rename actions even after I changed blender to add .B. instead of .BAKED. to the baked actions. I am getting non-zero node numbers during the export everywhere now, I wasn't before.

Good news about the NodeException section, I'll look at that. I expect I'll have to expand on it though as when you bake an action every bone gets a key frame every frame. Having an absolute hard exclusion for bones would be best. But if you've got something in there already, it'll probably be easier for me to hack something in to do a hard exclusion.

The expression "(len(bits) + 31) / 32" does basically do a ceil. (32 + 31) / 32 = 1 and (33 + 31) / 32 = 2, assuming integer math of course. You likely know python better than I as my python experience is limited, but I've been using it as it was and it appears to work. One of my animations never hit this function and its as broken as the ones that did, :-).

Glad to send anything I do on this your way. Do you have an estimate on your next release date, just a very rough one, like a few days, weeks or months ? Just curious as I've got other work pressing now and I'm sort of procrastinating working on this atm. If you're going to release something soon, I'd be more likely to try to look at getting a change or two your way sooner than if you won't be releasing the next version for a while.

#20 Zaz,

Hopefully i will release something this weekend, or alternatively next weekend.