LEGO Indiana Jones 2: The Adventure Continues *_nxg.ghg files

[marty]

I have been wanting to properly extract and view _nxg.ghg files from LEGO Indiana Jones 2: The Adventure Continues (PC) but there arent any great tools for doing so. These files are character models but they dont have textures, textures are stored in a different file somewhere else and arent too hard to extract. Each file has different chunks starting with "02UN" or "NU20" (Each chunk name is flipped for some reason) thats followed by "OFNI/INFO" which is the info chunk of the file, it has "ukhtryggva" (Code name for the dev who built the file) then the build date "Tue Jul 21 12:02:51 2009" then comes the "LBTN/NTBL" (Nametable chunk) which has "default_string" then followed by a long list of names like "TT5_Blowup_NG", "LeftFoot" or "TT8_Hat_NG" and then comes the "HGXT/TXGH" chunk after that comes the "SDNB/BNDS" chunk then the "HSEM/MESH" (Most likely mesh chunk) after that at the end of the file there is a "LTMU/UMTL" (Possibly material/lighting/uv chunk) There might be stuff I missed so if anyone can help with reverse engineering this file format that would be GREATLY appreciated 🙏

Test nxg.ghg files.zip

Edited July 25 by marty

[shak-otay]

Mesh vertex format for the first sub mesh appears to be simple, Donovan:

edit: half float uvs look a little bit strange, imho:

edit 2: rest of sub meshes is not a fun. Small chunks which I don't know how to collect them in an easy manner...

But uvs look better.

 

Edited July 25 by shak-otay

[marty]

Quote

Mesh vertex format appears to be simple, Donovan, first sub mesh:

Oh well that looks promising

 

Edited July 25 by marty

[marty]

Quote

edit 2: rest of sub meshes is not a fun. Small chunks which I don't know how to collect them in an easy manner...

I see...

[marty]

 here is what the donovan model looks like in game

[marty]

https://github.com/AlubJ/TTGames-Extraction-Tools

I've also been looking through the source code of this tool that can somewhat correctly extract meshes from _nxg.ghg filse but unfortunately it messes up the UV's and the meshes are all over the places (no bones either) posting it here if anyone wants to take a look

Looking at the source code I've figured out the real purpose of each chunk

NU20 - Version information

INFO - File metadata

NTBL - Table data

BNDS - Bounds data

MESH - 3D mesh geometry data

TXGH - Texture data

HGOL - Hierarchy/group data

DISP - Display/dispatch data

I had previously missed HGOL as it appear in the middle of the file along with what appears to be other chunks like BNAT/TANB, 3ALA/ALA3, TROP/PORT, BCSB/BSCB,

same with DISP as it appears alongside a TDML/LMDT and SUPC/CPUS followed by "AC:\CONVERSIONDATA\UKKNULP-LI2\CHARS\BELLOQ\BELLOQ_JUNGLE_NXG.GHG"

I also got some interesting output from the tool:

00000008 NU20 Version 0x0a
00000010 INFO Version 0x01
00000045 NTBL Version 0x0a
00000256 TXGH Version 0x01
00000349 BNDS Version 0x0a
00000505 MESH Version 0x04
000ca2b2 DISP Version 0x01
000cbb67 HGOL Version 0x02

I've also noticed most _nxg.ghg files end with their conversion date or something date NUS: 15:14:33 12-03-2009 Converted: 10:37:23 21-07-2009 followed by JMETA at the very end

ExtractNgxMESH Source code.zip

Edited July 26 by marty

[shak-otay]

1 hour ago, marty said:

I've also been looking through the source code of this tool that can somewhat correctly extract meshes from _nxg.ghg filse but unfortunately it messes up the UV's

Seems like most uvs are ok. For those which are not it looks like a know problem - I've notice many double vertices, maybe it's worth caring for them.

[marty]

20 minutes ago, shak-otay said:

Seems like most uvs are ok. For those which are not it looks like a know problem - I've notice many double vertices, maybe it's worth caring for them.

