Salvaging old HODs for re-HODOR-fication with UU3D

G’day all!

I’ve been bugging the developer of Ultimate Unwrap 3D to improve their HOD importer so that it can read HODs created for the old HW2, he has come to the party and done two updates to his HOD plugin this week! I don’t know if he’s put the latest HOD plugin up on the website yet but I have in my possession the power to get meshes, joints, NavLights and materials out of a HOD!

Because I don’t understand how the DAEs are actually done I don’t know what the next steps are to getting it into a condition where it can just be exported again ready for HODOR to chew on, there are several things which the HOD importer doesn’t do which I am concentrating on bugging the developer about first (Goblins don’t have UVs, no thruster related items/info are extracted, markers are not extracted, dockpaths are not extracted).

But yes, there you have it, the closest thing to a HOD -> DAE tool out there! This sort of thing will be vitally important for people like me where the whole modelling process is a black box and we just dealt with CFHodEd’s friendly GUI. Eventually I am hoping to see it import an old HW2 mod HOD and export a HODOR-ready DAE.

Cue enthusiasm to incentivise the developer :smile:

2 Likes

Well, lucky for you that a HOD->DAE is coming in the very, very near future - no hacks required. This will be super handy when HOD format changes and old, hacked tools don’t work - I can point at HODOR and say ‘hey, go use that!’ - and people won’t make faces about it.

It will not open new HODs, nor the ‘new’ HOD formats to come - just the older ones. But that’s what we’re trying to help with: Old Mods with tons of HODs that want to switch to the supported toolchain. Along with improving/evolving Blender support I think there’s a ton for people making ships to love.

4 Likes

I would be happy with getting the hardpoint/navlight rigging out of a hod, I really don’t want to have to rerig a super star destroyer (280 weapon points)

1 Like

Yup - it gets all of the old data out, and generally will re-organize the materials into the new layouts too. Plenty of manual work remains (badge cut-outs, creating NORM/PAIN/etc) - but it will be a huge jump-start.

Again, won’t help people hack at existing ‘new’ HODs - so don’t do it.

But all sorts of old HODs will go over to DAE super-fast.

I’m also going to try to get people set up with a GUI or batching script - so that when a new HODOR is released with any additional features or format changes, it’ll be a single-click to update your entire Mod’s content to the new version and keep pace. Other changes (like the work to make Locale and ‘skins’ safe for mix & match) will also eventually happen that should leave Mods in a much better and more flexible state than before.

5 Likes

So @BitVenom, will the DAE files converted from old HODs by the official tool be ready for HODOR without being touched in Max or Blender? Will the only work beyond the conversion be setting up the new texture files? Even our team members who use Max for modelling have expressed a bit of distress with the prospect of working with the joints and all that in Max instead of an easy to understand visual editor like CFHodEd.

So if our workflow can be OBJ -> CFHodEd -> old HOD -> DAE -> HODOR -> new HOD then we have a way of getting back into the game as the DAE files will only need to be done once, right? HODOR can then be run over the source files to make new HODs every time you guys update that :smile:

If we have badges set up in the old HODs will they come across too?

It sounds like your team would prefer to go out of their way doing the most difficult thing? I don’t even know where to start…

Have you thought through what you’re asking? I mean, like - step-by-step it out? I mean, if I really have to I can lay it out in a big table of reasons that approach is a god-awful idea. I really don’t want to burn time talking people down off of rooftops or begging them to stop aiming guns at their own ankles.

That or this is just trolling?

  • The HOD->DAE tool won’t invent/create new textures.
  • No HOD->DAE won’t magically fix UVs.
  • No HOD->DAE won’t let you work with expanded shader and material properties.
  • No HOD->DAE won’t understand ‘current’ HOD features - it works on old HODs (10 year old format HODs).
  • As new features are added to DAE (yes, there will be) - they don’t have an analog in the old HOD format. So you have to add/edit them at the DAE level.

Anyone claiming to prefer CfHODEd over Max or Blender for joint/transforms editing is being rather disingenuous - or is terrible with Max. People are entitled to their preferences, absolutely - but we support DAE->HODOR. The pipeline from ‘art’ to DAE so far is Max or Blender. Instead of spending time patching an old tool for an old format to half-understand the new stuff (which is a moving target, I can’t even begin to understand why that seems sane) - maybe contribute to the Max/Blender tools being made? Those are great - they work in the right place (at the source data level) - and will only get better.

