[TOOL] DAEnerys - DAE Ship Editor


I came far today.
Edited much, much internal stuff to make the future easier for me.
The editor loads textures, UV-maps, all meshes and their multimaterials now!

I tested it with simple shading too, it displays the GLOW(selfillum) maps correctly.
You can show and hide meshes with the little checkboxes at the left.

And I duplicated the Homeworld ingame camera behaviour for the editor, you can now look at the model from all angles and stuff.

All meshes are at the zero-position right now, so I can’t show you any engine-meshes etc. yet.


Oooooh :smiley:

That’s seriously cool stuff, I was always thinking the same thing too ever since modding invented the idea of a stupid number of steps :smiley:

You definitely need to get this on GitHub I’d love to help if i have the time, as im sure everyone else does!

My idea:
Import Ship .OBJ to Ship Editor
Import Turret OBJ (Blender style right click to choose location).
Import Engine Thurst .OBJ

Or, select Meshes and mark as hardpoints.
IMO, 3D tools would be best used only for 3D. All Homeworld related stuff through the tool.

Ideally a Homeworld render button that uses similar shaders or exports, throws out a level script, then starts the game windowed with your ship…would be the best finaly out come :smiley:

1 Like

Now this i like :smiley:

cannot wait to use it!

1 Like

@PayDay, Did this ever get to GitHub or BitBucket? :smile:

1 Like

Oh dear, I changed from XNA to OpenTK/Mono again, but faced more and more problems.
I worked on that editor some months ago, because I have to do much for school right now.

Sorry for that, I think I will get into this again soon. Maybe uploading it to BitBucket then.


Hello guys, I’m finally back!

I learned and developed much since my last try on this, especially regarding OpenGL and 3D-rendering in general. Due to my current holidays, I decided to work on this tool again.
I spent the whole last days (and nights) creating an engine that is capable of the things needed for this. It runs on OpenTK (a low level .NET wrapper for OpenGL) with a Windows Form around it.

Currently it loads every .dae (at least I hope so), it’s meshes and linked textures and joints with positions and rotations (still buggy on some).
I will continue on the viewing and testing features, after that the editing and exporting will be implemented.

Now guys, I would like you to download the tool and load some of your ships with it. Report any problems/crashes here please.
Windows x86/x64

I have had some problems with the collada files exported by your addon.

In library_effects, there are missing alpha values for emission, diffuse and specular colors.
Furthermore the color parameter under the reflective node is missing sid=“reflective” aswell as an alpha value.

I implemented a little fix before importing the file using Assimp, but a fix for your exporter would be way better.
The files in the workshop examples contain these things, so it should not be a problem for HODOR at all.


My understanding of Homeworld:RM was that it didn’t actually use any of those values out of the DAE material, it just uses the initial texture reference to get the rest of the textures to drive those effects, with underlying colours for emission and spec being driven by the diffuse map.

Am I wrong?

1 Like

That’s true, but Assimp crashes without these values, and it would allow me to remove these ugly string manipulations.

Outstanding work!


This looks great! But you are right - it seems to open max-generated DAEs fine:

But it is struggling with blender-generated DAEs:

One thing I noticed was that it seems to keep getting the engine burn flames in the wrong place… They are actually correctly located behind the engine…


Thank you for testing :slight_smile:

It should load blender DAEs fine, I implemented a fix for that.
This looks like a missing texture, be sure that the texture is at the right place and correct in the .dae.
I will try to show a warning if it fails to load any texture next time.

About the engine flames, it does weird things with joints in the 3rd layer and below I think. Rotations of markers for example are messed up too, I still have to look into that problem.

1 Like

First and foremost, excellent work! If non-modelling work can be taken out of MAX that would make things so much easier for the less artistic/capable among us :stuck_out_tongue:

Here’s a DAE from MAX, the joints seem to be a bit weird. Would you like me to PM you the source file?

This ship was done in the currently available RODOH, the turret joint seems to be out a little bit here too (the joint is supposed to sit on the phaser strip)

And it didn’t seem to handle very large things yet :stuck_out_tongue:


The old version had an error in the rotation conversion.
I have to convert the 4x4 Matrix from the .DAE to translation, rotation and scale.
The rotation has to be converted from a quaternion to euler angles (Vector3).
For some reason the pitch and roll values had to be inversed, and the pitch valued negated. I fixed that last night.

About your large ship (beautiful ships btw.), this is just the draw distance of my renderer, so nothing to worry about there. I will add a slider in the settings window.
The renderer has serious performance issues though, I only get around 50FPS when I should really have something like 1000.

The recursive positions of some joints (like the EngineBurns) are still problematic, I am looking into that right now. Thank you, I don’t need your DAE yet. ^^

EDIT: Nodes that are children of rotated nodes should get translated, this is not implemented yet. Of course it’s not working. Working on that now.

They get parsed and displayed as a polygonal 3D line for now.
I need some help with the enumerations for dockpath and segment flags:
public enum DockpathFlags { EXIT = 1, LATCH = 2, ANIM = 3, AJAR = 4, }

public enum DockSegmentFlags { USEROT = 1, PLAYER = 2, QUEUE = 3, CLOSE = 4, CLEARRES = 5, CHECK = 6, UNFOCUS = 7, }
Did I miss some of them?
And if yes, what are their exact names?


There is another “DockSegmentFlags” entry called “clip”.

Did you update the download?

1 Like

Not yet, I will release a new version tomorrow. I added many features and fixed many bugs.

Thanks for that flag, I am working on parsing mesh metadata right now. There are ‘Tags’ on them, is there any other than “DoScar”?

1 Like

It sounds like you might be sending the vertex/index/etc data to the GL pipeline every time the render() call is made. If so, create a VBO/IBO and send the buffered info to the GL pipeline once, when the vertices/indicies are read/calculated/whatever else, and then you can “forget” about it. The only changes that then need to be called in the render() method is updated camera/light positions, and various other positional data.*

*I say all this with the knowledge that I might be completely off-base. It has been a “minute” since I last touched OGL rendering…

Some other points:

  • 50 FPS isn’t that bad (it’s technically all about frame time, or how long it takes to render a single frame [see this article]). What is your monitor refresh rate? Anything above that, and you start to skip rendered scenes.
  • Having not actually looked at your render code, I can only offer pointers, but make sure that everything in that render call is 100% necessary for rendering. The only example that currently comes to mind on things to look for:
  • Are you calling an update to the matrix for the camera in the render code, or is that being done as soon as the camera is updated?

Hope some of this helps…

1 Like

another thing is to tighten the inner loop of the rendering code so that things like setting up buffers and rendering modes are done as far outside of the loop as possible and iterating through meshes and verts/indexs is done with as little extra code as necessary, you may even want to group by rendermodes so that those can be iterated too.


I am doing that in my Update callback, the editor is event-based and not in a loop (due to the Form around it). I am now rewriting the renderer to only update the mesh data when it’s actually changed. Thanks for pointing that out.

60Hz, even without V-Sync, the framerate is horribly low.[quote=“radar3301, post:41, topic:540034”]
Are you calling an update to the matrix for the camera in the render code, or is that being done as soon as the camera is updated?

Another thing to optimize, I’ll fix that. :slight_smile:
Let’s see how much these optimizations help, especially sending the buffered data only if needed.

Good point, I’ll do that when updating the renderer to be able to use several shaders, thanks.


Okay, so here is the new version: Windows x86/x64

Added features

  • All editor visuals now get drawn in front of the ship.
  • Dockpaths now have their own tab with all of their information conveniently displayed.
  • Dockpaths are visualized by a 3d line showing their path and little spheres at the segment points.
  • Markers now have their own tab with a list of them and a checkbox to render them.
  • Added marker size slider.
  • Added clip distance slider.
  • Many internal things.


  • Much better performance (Thanks to @radar3301 and @EvilleJedi).
  • Transformations of nodes fixed, so all joints and other things should be correctly rotated and placed now.
  • Many little things.

Known bugs

  • Some mesh names don’t get loaded correctly.
  • The mouse sometimes goes to a random position after releasing the right mouse button.
  • There is some weird flickering on some meshes (with multiple materials applied to them I think) after I reworked the renderer. All homeworld meshes from the workshop examples I tested work.

Planned features

  • I thought of some 2D icons for displaying navlights and all the other stuff that homeworld ships have. Like these from Unity: image
  • Real-time previews of how dockpaths (and maybe other things) are going to look like in game.
  • Tolerance display of dockpath segments.
  • Lighting shader for navlight previews.
  • Better data display for all the other joints.
  • Troubleshooting help by showing you problems with your DAE. (And fixing them) Like @Xercodo suggested a while ago.
  • Bounding box calculations, in order to scale zoom speed etc. automatically.
  • Editing and exporting of ships.

Note: You won’t be able to see your navlights, engine burns and some other things for now. Because only joints (nodes starting with “JNT”) get displayed in the joints tab. They still get loaded internally though.

So once again, test your ships with this, give me feedback and let me know of your ideas.


Edit: Derp, I found zoom speed

  • I got a crash when trying to load a Nyx, looks like a zero length substring:

    ************** Exception Text **************
    System.ArgumentOutOfRangeException: Length cannot be less than zero.
    Parameter name: length
    at System.String.Substring(Int32 startIndex, Int32 length)
    at Homeworld_Editor.HWNode…ctor(Node node, HWNode parent) in D:\HomeworldEditor\Homeworld Editor\collada\HWNode.cs:line 69
    at Homeworld_Editor.HWNode…ctor(Node node, HWNode parent) in D:\HomeworldEditor\Homeworld Editor\collada\HWNode.cs:line 157
    at Homeworld_Editor.HWNode…ctor(Node node, HWNode parent) in D:\HomeworldEditor\Homeworld Editor\collada\HWNode.cs:line 157
    at Homeworld_Editor.HWNode…ctor(Node node, HWNode parent) in D:\HomeworldEditor\Homeworld Editor\collada\HWNode.cs:line 157
    at Homeworld_Editor.HWScene.LoadCollada(String path) in D:\HomeworldEditor\Homeworld Editor\collada\HWScene.cs:line 59
    at Homeworld_Editor.Main.buttonOpen_Click(Object sender, EventArgs e) in D:\HomeworldEditor\Homeworld Editor\Main.cs:line 115
    at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
    at System.Windows.Forms.ToolStripButton.OnClick(EventArgs e)
    at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
    at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
    at System.Windows.Forms.ToolStripItem.FireEventInteractive(EventArgs e, ToolStripItemEventType met)
    at System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met)
    at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
    at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
    at System.Windows.Forms.Control.WndProc(Message& m)
    at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
    at System.Windows.Forms.ToolStrip.WndProc(Message& m)
    at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
    at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
    at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

1 Like