(sorry for the multiple edits, I get disorganized at times)

I can hex the tga names , but I can't create low res models.
(Couldn't figure out who needs hexing though)

The only ones that look like they need low res are Heavy and Pilot.
The stock low res for trooper and darktrooper look groovy and play nice with the given textures.

You could 'get away' with using the stock stormtrooper low res for Pilot.
(Playing on the idea that at a distance they seem simular.)

And I don't even know where Heavy originated.
A low res for it would have to be built.

I'm working toward being able to kitbash regular (then low res) models with 'some' success.
But I'm not using a modeling prog to do it (I'm using a spreadsheet and shreads of my soul). So progress is very slow.

Great Job, again, SleepKiller!
Another map that was wierd to play in BF2 made playable

I found a reflection in one of the halls.

Quote from: Epifire on February 28, 2012, 07:23:35 AM
Ande is a genius

I'll second that.

Glad it's working out.

I'm reworking the loader for all my tools with the code from this one.
All the other tool have a built-in error regarding size, and this tool fixes it.
(I wouldn't have made it without your request SK)

I'm thinking a bunch of little tools to do little things to msh files will be easier to make and use than one big tool like I wanted.

Next up for this one is the ability to call it from a command line for use in batch files or called from another program.

-edit
Sorry about hijacking my own post.
Ran out of room above.

.msh SPECULATIONS
[spoiler]
I've noted some interesting things about how all these pieces work together, but am not sure how to word it.
Bear with me as I work this section out.

I noticed that the eff_ (effector?) MODL chunks all have either no rotation, (-0,-0,-0,1), or an all -0 vector with a very slightly off scalar (making the quat non-normalized)
I bet these could all be 'zeroed' to , (-0,-0,-0,1), and were probably intended to be to begin with.

The MATI chunk indicates what material(MATD) is to be used when rendering the geometry defined in it's SEGM.
The MATD's are referenced in order of appearance in the MATL. Starting with 0.

To get geometry to show up in game, it needs to be in a SEGM.
That SEGM needs to contain a minimum of a POSL, NRML, UV0L, and STRP chunk.
The UV0L isn't required, but if you want your mesh to not be plain white, It must be there.

The POSL lists all the vertecies for the mesh.
All the other SEGM sections refer to vertecies by their order of appearence in POSL (starting at 0.)

Positions in the chunk for POSL, WGHT, NRML, and UV0L have a 1 to 1 relationship.
An example:
Entry 15 in POSL is a vertex.
Entry 15 in WGHT is the weight info for that vetrex.
Entry 15 in NRML is that vertex's normal info.
Entry 15 in UV0L is that vertex's UV point on the texture.

NDXL, NDXT, and STRP define polygons and edges by listing vertex references in the order needed to form the poly.
The references are their entry position in POSL.

STRP also describes strips of triangles that, once coupled with their POSL, NRML, and UV0L information, define the actual stuff that shows up in game.

Trialgle strips are appearantly easier for the machine to manipulate.

NDXL and NDXT are ignored by ModelMunge.exe, and therefore do not make it into the game.

NDXL and NDXT are used by some programs to find the edges that conect vertecies.

I have tested gathering the triangles from the STRP and replacing NDXL with them, and not only does it work, but if I sort each triangle so that the lowest index comes first, the sort the entire NDXL by that first index, I end up with the same list of tris from NDXT.

Weighting.
WGHT referes to an entry in the ENVL contained in the same GEOM chunk.
ENVL is a list of MNDX references.
There are spots for 4 weights in each WGHT entry, though most models use only 1.
(I haven't actually seen any models use more than one per vertex.)
If you do use more than one weight, then the percents for all of them must add up to 100% (1.0)

Some MODL's have no EVNL.
The examples I have seen are mostly hands.
They are positioned within the heirarchy so that their parent is the bone_*_hand.
I don't know what tells ModelMunge to weight it to the hand bone.
It could be the absence of an ENVL and it's position in the heirarchy.
Or the absence of ENVL and the PRNT entry.

The CRCs in KFR3, SKL2, and BLN2 all refer to the envelope bone MODL chunks.
There is a groovy little program in the BF2 mod tools bin that will take whatever text is on the clipboard, calculate the CRC and place the CRC on the clipboard.
I don't exactly like the manner in which it runs, but I am glad whoever wrote it, did.
The algorithm for creating these CRC's is not known at this time. (if you know, drop me a line )

[/spoiler]

SOURCES[spoiler]
The documentation for the BFBuilder and BF2 Mod Tools.

Ande (ANDEWGET on GT) Has been the biggest contributor to all this.
He is working on an exporter for the modern version of the XSI modtool.
Idealy, once it is done, there should be no need for all this.

The Extended Riley pages MSH File Information (extended by Ande) This guy is doing a wondefull job exploring this format. I hope, one day, that our answers mirror each other.
His site has more info and tools : Ande Projects

The Riley pages (lost to the internet ages and resurected in archives, the info is a good start, and when I move on to lvl files, the Riley pages will prove invaluble, I am sure.)

A myriad of posts on GT and SWBFGamers.com. Both of these boards have hard working and dedicated modders. As I gather more resources I will put your names and links to your research here.



(Tracking all these down is going to take time, but it will show up here, I promise.)

Blood, sweat, and tears inside the SciTE editor, the AutoIT help file, and XVI32.

Genuine curiosity for how and why the msh file format has remained a mysterious black box for over 6 years.
[/spoiler]

TOOLS USED TO FIGURE THIS OUT[spoiler]
HEX EDITOR (for looking at msh guts)
Freeware Hex Editor XVI32

TEXT EDITOR (mainly for formatting text copied in one program for pasting into another)
AEdiX Suite

SPREADSHEET (for analyzing msh guts)
OpenOffice.org - Calc

SCRIPTING LANGUAGE (for chopping and stitching msh guts)
AutoIT

3D PROGRAMS (Miscelaneous bits of information)
Ultimate Unwrap 3D - A shareware UV mapping program. It has a plugin that can load SWBF msh files. If you tell it to load all models instead of just the ones with geometry, then you can access information about the bones. Specificly relative and global rotations and positions.

3D Object Converter - A shareware 3d file viewer and converter. This program will let you browse geometry and materials. You can also unwrap the model. While the unwrap from this prog is not 100% it is definatly close enough to assist with basic reskinning. Interestinly, it gets it's polygon unwrap info from NDXL and not the STRP. (The STRP makes it through ModelMunge, while NDXT and NDXL do not)

Milkshape 3D - A shareware 3d editor. Many plugins for export and import. While it isn't directly usefull for handling MSH files, it is much more approachable as a modeling program than the big players (3d studio, XSI, Blender, ect.) For static models, exporting as VRML 2.0 then converting to MSH via the SWBF MSH Viewer is really handy. If we could get a msh exporter put together for this one, it would solve our animating and modeling problems for good. (and for less than a hundred bucks.)

SWBF MSH Viewer - If you want to see a MSH without munging it into the game or jumping through ZeroEdit's hoops, this is it. It can export your MSH as a VRML97 file. It can load VRML97 files and save as a MSH. No bones make it through this process, only the geometry gets saved. It also has a debug feature that was my starting point for decyphering the MSH structure.

EVERYTHING ELSE (Miscelaneous bits of information)
... Google, Yahoo, MSDN, various math and 3D graphics engine sites... Basicly all the dustiest, darkest, most dis-used sites on the internet...



[/spoiler]

-edits-[spoiler]
05/19/2012 -Revised some definitions and data type descriptions.
           -I'm getting ready to sync the tags with my tool source, but need to do more testing. (it's a mess right now)
           -The MSH INFO tool may go away and turn into a txt report tool. AutoIT's method of handling gui widgets makes me cross-eyed. Txt reports can be customized so much easier than that logic-defying listbox.
           
03/22/2012 -Added speculation section. Ran out of room in first post, so I hijacked my next one. I think I'll work on putting this in a doc or txt file.

02/27/2012 -Fleshed out KFR3. standard bone heirarchy example. Revising many definitions... Synced up definitions.

01/21/2012 -WGHT references envelope entries and not MNDXs like I thought.

01/20/2012 -'editor' gets it's own thread now. I have more info, but haven't got it ready yet.

12/18/2011 -Updated Screenshot of the 'editor' program I'm working on. My hopes are that it's completion will help me flesh out some of the question marks in the above notes.

12/14/2011 -Added ANIM, CLRB, MYTP, LGTI tags.
           -Files are loading fast now, but I'm running into new tags and bad file sizes.
           -The problems are with 3rd party msh's, but I'd still like to resolve them.
           -No new shots of the GUI, re-working the code first. Pretty won't fix bad code.

12/13/2011 -Found 3 new tags (ANIM,CLRB,MYTP). 2 of them disturb me. The worst is MYTP. It contains the same info and is in the same place as MTYP (Existing in place of it, almost). So it was either intentionaly misspelled, or there was a bug in whatever program made them. Doing a more intense search for msh tags now. I was only looking at BF1 models, but now I'm looking at every msh in my archive. (many thousand msh files, since everyone thats released thier source also re-released assets that were either already released or included with the mod tools.) Been at it for 2 hours and I'm a quarter through determining which ones fail a size check (un accounted for tags.)  So, new tag entries in a cpl of days...

12/02/2011 -Added SHDW tag. Courtesy of Ande. Not yet reflected in tools. It seems to only be present in 'some' static models.
           -corrected (guessed at) [/b]SWCI[/b].
           -dead wrong about CLRL structure
           
11/28/2011 -NDXL and NDXT are depriciated. I thought they were redundant, anyway since the STRP is a more efficient way to store the triangle info. Thanks to ANDEWEGET on GT for the heads up.

11/22/2011 -Updated chunk2MSH tool to update size values automaticly(see readme). inacurate SWCI qualifier removed. inacurate GEOM-BBOX parent fixed.

11/18/2011 -Started enumerating sources.
11/15/2011 -upped screenshot of tool.
11/06/2011 -Got rid of some extra words.
11/05/2011 -added basic CLTH info.
11/04/2011 -added SHVO offset info. updated tools.
11/02/2011 -Attached a zip containing src and compiled scripts from early in this process. (v1)
10/31/2011 -Got rid of some extra words. Hardened some of the known descriptions.
10/27/2011 -updated NDXL, NDXT, [STRP]
10/27/2011 -fixed WGHT (skipped one of it's fields, and made a pretty good guess at it's structure)
10/26/2011 -fixed BBOX (skipped one of it's Rotation fields.)
10/25/2011 -Fleshed out some info from the MSH Viewer. (I'l love to talk with whomever made it.)
10/24/2011 -Revised the layout a bit and expanded BBOX info.
            it makes more sense to look at each tag as it's own chunk(from a programing point of view.)
            Dead wrong about ATRB. Removed bad info.
10/23/2011 -added NRML, CLRL, UV0L, NDXL, NDXT, STRP, SWCI, BLN2, KFR3, CYCL offset info.
10/23/2011 -Revised the layout a bit and added POSL, MATI, SEGM, ENVL, SKL2 offset info. Restructured the section descriptions.
10/22/2011 -added offset info section.[/spoiler]

So I have just figured out what a quaterenion is.
(basicly a way to represent rotations for 3 axis using 4 numbers)

A shot in the dark, does anyone know how to convert a quaternion back into degrees?
(without having to go back and finish the degree I never started...)


The KFR3 tag stores keframe info and I am guessing it is using quaternion rotations of joints and the length of bones to 'build' the skeleton for each frame.

I can visualize ( 90 , -0 , 90 ) but (0 , 0 , -0.117461 , 0.993078 ) just makes me ill.....

edit....
Maths - Quaternion to Euler Examples 90 degree steps - Martin Baker
This looks promising, but my spreadsheet hates the formulas.

To much noob control kinda spoils the game though.
That same sort of elitism ruined tribes.
Now it's just the same 10 guys playing the same 5 maps, forever.....

heh

It is the respirator from Darth Clod's Tusken Raider for Jedi Knight (2 or 3).

This is so sublime.
I love it.
Great work on this mod, Sleepkiller.

Bespin: Cloud City is already fun, this doubles that.
I bet the snipers are going to love it as well.

So I am paused on my programs for a bit to take a few swings at building my Tuskens, when this happened....

It seems things in JK3 are about 30 times larger than in BF1.

A client on another machine, logged into the server, running a 3rd party auto chat macro?

Kinda like using a tree limb to pull an engine though...

I've alwaysed used 'the city' to refer to any non-rural environment.

I've also always refered to New York as 'that dirty place'. But that's just based off a 6 hour visit.

I only tried multiple copies of the one model without textures.
And only in single player for a few moments on my blank test map.

Since your getting the crashes in multiplayer, thats a starting point... something about multiplayer hates the model.

My guesses on the crashing, is that it has something to do with poly count or complexity.
There is no shadow volume or lowres geometry, so something might be going on there.

Some of the SEGMs are pretty big, poly count wise. But not way too big.

Or some of the tiny detail shapes (the mouse for instance) might be messing with it.
I read somewhere that Zero doesn't like polys to be to small.

Could try yanking out entire SEGM chunks, and see if the problem is localized to a specific geometry.
That could also ruin the model, though.

It could be that simply fixing the size and respelling the MTYP tags might fix it so that it runs right.




BTW, thanks for verifying the x64 functionality.

Well, I got it in game with no edits, and no crashes.

the little screenshot is with the size error and the MYTP misspelling.

Have you tried doing a clean or a manual clean before munging?

All it alters is the 4 bytes after the tag. (the size field)
And only if it find a bad size and you give it the ok to fix it.

If the incorrect size fields are causing it to crash, the yes.

The only way to know is to test.



Here is a possibility for failure on the program's part:
If there is a new, un-documented tag in the file, then it will not recognize it and add it to the previous tag.
It will still get saved, but the size of the altered tag before the un-recognized one would be incorrect, and that might hose the munger and or the game (depending on the tag.)

I've accomidated tag names I know about, but havent seen in any msh's, like TX4D and such.
Also for the MYTP mispelling of MTYP.
I was pretty thorough, but it's very possible to miss things.

On a side note, I don't have that asset pack.
You wouldn't happen to have a link, would you?
I'd like to discect that desk

-edit-
NM. Google is my friend. DMI Prefab Pack

-edit again-
The MSH2 on that desk is incorrectly including the CL1L tag at the end of the file.
So the correction is valid.
I still don't know if it will or wont crash a map.

-edit again-
that whole pack seems to have the same issue. (MSH2 + 8 bytes)

-edit again-
Ok tested on a known good model, adding the extra 8 bytes to MSH2 doesn't crash anything, so it must be something else fudging that desk.

-edit AHA!-
This is one of the msh's that has MTYP mispelled as MYTP.
It's at decimal offset 1856 and 1952
Just change to read MTYP
I am willing to bet that if the msh can't tell munge what type of geometry it is, that munge will happily crash it.
(Or at least create a malformed modl chunk somewhere.)

-edit un-AHA-
Ok...
I tried making the error on a known good model (Changed MTYP to MYTP) and it munged and ran perfect.....
...
I'd still correct everything.. the sizes, the MTYP mis-spell.
...
Still looking at it...