So fixing it wouldnt be that hard? Also what about bones and fixing the the position of the meshes.

[shak-otay]

52 minutes ago, marty said:

So fixing it wouldnt be that hard?

Who said? It's uncommented source. Usually it takes ages to understand other author's code. Plus, it's decompiled source so unsure whether recompile will work.

Quote

Also what about bones and fixing the the position of the meshes.

Without knowing the ghg file structure chances are low.

Best would be to ask sluicer on Rock Raiders United, imho. (If he's still active.)

edit: surprisingly it compiles (usually 50% chance with C#/Net/NuGet for me) but then this error with hardcoded path by AlunJ:

File C:\Users\alunj\source\repos\LEGO TOOLS\ExtractNgxMESH\obj\Debug\net20\HAT_I
NDY_REDDISHBROWN_NXG.GSC does not exist!

edit: ok, replacing the path/filename with a current one did the trick. Cool.

Edited July 26 by shak-otay

[marty]

12 minutes ago, shak-otay said:

Who said? It's uncommented source. Usually it takes ages to understand other author's code. Plus, it's decompiled source so unsure whether recompile will work.

Without knowing the ghg file structure chances are low.

Best would be to ask sluicer on Rock Raiders United, imho. (If he's still active.)

I might try contacting him I'm pretty sure he is active on discord. But I'm pretty sure the _nxg.ghg file format is somewhat if not well documented

edit: I found the documentation https://github.com/AlubJ/lego-tt-nxg-formats should be quite helpful

Edited July 26 by marty

[shak-otay]

Ok, since the source compiles you need to find some coder who's willing to invest his time.

In project ExtractNxgMESH, Program.cs this line has to be patched like so (args instead of a):

extractNxgMESH.ParseArgs(args);

to have the exe working with parameter filename (to get rid of the hardcoded path).

[marty]

1 minute ago, shak-otay said:

you need to find some coder who's willing to invest his time.

and thats the hard part. Unlikely I will unless someone from the modding will care enough. Thanks for your help tho! 🙏

[marty]

1 hour ago, shak-otay said:

Ok, since the source compiles you need to find some coder who's willing to invest his time.

In project ExtractNxgMESH, Program.cs this line has to be patched like so (args instead of a):

extractNxgMESH.ParseArgs(args);

to have the exe working with parameter filename (to get rid of the hardcoded path).

Ok so it turns out the documentation is for a completely different game and doesnt apply to LEGO indiana jones 2. So it looks like we dont have much to work with. Unless the data might still apply in some areas

[shak-otay]

Good to know.

Meanwhile you could trick around with Donovan, apply textures, for example.

(Joining sub meshes is not the best idea, btw.)

edit: the state of the project is unclear - I found an unused function CreateDatFile()

which can create a .dat file for each obj file.

The contence is like so

Quote

0 // Needs Work: Clean necessary
0 // Scale and Origin are not right

3 16 1.935866 81.411710 -15.432590  3.257466 81.518540 -14.997910  3.257466 81.518540 -14.997910
2 24 1.935866 81.411710 -15.432590  1.935866 81.41171 -16.43259
2 24 3.257466 81.518540 -14.997910  3.257466 81.51854 -15.99791
2 24 3.257466 81.518540 -14.997910  3.257466 81.51854 -15.99791
3 16 3.257466 81.518540 -14.997910  1.935866 81.411710 -15.432590  3.257466 81.518540 -14.997910

dividing by the scale 262.0 you can find 1.935866 81.411710 -15.432590 matching the first vertex in

# donovan_nxg
v 0.007389 0.310732 -0.058903

As usual it doesn't make much sense to dig into other author's code (for offsetP, offsetN here) because you're usually faster (but not fast enough) doing own research.

There's offsets logged to the console but I can't make much sense of them atm, guess "Offset vertices" needs to be added to iPos.

edit 2: the FIs were not the problem, I simply had the wrong FVFsize for the half float vertices:

edit 3: this part doesn't use tri strips:

I moved it manually:

 

Edited July 27 by shak-otay

[marty]

4 hours ago, shak-otay said:

Good to know.

Meanwhile you could trick around with Donovan, apply textures, for example.

(Joining sub meshes is not the best idea, btw.)

I'm pretty sure all of the remaining problems with the mesh position can be fixed by figuring out the skeleton. And as long as we know where to look in the file (which we do) it shouldnt be that hard but I could be wrong. We might even be able to use the documentation for the other LEGO game for the skeleton as I doubt it is that different seeing as these two games use the same engine

edit: 

Quote

edit: the state of the project is unclear - I found an unused function CreateDatFile() (not the address logger I hoped for)

which can create a .dat file for each obj file.

The contence is like so

  Quote

0 // Needs Work: Clean necessary
0 // Scale and Origin are not right

3 16 1.935866 81.411710 -15.432590  3.257466 81.518540 -14.997910  3.257466 81.518540 -14.997910
2 24 1.935866 81.411710 -15.432590  1.935866 81.41171 -16.43259
2 24 3.257466 81.518540 -14.997910  3.257466 81.51854 -15.99791
2 24 3.257466 81.518540 -14.997910  3.257466 81.51854 -15.99791
3 16 3.257466 81.518540 -14.997910  1.935866 81.411710 -15.432590  3.257466 81.518540 -14.997910

dividing by the scale 262.0 you can find 1.935866 81.411710 -15.432590 matching the first vertex in

# donovan_nxg
v 0.007389 0.310732 -0.058903

I'm not sure what that is or what its for but I can definetly tell you the project is not being worked on as far as I know.

Quote

edit 2: the FIs were not the problem, I simply had the wrong FVFsize for the half float vertices:

thats a lot of progress!! 😃

Edited July 27 by marty

[h3x3r]

This is where real struggle starts...

I don't see any presence of ROTV signature.

[marty]

47 minutes ago, h3x3r said:

This is where real struggle starts...

I don't see any presence of ROTV signature.

So the ROTV header appears in LEGO Hobbit and LEGO Lord of The Rings. Like I already said the documentation was made for another game but might be somewhat useful for this game. LEGO Indiana jones 2 is the first to use the Next-Gen (NXG) engine so it probably has some differences.

Edited July 27 by marty

[marty]

Ok so I've figured out the issue with the placement and relationships of the meshes exported by the tool turns out the tool doesnt support this specific version of the DISP (Mesh placement/relationship) chunk that is in this version of the _nxg.ghg format.

[marty]

On 7/26/2025 at 11:13 PM, shak-otay said:

Good to know.

Meanwhile you could trick around with Donovan, apply textures, for example.

(Joining sub meshes is not the best idea, btw.)

edit: the state of the project is unclear - I found an unused function CreateDatFile()

which can create a .dat file for each obj file.

The contence is like so

dividing by the scale 262.0 you can find 1.935866 81.411710 -15.432590 matching the first vertex in

# donovan_nxg
v 0.007389 0.310732 -0.058903

As usual it doesn't make much sense to dig into other author's code (for offsetP, offsetN here) because you're usually faster (but not fast enough) doing own research.

There's offsets logged to the console but I can't make much sense of them atm, guess "Offset vertices" needs to be added to iPos.

edit 2: the FIs were not the problem, I simply had the wrong FVFsize for the half float vertices:

edit 3: this part doesn't use tri strips:

I moved it manually:

 

NICE! All we have left to do is get the bone data from the HGOL chunk I've found something that should make this really easy turns out the documentations (https://github.com/AlubJ/lego-tt-nxg-formats) information about the HGOL chunks is correct for this format version which means we dont have to figure out the HGOL structure by ourselves

[shak-otay]

I moved/placed the head manually:

[marty]

2 hours ago, shak-otay said:

I moved/placed the head manually:

Well without further reverse engineering thats probably as far as we're going to get. Not sure if I wanna mark it as a solution just yet

[shak-otay]

1 hour ago, marty said:

Not sure if I wanna mark it as a solution just yet

It's a workaround only.