The tool will help move OLD files to DAE. My VERY sincere suggestion at that point is this:

  • Import the DAEs into Max/Blender.
    – These new files become your baseline.
    – Make all edits on these files only. The process to <-> from other tools isn’t lossless.
  • Determine what features you lack from Old->New (Pathing flags, non-linear animation keys, scar/material properties, additonal material channels, etc - it’ll be a growing list).
    – Make those adjustments in your new baseline files.

Think about it a moment - if I add new features to the engine - who adds them to the old HOD format you want to use? And forget ‘who’ - the better question is why? If you can interact with new features in your baseline format and get them into the game with supported tools. Here’s my ‘timeline’ of edits in the universe your team has apparently suggested they’d prefer:

  • Create/Have have Old HODs (wrong format, layout, etc)
    – Make OBJ re-import edits.
    – Make Texture re-import edits.
    – Hand-tweak joints of various types (markers, weapons, etc)
  • Save old HOD.
  • UNHOD (probably won’t be HODOR itself) to DAE
    – Breaks out DDS files to HODOR ready TGAs
    – Breaks out meshes into DAE multi-material ID objects (minus smoothing groups, etc)
    – Re-creates animation channels as linear, when possible.
    – ONLY understands old HOD. Zero new features.
  • Your team has to rebuild Badge objects.
  • Your team has to edit in new info about scar masking, add new collision prims by hand.
  • Your team has to manually add any other ‘new’ features (dock path flags, expanded nav light flags, etc)
  • Your team has to make the other new TGAs that the old format didn’t understand.
  • Post edits export DAE
  • Convert to final HOD
  • EVERY time you want to edit your ‘old HOD’?

Just to repeat - every time you edit a file, you want to re-import your edits to the ‘old’ stuff to buggy/hacked UI (and at the internals level CfHODEd in particular was a mess of bad geo processing code), maybe do some joint/transform edits there - and then dump an ‘old’ HOD - then ‘UnHOD’ it (so now we’re compressed/decompressed the images twice, shifted around verts, lost all concept of defined smoothing groups, etc)

-OR-

Do the stuff above Once - into a DAE (or similar app format that has easy export to DAE). Then, as we add flags, features, new ‘stuff’ - just edit the base file - and re-export as needed.

  • All of your ‘unbaked’ data is fine
  • Smoothing groups, complex surfaces (that become mesh at export)
  • Alignment helpers & widgets for editing weapons (maybe with proxy mesh objects in the scene so you can see what you’re doing, etc)
  • Extra processing flags and hinting objects, etc.

I really encourage people that understand where I am coming from and why I harp on a ‘correct’ processing pipeline for art to speak up here about where the other approach fails/sucks/hurts. Because I don’t think I should be the only one blowing smoke out of my ears that this thinking is bad; that these processes are just wasteful. I’m so on board with helping people make stuff - you have no idea. But I’m not going to do that in this ‘but but but my old tools sad face’ context.

Hi BitVenom,

I understand that there’s not going to be any way to avoid Max or Blender in the long run, and we have people trying to figure out just how to do all that too (a complete dunce’s guide to rigging a mesh from scratch for HODOR in Blender or Max would be paid for, everyone take note~~). My immediate concern is getting set up and started

My idea for the old HOD to new HOD workflow was (slightly) less presumptuous about what would be automated than you were fearing, it went like this:

Create/Have have Old HODs (wrong format, layout, etc)
– We’re unlikely to need to make any new HODs before we understand the “correct” process
UNHOD (probably won’t be HODOR itself) to DAE
– No textures expected from old HOD, only materials so we don’t have to set them up in Max/Blender
– Breaks out meshes into DAE multi-material ID objects (minus smoothing groups, etc)
– Re-creates animation channels as linear, when possible. (Hopefully can recycle MAD files too?)
– ONLY understands old HOD. Zero new features. Will do without new features until they’re understood by the team
No understanding of Badge objects, will have to do for badged ships later when understood
No understanding of scar masking, or collision prims, will have to do for all ships later when understood
Any other ‘new’ features (dock path flags, expanded nav light flags, etc) will have to come later when understood
Not sure about smoothing groups, will have to do for all ships later when understood
New TGA textures will be created from original DDS diffuse, glow and normal maps (this doesn’t involve Max/Blender, so we’re fine here)
If any edits are done, they are exported from Max/Blender
Convert to final HOD

