I'm writing Yet Another HAM Editor For Descent II. aaa
Well it's as the topic title says. Using things I learned from writing my command line tool, I'm now revising my ancient incomplete graphical HAM editor to be a complete product and be much easier to use than it's ever been before. At the moment, I've written a new method of importing and changing around models that make it easy to swap models around while retaining the right guns, managing the object bitmap table, and so on. Individual editors have been improved, and enumerated combo boxes are now used to make it easy to see what the formerly cryptic IDs correspond to, as is the case in my data compiler. Most of these new convenience features are fully implemented at this point, so it's just a matter of testing and getting everything in the UI hooked up properly. Save me...

There's not much to look at, but here's a few pics
[Image: vnmCDJ4.png]
[Image: t0wV4yU.png]
[Image: pXGGgAe.png]
While working on this I've gotten polymodel importing going. It's much easier than it's ever been before, with no more need for the makepof tool. In addition, I've fixed up a great amount of bugs in my Blender exporter script, most notably angles are now correct and stacked rotations should render just fine. Animations and guns are tied to the model and are automatically transferred to robots that are using the model. Texturing is also silky smooth, with no need to worry about which former model's space to add object bitmap pointers.

One minor annoyance I've brushed up with testing though is that models have a pretty hard limit of 32kb of data. A test model using Blender's suzanne mesh is more than enough to push through that (well it kinda if she isn't textured...), Descent can handle an object this big but subobjects become impossible to use, since subobject calls are a signed 16 bit integer. The model is big enough to cause Rebirth to crash when trying to load it in newer versions, but it functions in older versions okayish. Oh well, have a pic of suzanne anyways but with the test swingarms not rendered.

[Image: NAVmnfw.png]

As one other side effect, I'm likely just going to throw out the code I've written in the past for generating HXM files. With Rebirth loading HAMs from archives, there's almost no need for it anymore, and the nature of replacing items rather than adding them makes it much harder for me to manage your object bitmaps and object bitmap pointers for you. vertigo add-on VHAMs might still be editable, for those who don't want to include copyright resources in their mission files I guess.
I could add support for a 32-bit subcall displacement, though using it would then require the new Rebirth version. Nothing else would understand it.

What is the nature of the crash? Some invalid models may provoke an exception, but if you are getting a memory access crash, I would like to fix those. Even for the exceptions, it would be nice to make the game reject the unhandled model a bit more cleanly. Can you post models that crash Rebirth, so that I can try to make it not crash on them?

Several years ago, I added support for missions to set the name of their HAM file explicitly. It includes a special hack to search for that HAM in a HOG of the same name. The primary use is for people who want to reuse without modification the Vertigo HAM. Such people can direct the game to load D2X.HAM, not ship the Vertigo resources, and instead include a note to players that Vertigo must be installed separately. This also saves on download size a bit, if anyone still cares about that. It's not specific to Vertigo though. A mission can reuse any HAM of the same file format as Vertigo used.
Hmm, amusingly enough when I went back to try it again the older version of D2X-Rebirth also started crashing with a "invalid polymodel" error. I'm amused it worked in the first place.

I don't have any builds newer than the "beta 2" release available on the downloads, but this coughs up a error screen also informing me of an "invalid polymodel" and producing this crash log. The model in question is this model. I'm assuming it chokes on the interpreter data, since the submodel_ptr fields in the polymodel structure are all wide enough to handle the larger pointers.

I noticed while researching problems with this that my own interpreter uses unsigned values in the SOBJCALL instruction, so this is what the model would look like if it didn't fail:
[Image: xByeIsD.png]
You exist! I am glad you are still alive InsanityBringer!

This brings back memories http://www.planetdescent.net/index.php/t...7d9e2791ad
Odd as this may seem, I don't know how to use the POF file you provided. I renamed it to shadow various built-in POF files, but was never able to get it to load, so I can't try to reproduce the crash. Could you explain or link to an explanation of how to override a built-in robot (preferably an easy-to-find one like a Class 1 Drone, a P.E.S.T, an I.T.D., or a P.I.G.) with your custom model?

Also, although this remark is six years late, I agree with your comments in the thread that Blarget linked: these file formats ought to be replaced with something more accessible.
ah, sorry about that. The only way to apply that with the engine would be to make a development build of Descent 2 that can parse BITMAPS.TBL or load it with Descent 1 v1.0... (and as a minor problem that's a slightly extended POF file format with some additional bits in the subobject header, but I can easily write out a version 8 one that Descent can actually handle) I can provide a prepatched HAM file via PM if that would be the most convenient method.

Also, I spent last night working on the model exporter for blender, and it's almost done at this point. Unlike my previous one, there is no intermediary program to process the output as needed, you can now export directly to POF which can then be imported straight into your HAM file from my tool. Since I'm more ambitious than I was six years ago, I'm actually vaguely tempted to research building BSP trees since it would be an amusing curiosity if my models could work right in vanilla, but we'll see...
I always enable the developer features in my local builds, and that enables BITMAPS.TBL support. I don't actually have a BITMAPS.TBL present though, so gamedata_read_tbl bails out early.

I'd be happy to get the ability to customize objects more directly, if you don't mind providing a BITMAPS.TBL or instructions on how to make one. It might aid future development work. It would also be a useful reference for what to improve if that file format ever gets overhauled. Wink

As for backward compatibility of your model, you might (obviously untested, since I can't even load your model yet) be able to work around the 16-bit limitation by chaining subcalls. Instead of laying out your model as you do now, structure it as:

top-level object
- arm 1 of top-level
- arm 2 of top-level
-- sub-object of arm1
-- sub-object of arm2

This would let you have shorter jumps than if you did:
top-level object
- arm 1
-- sub-arm1
- arm 2
-- sub-arm2

If you were very ambitious, you might even break the arms into more pieces and interleave further. Every new sub-call gets you an additional signed 16-bit displacement you can use to move within the model data.
I've played around a little with a "decompiler" to generate bitmaps.tbl files, I can toy with it a little more. I'll probably need to make my own dev build at some point to test it out, I'll probably do that on my linux box so I can both try building there and test if the current version of my editor will work fine on it (older versions have worked fine)
Gave my model exporter toolchain a thorough test with an actual polymodel rather than some test data, I decided to try making an improved player ship model since I never liked most of the previous attempts and I never liked the game's own ship, it's not near as cool looking as it was in the game's cinematics. Here's a pic of the model:

[Image: WNCbmCtl.png]

Exporting this bad boy helped track down quite a few bugs that can rise up when working with an actual modeling workflow, as well as some smaller oddities that never came up when simply working with simplistic test models. It also shook out a few bugs within the polymodel previewer in my tool. It looks pretty great in game, here's it applied to a robot:

[Image: mTA6kdFl.png]

I am super pleased with how the workflow is working now, this should allow for much more complicated polymodels than before with POLYTRON and the like, but there are still limits. the 32kb data limit is troubling, but I'm investigating kp's idea of chaining SOBJCALLs. It requires a smarter IDTA generator, but I have some ideas on how to make it work. This should allow for pretty detailed models, but there's still a overall limit of 1000 verts. Some cycling tricks can extend the vert limit, but models doing that can't be created by a matcen or else they don't morph correctly.

Forum Jump:

Users browsing this thread: 5 Guest(s)