Blender COLLADA -> T3D skinning(Solved)

#1 I've not tried getting armatured meshes in via Collada ... but if you haven't already checked out the correct export hierarchy --- go hither.

I've got "normal" TsStatics in using this no probs:


The amount of trouble I've had with armatures and animations and the sort in the past I figured sticking with DTS would be easier.

In a kind of "don't fix what ain't broke" attitude.

#2 Hi Bryan,

There's been a few changes to the collada import pipeline for the next release of T3D. If you send me the file that is crashing I'd be happy to take a look at what is going wrong.

#3 I can't actually tell what I did to fix the crashing, and I don't have any copies of the .dae from when it was crashing. After I first posted I did some random tweaking to the node names and then next thing I knew it suddenly stopped crashing. My current node heirarchy seems to work:

Unfortunately now I'm having a problem with T3D importing the data and translating the skeleton nodes some distance to the left for some reason(even though I created the bones in the center so never had to translate in either direction)

If anyone feels like having a closer look at my files, here's the blend file.
Also here's the most recent DAE file if anyone really wants to have a look at it.

#4 No idea what has happened there, but try the hierarchy I've posted and see if it makes any difference.

#5 Both node hierarchies are basically the same thing, and the node hierarchy would have no effect on the positioning of the nodes after importing to T3D. I'll have to wait until this weekend before I have the time to start over from scratch since it's quite possibly related to the fact that I first tried to export it with the mesh as a child of the armature, which obviously wouldn't work in T3D, and perhaps I did not undo everything.

#6 Hi Bryan,

I took a look at your exported collada model, and I get the same 'offset' skeleton problem as you, so it's not an issue that is already solved in T3D trunk.

I have a couple of other test models that are not skinned correctly when imported into T3D (though with different symptoms as yours) so it is possible that there is still an issue with the importer.

Are you able to import your exported model back into Blender and check that it displays correctly? That would help eliminate if this is an export problem or not.

#7 Also something to try - when exporting to DTS, Torque requires that skinned meshes are at the root level. Since both DTS and COLLADA end up as 3space shapes, some of the same limitations apply to COLLADA-for-Torque.

Could you try moving your skin object to the root level of the hierarchy (ie. at the same level as base01)?

#8 Argh...Seems the COLLADA 1.4 importer is bad with the version of Blender I've got. I'll have to wait until I've got time to replace that plugin or reinstall Blender before I can test if it's something in the .dae file itself which is causing the nodes to be offset from the mesh. I believe the hierarchy I'm using is exactly what you suggested in this thread, but I'll have a go at putting it at root later. Somewhat amusing looking at the date of that thread and realizing that I've actually been trying and failing to get a rigged mesh into Torque off and on for months now.

#9

Quote:Argh...Seems the COLLADA 1.4 importer is bad with the version of Blender I've got.

Why do you say that? Did blender fail to import your DAE file?

#10 Oh, yeah. Probably should have mentioned that :P
Based on the errors the importer gave me though it's not likely a problem with the DAE file itself and something in the importer's code was being silly because it couldn't find some function.

#11 Just to pipe in, I can't get any *.dae to import into Blender, so yep, I guess importer based issue.

#12

Quote:Based on the errors the importer gave me though it's not likely a problem with the DAE file itself

As I said, I'm still not sure whether this is a problem with the T3D importer or with the DAE file. The skeleton shows up offset in at least one other application (UltimateUnwrap3D) as well, but I was interested to see if it shows up correctly in blender.

#13

Quote:As I said, I'm still not sure whether this is a problem with the T3D importer or with the DAE file. The skeleton shows up offset in at least one other application (UltimateUnwrap3D) as well, but I was interested to see if it shows up correctly in blender.

Hehe, well as the COLLADA 1.4 importer plugin in Blender is actually broken the answer to that would be no, unfortunately if the offset nodes are appearing in other applications it's likely that either the COLLADA exporter in Blender is also broken or I performed some form of translation that didn't get set or reset before export(the latter is unlikely as I created the nodes at the spots I desired them and the only translations performed were in the Z direction in Blender to push the nodes into the mesh as they were created in front of the mesh initially). It looks like Blender has been updated since I last installed it, so I'll reinstall that and recreate the mesh this weekend when I find the time.

If it comes down to it I can write my own COLLADA exporter/importer plugins to be sure that it is in fact using the standards and can be loaded correctly by T3D (just in case T3D isn't sticking to the standards). I'm still reticent about exporting to DTS because then I will need to reexport as another format if I want to tweak the mesh in another program, and I would also like to make additions to Blender's COLLADA exporter anyways so that I can create PhysX objects in it since I am not likely to have the $3000+ for 3DS Max or Maya anytime soon.

#14 Well I finally got around to reinstalling Blender, testing out the import/export and all that mess and it appears that either the importer, the exporter, or both are broken. I first tried it in Windows and the error messages were thoroughly unhelpful, and then I fired up Linux and tried it out and it looks as if the importer does work, but the exporter is doing something bad to the dae file so that some or all the nodes are invalid as far as the importer is concerned and fails. From what I've been able to find out, the COLLADA 1.4 plugins for blender haven't had a proper update since 2007, and while I could write my own COLLADA plugin set it would take me a considerable amount of time for something I just won't get much use out of compared to the relative development time. I guess this means that I will either have to bite the bullet and use the DTS binary exporter, or just give up on doing any of the artwork and just hope eventually I'll have the money to pay someone to do it properly.

#15 I haven't been able to get working, correctly aligned armatured models out of Blender's DAE exporter either.

Is DTS really that bad?

#16 @Steve: Did you have the same problem as Bryan? ie. the armature nodes did not line up with the mesh?

#17 @Bryan: I'm not a Blender user, but I'm interested to see this problem through so I downloaded the latest version. The importer failed to import your monkey.dae file for me as well, but the console errors revealed it to be a problem with importing the physics objects. I manually removed these from the DAE file and it now imports ok.

Interestingly, importing the model into Blender shows the same problem as T3D => the skeleton is offset to the front and side of the mesh, so I think it's fair to assume the problem lies with the Blender exporter.

All is not lost though. I was able to get the skeleton and mesh to line up in T3D by applying a simple offset during loading. If the Blender exporter always makes the same error when exporting, I could just make my "fix" an option in the T3D Collada Import GUI (much like the "ignore bone scaling" option fixes certain skinning problems that come out of the MAX and MAYA Collada exporters.

I'd be very interested to see if the same fix would apply to any skinned model exported from Blender, so if you (or anyone) can provide some more examples to me that would be great.

I will also take a quick look at the Blender Collada exporter source. My python-fu is not that strong, but I might be able to see if there are any obvious problems that could be easily resolved.

#18 @Chris
Yeah, it's all offset and funny with exporting an armatured mesh. Fine with a normal mesh *.dae though.

#19 There shouldn't have been any physics data in that file as I explicitly set the exporter not to export any, and there wasn't any in the blender project to begin with. When I made my previous post I had exported the default blender scene without any changes and then imported it again. In Windows I got a missing dll error, meaning bad plugin, and in Linux I got an error when trying to read in the geometry so the physics shouldn't have anything to do with it. It's obvious the plugins need fixed, but I don't really have any experience with python or the Blender plugin API. Are either of you using 64-bit Windows? If so, 64-bit or 32-bit Blender?

I would much prefer if the importer GUI did not get cluttered with options for enabling fixes due to broken exporter plugins, and would much rather see the plugins get fixed themselves. If the node offset is an easily reproducible problem it will be easy to get fixed by the Blender plugin developers, and even though I'm not too familiar with Python or the Blender plugin API I could probably fix it myself given enough time. I don't really have a whole lot of time to spare just now, and chances are in the next month or two I'll be shipping out with the Navy so I've no idea what time I'll have then, or even if I'll have access to a computer, but I'll still see this through until the bug can be pinpointed and fixed.

#20

Quote:There shouldn't have been any physics data in that file as I explicitly set the exporter not to export any

And we know the exporter is reliable, right? ;-) If you open the DAE file you link to above in a text editor, you'll see it contains several <rigid_body> physics elements.

I'm not using 64-bit windows.

Quote:I would much prefer if the importer GUI did not get cluttered with options for enabling fixes due to broken exporter plugins

I agree - that is the ideal outcome. However, the last update to the Blender plugin was back in July 2007, which doesn't fill me with much hope that a fix will be forthcoming anytime soon!