Let me know if I can help in any way…
I think I got it. Updated script pushed to GitHub.
Problem was the library_visual_scenes was pulling matrix_local (which is a 16 item array that has all the transformation data (location, rotation, and I’m not entirely sure what else) and was dumping that into one long string in the xml. Changed it to just pull the XYZ location (rotations don’t seem to matter since the orientations for all the hardpoints are set by the child empties) and it looks like it’s working okay now.
Questions for BitVenom or anyone else who might know: What’s the deal with the animations? When opening the FBX in Blender, every single object has an action on it named “[ObjectNameHere]|Take 001|Base Layer.002” Are these necessary for the ship to work, or is this something that 3DS Max just does for no reason?
Also: what are the absolute minimum requirements for a ship to work? I tried throwing together a quick crappy tapered cube and add all the engine trail stuff empties, a basic material with no textures (also no actions), exported the DAE and HODOR took it just fine (hooray), but when I tried it in game I got an Access Violation error when loading in to the match. Does it need at least one diffuse texture and one team texture (even if Team is totally blank like for the Kad Swarmer)?
Trying to figure all this out to make an actual Homeworld Ship Building in Blender guide (also trying to figure out if Blender’s cartesian Z-Up coordinate system causes any weirdness when building a ship from scratch).
Textures aren’t needing. I put a model in based from the p1mothership. I removed all but one repair/capture and totally remove salvage (purely because there was no need for them). Removed all the left/right etc. bits but ended up adding them back in manually before realising their importance in .events and how lucky i was with the number of my new ones
This was 3ds Max - no material, no textures. Collision model is not needed either. Again, salvage was not included.
I hadn’t looked at the .events file. That refers to animations, so I guess that’s what all the actions are for. Maybe threw the access violation because it was trying to get info from the HOD that just wasn’t there.
Probably be worth making a ‘Generate Animations’ script that’ll automatically add all of them.
Possibly but they are optional. It is used by events for things like smoke and fire when health is low. The number of them and having them as far as i understand is not needed - pretty sure not all ships have .events too. Simple pop up to choose left/right/front/back for a joint is all that would be needed. You’re probably right that’s where the crash came from; also make sure the .ship file doesn’t look for any utilities (repair etc.) that you don’t have.
Typical behavior when stuff in the events file doesn’t have a matching joint in the hod is it’ll just spawn the effect at the root.
Missing hardpoints in the .ship file WILL cause a crash though.
Well, I can’t figure it out. I’ve manually created an exact duplicate of the Swarmer rig for my silly test ship mesh. Every joint with exactly the same name, with exactly the same hierarchy. I even put in all the animations and set up the materials.
Export the DAE, HODOR makes the hod no problem, I swap it into the kus_scout, same way I did for testing the swarmer.
Start up mp beta with the -overridebigfile flag, and I get the access violation error when I try to start a match.
PM it to me, I’ll check right now.
Skype complete! I think the (relatively minor) issue now found means there will be some degree of Blender->DAE for ‘new’ ships in the very near future. I still need to roll out an update to HODOR for a few things - but some really great progress is being made.
Yup! Got it working on my end. There are a couple of additional ‘gotchas’ that come out of Blender’s Z-up, -Y-forward coordinate system that weren’t apparent when exporting the example ships (because when you import an FBX that’s on a Y-up system, even though everything displays like it’s now Z-up, the local coordinates are still Y-up. And there’s no option in Blender to change coordinate systems), but it just amounts to “once you’re done making your model and adding all the joints, turn the whole thing on its end, and then rotate the joints back the other way” which is a little counter-intuitive, but hopefully not a deal breaker for anyone.
Maybe I can detect Blender DAEs and auto-correct for that (the bad coord system) ?
Good news: I’ve successfully round-tripped the Taiidan Interceptor sample ship! The FBX conversion removed the Badge UVs, but re-adding them only took a second, and the Badges displayed properly in-game (except for one face that I had sideways in the UVs without realizing). The wing animations also all worked correctly (thank god. I really didn’t want to have to re-write the animations part of the exporter).
I’ve also figured out the coord system thing, sort of. It’s not that Blender was keeping the FBX coordinate system when it came in, it’s that the ROOTs were all rotated 90 degrees on X and 180 on Z, and all the children were on local coordinates and I hadn’t realized. The reason I thought the joints had to be rotated the other way after turning the whole thing on its end was because I had them rotated wrong in the first place. It also means that fixing it in the exporter is not something I think I can do. I thought I might be able to just swap the Y and Z coordinates, but I think there might be more math involved in the whole thing.
I’ve been trying to wrap my head around the “Z is up” thing in Blender too, it’s a bit deceptive because every OBJ from the HW2C mod I import is aligned correctly to Blender’s Z-up orientation…
Then I found these options:
Those are simple enough, and the same options are there for the FBX importer, but what should the “bone” orientations be? My understanding is that these are what make up the joints
The bone stuff is only if you guys are using animation bones for joints. If you’re using empties, you should be able to ignore the bone stuff.
Would it be possible for you to release .blend file versions of example ships? Assuming that’s okay with gearbox of course.
The DAE->FBX->Blender has all the joints come in as Empties, so bone orientation doesn’t matter. The reason everything appears aligned correctly is because Blender automatically rotates the ROOT empties (which all the other objects are children of) when you import (depending on the orientation settings in the importer). If you select all and then clear rotation (alt+r), everything will be pointed up, with the top of the ship oriented to positive Y, and the front to positive Z.
@EatThePath: It’s easy enough to do the conversion, but I’d definitely need an OK from GBX. And I assume they’d have to go on to the Steam Workshop.
Once the Blender versions of the Examples are all working and stable (and that is probably not until another HODOR update to handle long name) - I will happily add them to our Workshop Examples so that everyone gets them as an update, with credit given as relevant.
One of our team made the observation that you don’t need to be a current student to get a student license for 3DsMax. This might solve some issues