I need some way to keep track of all the information I discover and need, and what better way for all than to make it public?

MSH Chunk Tool will be an easy-to-use utility for transferring MODL chunks from one MSH to another without the need of a hex editor, and will be able to do so with much more efficiency and capability than a hex editor. Someone has also requested that I make a better MSH exporter. I may also use this information later to do this also. Comment as you please. I am using http://personal.riley-man.com/swbf/edit ... f-msh.html and a hex editor to gather a complete summary of the msh file format.



Done:
Mesh Loading (would like to know what the ENVL section actually does, though)
Prototype user interface


.msh File format; for the moment, this is all the info I need.


"HEDR" (4 bytes, indicates header)
- Integer (4 bytes, add 8 to this number and you get file size)

"MSH2" (4 bytes, indicates start of mesh information)
- Integer (4 bytes, add 16 to this number and you get file size)

"SINF" (4 bytes, header for info used only by ZeroEditor)
- Integer (4 bytes, Length in bytes of following section = 76 + length of Text under NAME heading)
- "NAME" (4 byte header)
- - Integer (4 bytes, indicates length of section)
- - Text (Zero-terminated string, does not seem to hold any real purpose)
- "FRAM"
- - Integer (4 bytes, should always be 12)
- - Two Integers (4 bytes each, appear to be 1 and 100 for an object and 0 and 1 for a player model)
- - One Integer (4 bytes, seems to always be 1106231967)
- "BBOX" (4 byte header data for bounding box)
- - Integer (4 bytes, should always be 44)
- - 44 Bytes of data - 11 Integers (I will have to see what to do with this. I don't know how this part works)

"CAMR" (4 byte header for camera information)
- Integer (4 bytes, length of following section = 52 + length of NAME text)
- "NAME" (4 byte header)
- - Integer (4 bytes, indicates length of section)
- - Text (Zero-terminated string, no remarkable purpose)
- "DATA" (4 byte header for the actual camera info)
- - Integer (4 bytes, should always be 40)
- - 10 Integers (Likely store information on camera position and orientation)

"MATL" (4 byte header outlining textures (materials) used for the model)
- Integer (4 bytes, size in bytes of following section, total is a bit more complex due to numerous strings and a variable quantity of MATD headings)
- Integer (4 bytes, indicates number of MATD headings)
"MATD" (4 byte header. There can be more than one of these)
- Integer (4 bytes, length in bytes of following information)
- "NAME"
- - Integer (4 bytes, indicates length of section)
- - Text (Zero-terminated string, name of material, but NOT name of the targa file)
- "DATA"
- - Integer (4 bytes, should always be 52)
- - 13 Integers (Contains miscellaneous information on the texture)
- "ATRB"
- - Integer (4 bytes, should always be 4)
- - Integer (4 bytes, usually 0 for player models. Supposedly set Material Attribute. I noted that the dark trooper's value here for both materials is 1024, and its lowres is 0. 0 appears to probably be no special attribute)
- "TX0D" (4 bytes, it is TX [zero] D, NOT TX [letter O] D. I read that not all materials have this)
- - Integer (4 bytes, shows length of section)
- - Text (Zero-terminated string, file name of targa texture for material)

"MODL" (4 byte header, there will usually be a considerable number of these. There should, for player models, be a dummyroot and a boneroot at the minimum)
- Integer (4 bytes, indicates length of MODL section)
- "MTYP"
- - Integer (4 bytes, should always be 4)
- - Integer (4 bytes, sets MODL type: null, skin, envelope, static, or shadow)
- "MNDX"
- - Integer (4 bytes, should always be 4)
- - Integer (4 bytes, what number the chunk is as appears in the file - first, second, third, etc.)
- "NAME"
- - Integer (4 bytes, indicates length of section)
- - Text (Zero-terminated string, name of chunk. Usually acceptably descriptive.)
- "PRNT" (4 byte header, used to set a model's parent, is optional)
- - Integer (4 bytes, length of section)
- - Text (Zero-terminated string, name of parent MODL. DummyRoot does not typically have a parent.)
- "FLGS" (4 byte header, used for child flags, optional)
- - Integer (4 bytes, should always be 4)
- - Integer (4 bytes, all the values I observed were 1)
- "TRAN"
- - 44 Bytes of data which I will not touch on at this point
- "GEOM"
- - Integer (4 bytes, length of section in bytes)
- - "BBOX"
- - - 48 Bytes of data to ignore at the moment
- - "SEGM" (4 byte header, this is where all the model data is stored)
- - - Integer (4 bytes, length of section in bytes)
- - - "MATI"
- - - - Integer (4 bytes, should always be 4)
- - - - Integer (4 bytes, index of material to use)
- - - [ Length of SEGM section - 12 = quantity of bytes for model info ]
- "ENVL" (4 byte header, probably used for stuff that has to do with the skeleton)
- - Integer (4 bytes, length of section, tends to vary)
- - Section (length is indicated by above integer.)

"CL1L" (4 byte header, seems to be at the end of every mesh file)
- Integer (4 bytes, I have not observed it as equalling anything but 0)

MATL and MODL?? not all have SINF XD also you forgot COLL (from cloth)

This post is going to be frequently edited.

I am in the process.

biohazard wrote:

This post is going to be frequently edited.

I am in the process.

oops sorry i must read better the next time XD

No problem


Right now I've nearly finished rewriting mesh file reading so that it stores all of the file info in memory in a way that it can be efficiently modified and then later resaved.

May I ask which extra functionalities you're going to ad to your tool as well? I thought I'd mention it, since you now already have complete a tool that can transfer and rename model chunks, why not ad functionality for adding transparancy?

It's not to that point yet. I still have to iron out the bugs for mesh loading, but it'll be all completly downhill once I get the loading to work.

I noticed that when you transfer MODL chunks with a hex editor, there are a ton of things that just don't work. When you hex edit, you don't change the MODL index and you don't make the appropriate changes under the MATL section; I'm astonished that the meshes are still functional using the hex editing tutorial. What the tool will easily be able to do, is cover all these bases, and allow customization on a much higher level with no hassle, including adding/removing/modifying textures and materials, and will allow the user to make changes to the indiviual MODL chunks with everything beside its actual geometry.


EDIT: Yay, I've eliminated all the bugs but one. It's loading the stuff properly from what I can tell, but once it gets to the MODL chunks it's only loading the first two (DummyRoot and [side]_inf_[unit]) Probably just reused a variable someplace without thinking.



EDIT2: My source for understanding the file format has failed me. I have no clue what ENVL is, and it's popping up in the file. Whoopiedoo.


EDIT3:
Loading appears to work perfectly fine now. I would like to know what ENVL is for, though. It *should* all be downhill from here.


GUI screenie (this is going to change, I don't know how much):

Please note that though there are buttons, not all of them work yet. In fact, the only thing that does work at this point is File > Open.


Message log for successfully reading a msh file, for the curious:

im 99% shure ENVL means enveloping

so does it deal with the model's geometry only? As in, should I give the user the ability to modify this portion of the chunk?

well the enveloping is used on units with bones, it determinates which point moves with which bone, i dont think it makes senese to add a support for enveloping modifications since you must know which point exactly you reenvelope which is pretty hard to display without a 3d-engine

If I recall this right, envelopping is basically the "assigning of points to bones". So, if give the user the ability to transfer certain model chunks, you should probably let the ENVL section go with it. (IOW: The ENVL should be left connected to the same MDL chunk)
Though I don't know how the envelopment section is located in a mesh (next to their corresponding mdl chunk, or just at the end of the file. If it's the latter, you have a lot of figuring out to do.) Just as a side note; I find it really cool you're trying to do this

Thanks.

Okay, I think loading can be considered 100% done at this point.
Exporting is done.

Now I just need to figure out what's wrong with my importing.


After that I'll make it so you can save your changes to the mesh, and then add all the bells and whistles you would expect from a presentable tool

biohazard wrote:I noticed that when you transfer MODL chunks with a hex editor, there are a ton of things that just don't work. When you hex edit, you don't change the MODL index and you don't make the appropriate changes under the MATL section; I'm astonished that the meshes are still functional using the hex editing tutorial.

If an MATL chunk needs to be changed, it is (and it almost always needs to be changed for actual model chunks), but most of the time people hexedit cloth, which has its own separate texture data stored in the MODL chunk. The MNDX is (mostly) irrelevant; having indices of 1,1,2,3 works just as well as 1,2,3,4, because duplicate index numbers will just be ordered based on physical position in the file.

well the enveloping is used on units with bones, it determinates which point moves with which bone, i dont think it makes senese to add a support for enveloping modifications since you must know which point exactly you reenvelope which is pretty hard to display without a 3d-engine

Without some sort of GUI you're looking at trying to read numerical data to interpret where various vertexes are and then give them an envelope. I have no idea how you'd read this data in an easy-to-understand format. Usually it's much easier to just assign a single MODL chunk a parent bone in lieu of proper enveloping. Anything more should really require work in a modeling program.

May I ask how your loaded and then exported model looks ingame?

At this point all it can do is:

Open a mesh
Export an indiviual MODL chunk as a .chunk format (specialized format that's made for optimum readability by the program)
Import an individual MODL chunk and add it to the opened mesh
Remove an individual chunk from the opened mesh

You cannot save your changes to the mesh yet. That's next.

After that, I'll have everything you do with a hex editor nailed down. I want to, before I release it, make it possible to do similar actions concerning MATDs and many properties of MODLs and MATDs, the most significant of which will be the ability to change the targa file used by any MATD and also change which MATD is used by any MODL.

It will not be able to change any geometry information. Because ENVL falls under this category, setting it will, if anything, be just an "advanced feature", only there for the rare case that someone might need it.



EDIT: Anyone know what's the purpose of the CL1L and four 0 bytes at the end of the meshes?

Just like to say I'm very impressed by what your doing here, this could be a very useful asset for the SWBF2 modding community.

And it'll stop DEVISS getting 65,000 hex requests a day.

biohazard wrote:EDIT: Anyone know what's the purpose of the CL1L and four 0 bytes at the end of the meshes?

I would guess that it's some kind of closing tag. I'm pretty sure meshes are corrupt without it, but I haven't seen any mesh with anything except those eight bytes at the end.

Alright, another new question. What should I do with the ANM2 section that comes after MSH2, as a part of HEDR?


EDIT: finished coded in saving, just have solve a couple more bugs. For some reason it keeps messing up when it comes to BBOX and SEGM. I doubt it'll take long to figure out, though.

EDIT2: Yep, problem was just that I forgot to check to see if the MODL I was writing was actually supposed to have a GEOM section or not. (It was creating one regardless)

EDIt3: Lovely; it loaded back up a saved with no errors. And 51 of the MODL chunks I expected to see are now absent -.-.

EDIT4: Yeeey, fix'd. It now converts a loaded file into efficiently-stored and easily modifyable data and then back again flawlessly! (I think) Time to test its results in-game and stuff, then add tons of Bells and Whistles.


EDIT5:
Fweeeee...
Just found out that cloth MODLs are stored a bit differently from others. That means they aren't loading properly. Augh. I'll resume work on this tomorrow. Going to do some nice, relaxing, hintnode placing for my Dee'ja Peak map now.


EDIT6: Ok, now it's loading the clone commander (most importantly, its cape) just the way it should. Bliss. Now data editing is going to be a bit more difficult bacuse I have a couple completely different types of MODL chunks that both need to be analyzed using the same interface. Transferring chunks is (I think) done now. I have yet to test it with Mesh Viewer or ingame though. I just need to add the ability to transfer MATDs, update the saveing and import/export code to include cloth MODL chunks, and fix my value inputting code so it stops glitching on me.


EDIT7: Someone else post already! Having to edit 7 times is a bit much, don'cha think?
Current GUI, MATD editing stuff will go under the MODL stuff. More than just Name, Type, Parent, and Flags will be editable before release.



EDIT8:
Anyway, munged a modified mesh from my tool, and BFront2.log gave me this:

Message Severity: 3
.\Source\EntityGeometry.cpp(619)
Entity "rep_inf_ep3_sniper" missing geometry "rep_inf_ep3sniper"

And crashed the map before it finished loading. And the munger had no fuss. I also noticed that it didn't show up in the mesh viewer.

EDIT9: Maybe it has something to do with materials. I'll hold up on trying to fix this until after I've pretty much finished the GUI.

This was requested a long time ago, but never done. A great tool, if it's completed.
Impressive no-doubleposting, I must say.

Well, when resaving the clone commander, though my tool loads without issue, the resulting file is 3KB less than the original. Time to go through and see what it is I missed -.-;


EDIT: Ok, now I have to make it load SKL2 and BLN2 chunks. Anyone know what BLN2 does? I figure SKL2 must have something to do with the skeleton or something.


EDIT2: Whooooo! I loaded in clone commander mesh, saved it back, and it appears to have generated a perfect duplicate of the original. Yeeeey Celebrate


EDIT3:
Great, it won't load into the mesh viewer like the original does.

EDIT4:
Lovely! Just lovely. The msh file stores 32 bit integers different from the default sream commands. This will be fun, I've never been very good with bits. Oh, and it only does this for the integers which indicate the length of file sections. Wait, no, somehow I'm getting the wrong numbers to put there. Mehhhhhhh. Yeaaa my HEDR size is over 6000 bytes short of what it should be. Maybe SKL2 and BLN2 are included in HEDR. That might solve one problem.

EDIT5: Negative, even with ANM2 SKL2 and BLN2 all inluded in HEDR's size, I'm 3000 short. I don't know what else to do. Maybe just add the 3000 bytes, see if that works -.-


EDIT6: discovered I forgot to update some other code to make it deal correctly with cloth. Now I'm down only 1000 bytes for HEDR and MSH2 both.



EDIT7: Making good progress. I'm almost done with the fixing, and then I can finally move on to the nice and easy part of just allowing the data to be edited.



EDIT8:
detailed report on what needs to be fixed, hopefully not too difficult to understand: