Blender DAE Exporter for HWRM

(Siber) #121

Not really, as it seems you were right. Got some help from someone more familair with blender than I, and it seems I needed to ctrl+A all the joints, but only their rotations.

(Siber) #122

All working right now. Applying all the rotations and then reseting the origins was the key.

If I’d been real smart I would have fixed one turret and then cloned it instead of fixing all of them manually. I guess I’m not quite that smart.

(Siber) #123

I streamed my next stab at rigging a ship for my team, and the archive of it is here:

It is ultimately succesful, so it might be helpful to people trying to learn the process, and it’s a bit fumbling, so it might be helpful to people looking for places the toolkit can be improved. It’s also 1h16m long, and I have crap upload and a terrible microphone, so… you’ve been warned about htat, now.

(Sastrei) #124

@DKesserich - are there any known issues around exporting “translation” animations as opposed to “rotation” animations? I made sure tangents are set to linear, and the rotation animations seem to work fine, but translation animations seem to be missing/not exporting.

(D Kesserich) #125

I hadn’t tested with transform animations. Just checked the Kadeshi Fuel pod by importing the FBX, exporting it back to DAE, converting it to FBX in Visual Studio and then importing that FBX and it looks like only the rotations made it.

I’ll try to look into it. It’s hard to compare because the animation exporter is kind of dumb and works on every single frame in the selected frame range instead of just keyframes, so I think I’ll have to optimize how that works and that might take me a while.

(D Kesserich) #126

Actually, I’m dumb. There was a typo in the translation sections, forgot a dash. Just pushed the fix so if you just grab the latest from Github it should work.

I’m probably still going to re-write how it’s doing the animations though, since the export times can get pretty long and the file sizes themselves get nuts (like 22 megs for the Kadeshi Fuel Pod versus the 1 meg that the original version is).

(Sastrei) #127

Haha, yeah I noticed the DAE it generates for the ship I’m working on is 80-some MB. But the HOD and MAD pop out at the proper filesizes, so I’m happy! Will download the new version and try it out. Thanks!!!

Hmmm @dkesserich, I grabbed the new files off github and replaced them, triple-checked for linear tangents on the keyframes, but the translation still doesn’t seem to be exporting. Anything I need to be doublechecking or I can provide code snippets to assist in troubleshooting?

(D Kesserich) #128

If you can put your .dae somewhere I can take a look.

I did the DAE->FBX->Blender->DAE->FBX->Blender loop with the Kadeshi Fuel Pod after the code fix and the translations came through properly.

(Siber) #129

If the vay_ffion is what you’re using as a test case, feel free to pass your version of it along to DKesserich

(Sastrei) #130

Thanks, done. @Dkesserich I’ve sent a PM your way. Thanks for your help!

(D Kesserich) #131

Ah. Got it. Missed a dash for the interpolation source stuff. Weird that Blender was still able to process the animations correctly without it. I guess HODOR couldn’t. Fixed (hopefully. Can’t test properly without all the other ship files that I’m not going to ask for).

(Sastrei) #132

lol! I have tested it out with the updated files and it now exports all animations. :smiley:

Thanks a ton! :slight_smile:

Alrighty! @Dkesserich I think I found the reason for the size discrepancy, or rather @EatThePath did - here’s the Blender animation DAE output

	<source id="JNT[Array_Left]-translate.X-input">
		<float_array id="JNT[Array_Left]-translate.X-input-array" count="1111">

and here’s the 3DS Max animation DAE output:

<animation><source id="JNT[Array_Left]-translate.X-input"> <float_array id="JNT[Array_Left]-translate.X-input-array" count="2">

It would appear to be exporting data for all keyframes, rather than the just the keyframes that we’ve actually added.

(Siber) #133

To add to sastrei’s data, my belief of what’s happening is thus…

Open/close should only animate the array arms, codered/codegreen should animate the radiators and shutters, and drumspin should animate the drum. But if keyframes are being exported for all joins for all animations, when one animation is fired it’s keyframes on the joints it shouldn’t include override the keyframes for the animations that should be animating that joint, so only one animation at most can be played at a time.

(D Kesserich) #134

Yeah, I know the why of the file size difference, it’s one of about a dozen completely ridiculous things that the guy who wrote the original exporter did. I was just surprised by how extreme it can get. And I know more or less what I need to do to fix it, but it requires an almost from the ground up re-write of the animation section of the exporter, so will take me some time…

(Sastrei) #135

Oh. Darn. :frowning:

Thanks for the update @dkesserich! We shall keep soldiering on.

(D Kesserich) #136

I think I may have the animation stuff working better now, but I need somebody to test.

What it does now is for each action it only exports the frames between the first and last keyframe of the action into the DAE, where before it was exporting animation data for every single frame in the active frames (unfortunately, a function to get the list of keyframes in an action doesn’t seem to exist, so if you have an action that has a keyframe at frame 1 and the last keyframe at frame 1000, it’s still going to export 1000 frames of data). This should fix the overlapping animation data problem.

It’s also entirely possible that something will go horribly wrong, because when I do the Blender-> DAE -> FBX -> Blender process, the FBX conversion is for some inexplicable reason treating the animation like it’s at 1000fps. All the animations are there and functioning, they’re just spread out way more than they should be. Hopefully HODOR doesn’t have the same problem, but I can’t guarantee that it won’t.

If you want to try it, it’s pushed to GitHub.

UPDATE: I figured it out. In Collada the fps for animations is communicated by making the frame numbers in the animation input array float values, which are generated by dividing the current frame number by the desired fps. I was not doing this. Now I am, and the animations appear to coming in properly after the FBX loop. And much more importantly: HODOR is generating a MAD file, which it wasn’t before.

(Siber) #137

Just gave it a test with a recent blend from @Sastrei, and the animations are behaving as expected at last. Huge thank you to both of you for working on this, it’s a big help.

(Sastrei) #138

This is awesomely great news! I can’t thank you enough. I had gotten used to Max’s way of doing things, but after how easy it was to work on Siber’s IonArray ship for this test, I was loathe to return to Max. :smile:

(D Kesserich) #139

Awesome. Glad to know it’s working.

(Siber) #140

@DKesserich noticed something odd today… dock entry paths don’t seem to be getting created with tolerance properties on their nodes, like exit ones get. And at the same time, the dock paths I’ve tried to make don’t work, even if I add tolerance properties manually to their nodes.