I know scripting, but knowing the blender api stuff...
I took a quick look. Line 706 is where things start:
materialName = ob.name
if len(ob.data.materials)>0:
materialName = ob.data.materials[0].name
For a test I made a cube with half red and half white as 2 materials.
Dusho's script errors out. Probably because I didn't put textures on it.
I used the regular Ogre3d exporter and it worked. What it does is split the materials into their own submeshes.
I'm pretty sure the def bCollectMeshData(meshData, selectedObjects, applyModifiers): method can be changed to loop over the materials and separate them into the submeshes the same way ogre3d exporter does.
I'll give it a try after some coffee.
EDIT: I got it working! See attached.
Things I changed:
I put a checkbox on to the exporter for "Enable by Material". Default is old behavior.
Added code so that it supports exporting a single mesh with multiple materials as submeshes.
If exporting by material, submesh material names are taken from the actual material name, not the mesh data name.
Now supports multiple textures per material.
There is a catch to the export by material. If you are exporting more than one object and a single material is used more than once, it will probably not do what you want. I was thinking it should combine the meshes assigned to the same material?
Anyways, give it a try. Let me know if it needs any tweaks.
Hey
@Vkoslak , I tested your update for the script, I'm certainly thankful you take time to update it. But there seems to be something off in it. I tried to update my face models for the destro using your script, but when ever TL2 tries to load them it crash to desktop.
I have used your script for simple models and TL2 had no trouble, so I think the issue is with the way the wardrobe handles multi material models.
Since your update the model .xml had this added to it:
<mesh>
<sharedgeometry vertexcount="543">
<vertexbuffer normals="true" positions="true" texture_coord_dimensions_0="2" texture_coords="1">
[LOTS OF VERTEX DATA]
</vertexbuffer>
</sharedgeometry>
That doesn't appear on any vanilla model data I have check. And checking a bit more there are more difference between the "vanilla" .xml and the ones the script is generating now.
Vanilla:
<submesh material="HuM_head_cas01/Chest" usesharedvertices="false" use32bitindexes="false" operationtype="triangle_list">
Updated Script:
<submesh material="Hum_Head_Des01/Hair" operationtype="triangle_list" usesharedvertices="true"
And then the data in every submesh is also different:
Vanilla:
<faces count="40">
[faces data]
</faces>
<geometry vertexcount="30">
<vertexbuffer positions="true" normals="true">
[Lots of vertex data]
</vertexbuffer>
<vertexbuffer texture_coord_dimensions_0="2" texture_coords="1">
[Other Vertex data]
</vertexbuffer>
</geometry>
<boneassignments>
[Bone data]
</boneassignments>
</submesh>
Updated script:
<faces count="120">
</faces>
</submesh>
As you can see, the submesh data now lacks the vertex data and the bone assigment, I see those are assigned in a "shared geometry" but I thing that is what causes TL2 to crash, since the Wardrobe system needs that the submeshes can be treated as separe models and can't do that with a shared geometry.
Tell me what you think and I hope this feedback is useful.
I bet you are right with how the wardrobe system works and the shared vertices crashing the game.
Hell it's been long enough I forgot I had done this. I only tested with simple objects, not armor sets.
I'll see if I can find some time to work on it this weekend.
I should set bugzilla up again for error tracking. Now on github with issue tracking, etc.
https://github.com/RobJames-Texas/torchlight-to-blenderI'll put future changes there.
The branch I forked from had 8 bugs on it already. I may try and fix those once I get this one resolved.
EDIT:
I think I have it.
https://github.com/RobJames-Texas/torchlight-to-blender/tree/develop/torchlight-to-blender/srcI tried it out with TL1 since its easier for me to mess with that.
Let me know if it works for you in TL2 so I can mark the bug closed and merge it to master.
Thanks
@Vkoslak, I'm gonna try it on my heads and see if it's fixed.
Edit: Tested it on the heads for the Destroyer, It works like a charm, the normals are still there and no more crash, checked the .xml and it looks just like the vanilla ones. Great work
@Vkoslak
Cool. I marked the bug closed and pushed to master.
I'll keep poking at this though. There are some things in there that just bug me.
The folder structure makes it a pain to test under windows for one.
The bone import seems really strange to me. I've been looking through other blender plugins like rigify and fbx importer to see how they handle bones. I may end up writing my own bone/animation importer as opposed to trying to fix the existing one.
I may end up writing my own bone/animation importer as opposed to trying to fix the existing one.
uhm, would this be able to import and export .SKELETON animation info? Because
This would be freakin' awesome!!!I won't hold you to this of course
@Phanjam That's the idea. It is something I've wanted since I first started playing with torchlight and blender so many moons ago.
There already is a decent exporter (ogre scene exporter), but it's not exactly user friendly. The skeleton xml it spits out contains all the animations in one file, so you then have to spit it up manually. Although I could write a tool to do that if I found myself doing that enough. I have used it to make new animations for a couple of NPC characters I played around with. A cool thing about the ogre scene exporter is it has built in preview mode if you have ogre meshy. The scene exporter has way more features than needed for character export though. So using a subset of its code to make something catered more towards mesh/rig/animation export would be a good project. Then I could make it split the animations up as well.
@Phanjam That's the idea
I'm all a-quiver! The fact that we can't export animation info to .SKELETON has been an excuse for me not to learn about the animation side of Blender. If we actually had an exporter I
would put the hours into learning animation in Blender (again, not holding you to this)!
Hey
@Vkoslak I have trouble with the script again
Now I'm getting an error when I try to export weapon modesl, It even happens if I import a vanilla weapon and then try to export it.
Here is the error I'm getting:
From what I can understand the script is looking for a property on the model and It won't find it, but I don't know what property is. Also changing the export parameters doesn't fix the issue.
I case fixing it is too much trouble, could you change the identity of your updated script, so I can have it installed for working on Armors, and install the old dusho version for weapons?
It's looking for a skeleton. It should be an easy fix.