The new DAE files which result from the transition will be our new baseline, yes, as we learn how to use the peripheral features of Max/Blender that deal with all the joints/nodes/etc then we can worry about more than just feature parity across in the new engine. We won’t be revisiting our old HODs and would only use CFHodEd as a stopgap in the interim to get a new baseline for a ship before we’re capable of just doing it straight up in Max/Blender.

I’m sure you appreciate that we’re all just hobbyists here though, and Max and Blender are {appropriate expletive} HARD, even for the initiated. You must have an incredible amount of patience to deal with people like me who happily ignored Max and Blender the whole way through setting up their various HW2C mods and now need these most likely basic thing explained to them :smile:

As for “harping on” about the correct process… I completely get where you’re coming from, really, and I’ve been trying to find an on-road to the official toolset for weeks for people who don’t have all the skills to do it the proper way. Getting these baseline DAEs going so we can have the most basic of new HODs in STC just to start off is going to be a huge achievement for us. The frills will be the next thing we worry about though… :confused:

I think what I took/take issue with is the suggestion that anyone would work on Old HOD files and just repeat process UNHOD->DAE->HODOR; instead of UNHOD->DAE once, then building on that baseline with edits and refinements before using HODOR as a final build step as required.

I understand that you have a mountain of files to convert - and that shouldn’t be difficult to batch UNHOD once to DAE. Ditto for DAE->HODOR - you can very easily set up a script that just does it in a single shot. That leaves editing DAE files in the middle - which is really not that hard. Many of your smaller edits can be done to them directly (moving points, etc) - or you could take the plunge and batch convert them to FBX for Blender. There seem to be tools for Max/Blender coming up that help with things like placing new weapons and so on.

Yeah, we’re only going to have the most basic DAEs/HODs for a while… once the ship is actually in the DAE format though we shouldn’t need to go back to the original HODs to change it, especially if it’s a mesh change. And if there’s something in Max/Blender that just is impossible to do we can put a question up on the forum here as there’s obviously people who do understand it here

The worst of it is just learning Max or Blender, I used Milkshape to cut out thrusters and manage materials for STC. Occasionally also did doors and hanger bays. Super simple stuff. I didn’t even know you could do joints and markers and the rest in a mesh before having that brought into a HOD

Thanks for your continued support and patience, more questions will no doubt be coming in the future :stuck_out_tongue:

I feel like the majority of ‘unknown’ actions in Max/Blender can boil down at some level to asking various people here and on other forums for tools or scripts. The task somebody on your team has to tackle X is going to be one another team will also have - so tools to support that work will be relevant across projects. I may be able to help in Max (zero Blender experience) - but most likely it’ll be others.

I’ve used MAX for years but only to do the basic modeling. I’ve never had a reason to do bones, joints, etc, for modding HW. The plugins for Max that are up don’t work correctly for 2015 (it’s a legal copy). At least I can’t get them to actually do what they’re supposed to do, so yes, consider me a dummy. I don’t mind asking questions and asking for help but when the process is over your head from the get go and a few people actually know what they’re doing, it’s a little intimidating when people don’t actually want to help you. They just want you to go a way because you’re stupid. That’s been my take on the new game and community so far.

The problem isn’t so much the tools but the basics of understanding and using them. If there’s a compatibility issue then we never really know but just assume we don’t know what we’re doing. I’m sure there’s a lot of casual modders out there that don’t understand the basics and are afraid to ask.

The same thing happened with HWll when it came out. The requirements and the learning curve stifled many people. Eventually tools and resources came along that propped up the community but now there’s a difference. There are people who understand beyond the basics and have their own click or group and it’s not easy to breach that wall.

I looked for the FBX plugin upgrade for Max 2010 and was given links that didn’t go anywhere relevant. When I finally found it I discovered it doesn’t work for 2010 to upgrade to 2014. I asked questions but received no relevant help. My problem now is understanding nodes and joints. I can figure this out eventually but it would be a big help if I knew whether or not the joint/node plugins people made for Max actually are supported in 2015. If not then I’m not as big a dummy as I thought. If they do then I’m missing something.

1 Like

That’s depressing to hear. Is there really someone who acted that way? If you have difficulties with something, feel free to ask me if you want, I find the whole modding process more comfortable and straight than during the old days.

2 Likes

Thanks Pouk! You’re a champ :smile: