Blender DAE Exporter for HWRM

(D Kesserich) #61

Flags on the Roots shouldn’t be necessary. Y-UP or Z-UP are in the header data of the DAE, Hodor would just have to go 'Oh, this Z-Up? Rotate everything this way"

We’d probably have to undo the rotation stuff that we’re already doing for all the joints, though.

Also: I just committed an initial Navlight converter tool. I haven’t tweaked the exporter to convert the properties into the IDs yet, but the in-Blender workflow is fairly simple, I think.

(Dragon93) #62

Great work mate! We’re getting there :smiley:
Just saw you got animation export working too! Very nice :stuck_out_tongue:

(D Kesserich) #63

Anyone know what the phase parameter for navlights actually does?

I know Frequency is how many times per second it blinks, and I thought Phase was controlling how quickly the light fades out after it turns on, but it looked the same to me whether I set it to 0 or 10.

(BitVenom) #64

Phase controls the time offset for a light - so a series of lights can be coordinated. The actual style of a light’s blink (how long off/on) is part of the style definition file itself…

(D Kesserich) #65

Ah. Got it.

Threw together a quick video for the Navlights tools:

(Eville Jedi) #66

for Navs is DIST used when the SPRITE flag is set? It looks like nav lights with SPRITE flag do not cast light. is there any issue with having the parameter?

(D Kesserich) #67

It definitely casts light when Sprite is set. The world light can tend to overwhelm the effect of the navlight.

Also, not having a normal or spec map, and a pretty flat texture makes it harder to see the effect of the lighting in-game.

(D Kesserich) #68

Quick note to any Blender users trying to look at the example ships using the DAE->FBX->Blender process: I strongly recommend upgrading to Blender 2.74. The FBX importer has been dramatically improved, so the only thing that has to be done is re-naming the textures in the material, instead of basically re-building the material completely.

(Siber) #69

Thanks for the heads up!

(D Kesserich) #70

Updated the toolkit and created a quick video tutorial for making Docking Paths in Blender:

(Xercodo) #71

@DKesserich Halp. I cant seem to replicate the super simple export.

I tried taking the default cube, “shipifying” it, and adding an engine to it (like the example that came with the toolkit) and the dae exporter keeps crashing looking for the word “phase”.

I can’t tell what’s different from the sample D:

what the… it works when I delete the lamp…the hell?

Okay so still, it ignores my engines placements and the trails are coming from the center of the ship. I tried to keep it simple and only use one engine and it’s not using it.

Can confirm that even the demo ship is ignoring engine placement. Is there something else I need to do with the .ship file or something? Cause this is freaking me out.

(D Kesserich) #72

The lamp thing is because the exporter converts lamps to Navlights, but if you haven’t actually done the ‘Convert to Navlight’ on a lamp, it won’t have the custom properties. I should probably put in some more robust checking on that.

I’m not sure what’s going on with your engine trail. Did you rotate your Root so that everything is pointing up in Blender and then apply the rotation? The demo ship worked fine for me after doing that. I actually have an idea to eliminate the necessity of that step, but now that I’m working again I don’t have a lot of time to dedicate to this.

(Xercodo) #73

Well the thing is all the rotations seem to apply right off the bat. I don’t see any pending modifications like your first video implied.

I’ll see what I can do in that regard, I’ll try not rotating them, but they are def coming out of the very center of the ship and aren’t offset like I would have expected them to do if the rotation wasnt applying.

However, they do initially spawn HUGE in relation to the ship so maybe my scaling them down ruined it? They looked normal on the model when all as said and done and I made sure to do “Select Hierarchy” so that I grabbed all the flame divs too so they it was all to scale both in size and relation-ally.

(D Kesserich) #74

It sounds like you’re not applying any of your transforms. If you select an object (specifically your ROOT_LOD[0] node) and the Rotation and Scale numbers in the properties panel (the one on the right side of the 3D view, opened and closed by pressing ‘n’) are anything other than 0 and 1, respectively, you haven’t applied your transforms.

Before you export the .dae, in Object mode press A to select all your objects, then ctrl+A and select “Rotation & Scale.”

(Xercodo) #75

OH that might be what I was missing. Will keep ya posted…


YUP, IT WORKED. Though the ship was a LOT smaller ingame than I imagined. I just had to scale it by 10x to make it as big as I expected. If I do all of my ships by the same scale I should be golden.

Also a point I think would be worth making is that if anyone works with their textures in GIMP Do NOT use the RLE compression option when exporting to .tga. UNCHECK IT. Or the game will render weird stuff. I suspect this is the reason why HODOR has been rejecting textured models I gave it.

I’ll triple check the materials tags and make sure that compression isn’t on for the tga and I might actually get some thing cool in-game.

Oh side note. I’ve been noticing that my ships don’t hyperspace correctly, the whole model shows up regardless of the animation progress. I have a feeling this is related to my lack of textures since that probably effects how shaders render the hyperspace effect.

Either way BIG thanks


YUP I fixed it, I was missing IMG[ship_name_DIFF]_FMT[DXT1] on the texture itself.

(D Kesserich) #76

And I’ve finally made the Capital Ship Engines and Turrets tutorial:

(The sound goes kind of bad at ~27 minutes in because my good microphone’s battery died mid-recording.)

Thus endeth Shipbuilding in Blender 101.

Advanced Shipbuilding in Blender to come at some point in the future, probably. Covering such topics as: Animations, Subsystems, .ship file creation(?) and other stuff probably. And maybe a ‘Map Backgrounds in Blender’ one-off at some point in the future.

(D Kesserich) #77

Hotfix release that removes that confusing second name field in the wepons panel and (probably much more importantly) automatically triangulates the meshes when exporting is here:

(D Kesserich) #78

@Xercodo had a neat idea to change the dock seg nodes from Plain Axes to Sphere display, and use the draw size as the Tolerance value, so I went ahead and implemented it.

Here’s a visual:

This way we have an in-Blender visual representation of the sphere of influence for Tol. I haven’t created a release for it since it’s so minor, but if you just download the it should work.

I’m also working on removing the requirement for doing the “Rotate -90 on X before export” step. It’s kind of working now, but it’s had some knock-on effects where I have to do world to local space conversion on the 3D cursor location in order to keep the hardpoints from being created in unexpected places, and fixing that is just kind of tedious.

(Siber) #79

Awesome! I am very grateful that you’re still improving this. Two thoughts!

One of the very nice things about HodEd4 is drawing a line between the successive points in visible dockpaths, helps to visualize relative motions. Is there any chance of that happening here?

The second is more curiosity than request, are there any obvious technical hurdles keeping a better collada import from happening? I understand it might be a very low priority item, since there are tools that do conversion into things that blender will import properly, but I’m curious about the behind the scenes here. Are the problems with the importer unknown, known and significant, or known and relatively trivial but still more effort than it’s worth?

(D Kesserich) #80

I wish I could figure out a way to draw directional lines between the seg nodes to visualize the path. The only thing I can think of is parenting them in sequence, but then they’d have to be re-parented so they’re all only children of the original dock node at export. Maybe something with a curve or a nurbs path and hooks? The most immediate issue I can think of with that approach is making sure that the curve/path has the same number of verts/control points as there are seg nodes, and then being able to dynamically adjust that number is another problem.

Making a new importer is technically feasible, it’s just outside my current skillset. The exporter was just me retrofitting somebody else’s exporter, and they’d already done the majority of the heavy lifting on it. I just had to fix up how they were doing the tagging and the coordinate systems and a little bit of how the materials were structured. I’d be working from scratch for an importer, and I kind of don’t know anything about doing xml deserialization. Every time I’ve looked into it I just can’t wrap my brain around it. If I could find the time to get over that hurdle the import should be cake, since DAE is actually a pretty easily readable format.