[TOOL] DAEnerys - DAE Ship Editor

Hello guys,

In this thread, I want to show you my progress on developing an app that will be able to load .DAE files and export them after editing them.
You can do all of this in 3dsMax or Blender, sure. But I want to make the editing for Homeworld much easier.
A bit like CFHodEd, just using HODOR and not reading .hod files.

At the moment the program only loads one .dae that has to be changed in the code, I still need to implement the file browser.

It loads all the joints and displays the main mesh.

I started with Mono first, I wrote my own importer. But then I ran into a problem with the indices when the mesh had more than one material on it. So I ended up using a importer library for XNA.

I will post updates when I’m progressing.


LATEST BUILD: DAEnerys_b7529.zip


Awesome! I’d encourage you to put the source up on github, bitbucket, or a similar service and give it an open source license, people might be inclined to pitch in or offer pointers. I’ve personally wanted to do a similar thing at several times in the last six months, but I’ve only so much spare productivity to go around.


I will see if I can do that, but the code is a mess right now. ^^
By the way, I don’t have that much knowledge of XNA, so I will probably get into more trouble with rendering and stuff. I did a lot in C# though.

1 Like

OMG YES. This was exactly the sorta thing I had in mind, if we can share code I’d love to integrate this into HODOREST or vice-versa. The parsing of the XML data was weird for me because I essential needed to know exactly what tags to expects form the dae format and that was a bit much for me to figure out.

From the looks of things here you used XNA’s “designed for games” pedigree to read the daes for you. They are a fairly standard game model format anyway.

What I wanna be able to do is let you do a sanity check on your daes using something like this for all the materials tags, the joint names, etc as well as a quick check that your texture files are in the same folder that HODOR expects them to be in. I can probably handle the UI work you’ll need from that standpoint.

Ideally though, instead of editing the daes in your program we should highlight problems and make finding them easier so that we can go back into our preferred modeling program to make the changes at the source, otherwise you’re gonna have to edit the dae every time you make an edit to the source model and re-export it.


@Xercodo Yeah, I know what you are talking about. I could not figure out all of this vertex-triangle-indice stuff.

I am using an XNA-based library that basically gets all the information out of the .dae and puts them into classes that I can access easier. A lot of the parsing is still manual though.
I actually used HODOREST a while, but then it started to crash my HODOR.

The sanity check is a good idea, but after that I would like to implement actual editing stuff to it.
My current task however is to read all of the data correctly and put them into the different categories. (Just like CFHodEd did)


Hey, my code is messy as hell but it’s still out there to see. I haven’t publicly linked it, but it IS out there >.>

If it came to remodeling after using a tool like this, I’d reimport the modified DAE. A sanity checker would be great too, of course.


Heh my problem with that is that Blender doesnt have a dae importer that has been retooled to work with the HW version of the dae

1 Like

yeah, unfortunately it doesn’t. You can walk it through another format and it doesn’t seem to lose any data, but that’s obviously not ideal. Still, it’s what I’d do in this case.

I thought about an .obj importer, just like CFHodEd.
The .obj format is very easy and is perfect for only-mesh imports.

1 Like

I’ve found that 99% of thew time that problem is the dae used, not HODOREST because all it’s really doing is generating the .hodor script and calling hodor for you.

One thing you can do to check if it really is HODOREST is to try running HODOR itself from command line as intended and seeing if it still crashes. If it does work in HODOR stand-alone but not HODOREST then we can try to figure out what’s causing it so I can put out a new version. :wink:


The problem is taking the dae you’ve edited in your program and putting it back into blender. A bit counter intuitive to be losing data exporting it to obj for blender to read. heh

Once it;s in a dae format I’d like to keep it in dae and for everything to be synched.


@Xercodo The workflow would be:

  1. Creating your mesh in Blender or any other modeling software.
  2. Exporting it as an .obj file.
  3. Importing the .obj file into the DAE Editor.
  4. Adding all the joints and stuff.
  5. Exporting it as a .DAE.


  1. Creating your DAE in Blender or 3dsMax.
  2. Exporting it as an .DAE file.
  3. Importing the .DAE file into the DAE Editor.
  4. Adding and editing joints and stuff.
  5. Exporting it as a .DAE.
  6. Importing an .obj file into the DAE Editor to overwrite meshes in the .DAE file.

Maybe an .obj exporter too, but this is not really necessary, can be done in about 1 hour though.


an obj exporter that exports a whole ‘frozen’ mesh, with all the turret meshes and such in the places they’d appear in game but all as one object, is something I’ve wished for for quite a while. It’d make certain things, like p3ding old ships, considerably simpler. Of course I could probably do this in blender now with Rodoh’d ships, but removing steps is always nice.

1 Like

DAE to FBX to Blender works well.

1 Like

Yeah and my problem is that neither of those are ideal xD

Let me put it this way, as someone that is doing all of the edits to both geometry and joint data in one place I’d like to keep it that way. However, there can certainly be a case for people doing stuff similar to kitbashes and doing little changes here and there, especially to the examples from GBX, so for that allowing them to edit a dae still a valid scenario.

I don’t wanna look like I’m forcing my workflow on people here, but I’d prioritize the “sanity check” feature. It’ll apply to everyone anyway :smiley: Being able to import other standard formats though does sound awesome for anyone wanting to instrument a ship they made or acquired from some other modeling program that didn’t have a compatible dae exporter.

1 Like

THAT would be excellent! Your 2nd workflow idea is perfect.


True, but let’s be honest, editing some things like dockpaths in 3dsMax or Blender is a pain.
I want features like realtime marine frigate previews for capturing, preview of dockpaths with a moving model, stuff like that.

But all of this is still far away, the most important thing for now is importing all data correctly.


Even better, we could integrate WeaponEd with it and give a visual representation of weapon view arcs and attempt to animate the turrets to preview that too.

We could import mesh-only models to use as “placeholders” to visualize docking paths. Just check a box of which one you wanna see and it’ll attach itself with correct rotation to each dock path point.

Now we’re gettin somewhere.


@Xercodo Exactly my thoughts. I have to sleep now though, good night!

This just keeps getting better and better. With a tool like this we could edit ships almost like we used to with HodEd. This is a killer idea guys.

1 Like