Leaderboard

I'm still looking into the bones, trying to get them working correctly. The ones that don't work correctly yet are the models with over 256 bones, such as the one below. The vertex data only uses bytes for the indices, so it has to remap the bones into smaller groups of 0-255. They could have just used Shorts for the indices and it would have been no problem. Had a bit of success with some bones being remapped correctly, but others still not. It seems like some bones maybe aren't needed, or are used for something else. This is pl036 with some bones being moved correctly.

I'm going to do tools for it, and release it here on reshax. I plan to support characters and maps, like it was before with FF7 remake.

First release:

Good news. Issues with missing objects and incorrect normals were fixed. Now tool is really close to release.

Did some first tests.

I'm working on a set of tools for Dragon Age Veilguard. So far, i have dump tool to extract all files, all models can be converted. Also i have fixed the usual frostbite distorted faces. Now checking if something needs to be done with unified skeleton or textures, and then tools will be published here.

From further investigation, it seems that some meshes use up to 8 bone weights/indices, where others only use 4. It also looks like they're split into 2 groups of 4 in the vertex data - i.e 4 weights/4 indices/2nd set of 4 weights/2nd set of 4 indices. So I'll need to redo the way bones are processed to see if that fixes it.

I'm looking at the textures/materials now, trying to allocate them properly. Just a few tests so far:

Its getting there, I have more objects placed now. But still not all.

Adding materials... thats probably last thing its missing before release

Things are getting better. Almost everything is in place now.

Tool v1.2 posted. Work is not finished, i'm looking into getting custom characters now. Also maybe i can get real hairs later. Textures not supported yet, but they can be extracted with tools for other frostbite games.

I made an importer that import every tmd2 model correctly. it can read models with more than 255 bones, all uv layers, all vertex color layers, tangents, binormals, both sets of normals, etc... https://www.nexusmods.com/bleachrebirthofsouls/mods/63

Okay, here's a little bit of an update. I've added support for all the vertex types, and the textures should all load correctly now. I've also included the extra UVs where available, although they're not presently used. The bones are still messed up in a lot of cases, so that still needs some work. The materials also need more work. I've disabled the vertex colours for now as that was messing up a lot of the meshes as well. bleach_rebirth_tmd2.zip

Tool released. Its an early version (as usual), but already makes very good results.

I Finally got materials and textures to load dynamically, so far only works on Conker will have to work in some tweaks to support other models

Hello. I would like to share with you my private tutorial links collection. These are useful topics from Xentax, Zenhax and any other reverse engineering related sites that I was able to find in the Internet. I have put them into categories. You may encounter situation when one tutorial fits to few categories, but it is placed only in the category that it fits most. Also, you may encounter tutorials with "[PL]" mark, these are tuts in Polish language. If you don't understand this language, just skip them. Also be aware that I haven't read/watch some of these tutorials yet, so I can't recommend you which tutorial is the best choice, sometimes I'm still learning new things just like you and on this list you may find tuts that are not very useful for you, so don't blame me for that. 🙂 Just pick your favourite category and start learning. If you are complete newbie, I would recommend to start with tuts from category "Basic knowledge". If you have any other good source of knowledge, you can write a comment below and I will update this tutorials collection. Also remember that those links may be dead some day, so don't blame me for that and just make a copy for private use 🙂 So that's it. Enjoy. 😄 Links to tutorials: Basic knowledge (you should start with these if you are new to reverse engineering) - Definitive Guide To Exploring File Formats - Beginner Learning Materials on Reverse Engineering Video Games - What is a File Format? - Analyzing and Reverse Engineering a Game Archive - Key points to successful hex reading - Overview of game file formats and archives - REWiki - Reverse engineering hints - HOWTO-Reverse Engineering QuickBMS - [TUTORIAL] What is QuickBMS? How to export and import with QuickBMS? - QUICKBMS GUIDE - QUICKBMS GUIDE 2 ZLIB - QUICKBMS GUIDE 3 IF ELSE - Basic BMS Scripting - QuickBMS documentation - QuickBMS crc engine - QuickBMS - Reimporting files in the archives - QuickBMS - Scan all the supported compressions - Example of archive format reversing with QuickBMS (medium) - Practice with archives and quickbms scripts - [TUTORIAL] Making BMS Scripts MultiEx scripting - MultiEx Commander Manual - MultiEx Commander 4.5 YouTube tutorials - MexScript Documentation - Let's MultiEx Encryption tutorials - How to guess basic obfuscations: xor and sum/rot - Reverse simple decryption - Reversing AES Keys UE4 + AES Keys Collection - How To Get PAK RSA Key (Wolcen / CryEngine Games) - Retrieving ZIP passwords from games - the zero skills way - Retrieving ZIP passwords from games - the debugger way - Retrieving ZIP passwords from games using plain-text attack - Hacking Zip Passwords (C9) - Checksum / CRC scanning - Decrypt any vita game (no custom firmware needed) - How Unpack Themida 2.x.x or How Unpack Themida 2.x.x (WXP) - SM Hasher / Murmur3 hash + Wiki + Python implementation - LCG + sources + Cracking LCG + LCG in VC2 - Decrypt unity 3d files with Frida - [Tutorial] How to get Allegro passwords Hash tutorials - [Tutorial] How to restore hashed filenames from archives Compression tutorials - How to recognize the compression algorithms with your eyes - LZMA SDK (binaries + source code + specification) + LZMA Wiki - Bc7 and bc5 decompression and compression - Offzip - deflate/zlib scanning and extraction - ZSTD compression + documentation - Reverse Engineered old Compression Algorithm for Frogger - Oodle Data Compression + Oodle compressor + Oodle wiki page - RLE Compression explained + RLE Wiki + RLE in Python - LZ77 explained + LZ77 encoding + LZ77 decoding + LZ77 in Python - LZSS Compression + LZSS explained - LZ Compression + Open-source LZ Compressors Debugging / Decompilation / Disassembling - Lenas Reversing for Newbies - Reversing Spider-Man 2000 - Real World Decompilation with IDA Pro - IDAPython conditional breakpoints - The Beginner's Guide to IDAPython - Using IDAPython to Make Your Life Easier Part1 + Part 2 + Part 3 - Reverse Engineering with Ghidra - How to Reverse Engineer with IDA Pro Disassembler - How to reverse engineer functions - Debugging “Dust: A Tale of the Wired West” - Reverse Engineering Dust: Uncovering Game Scripts - Reverse Engineering an Xbox360 Game - Reverse engineering C programs - bin 0x10 - Memory Hacking — External Signature/Pattern Scanning Tutorial - Remote Debugging with IDA Pro (Windows) + Connecting host with VirtualBox - Remote Debugging with IDA Pro (Linux) - Basic IDA Python Scripting Hooking / DLL Injection - Simple C++ DLL Injector Source Code Tutorial - Quick and EZ - Dll Injection Explained (how it works + source code) - Manual Mapping DLL Injection Tutorial - Blizzhackers DLL Injection - API Hooking and DLL Injection on Windows - [PL]ReverseCraft #7 - Inline hooks, DLL injection - [PL]DLL INjection by Maciej Pakulski (PDF) - C++ Detour / Hooking Function Tutorial - [Tutorial] The different ways of hooking - API Hooking with MS Detours + MS Detours 4.0.1 description + source - Hooking tutorials - Inline hooking in Windows - C++ Internal Trampoline Hook Tutorial - OpenGL Hook - MinHook - The Minimalistic x86/x64 API Hooking Library + source on github - DLL Hijacking - [Tutorial] Simplest function hooking with IDA, Detours & C++ - [Tutorial] DetourFunction __thiscall - How to Hook Functions - Code Detouring Guide - Resources About Hooking - [Tutorial] Hooking Java Functions - [TUTORIAL] Hooking Android bytecode with Frida Console Tutorials - PS2 Texture Swizzling - PS1 LibCrypt tutorial + LibCrypt Sectors Mappings + LibCrypt Bible - Gears: A look Inside the Final Fantasy VII Game Engine - Convert Ps3 to Debug 4.21 - Extract Samples and MIDI files from Square PS2 Games - Extracting Xbox 360 game files - Reverse Engineering Xbox360 SaveGame (Dead Space) - Extract + Decrypt 3ds Roms - [HOW-TO] Assembling 3DS Homebrew for Gateway - [Tutorial] How to Decrypt, Extract & Rebuild 3DS|CIA|CXI Files - PS2 Hidden files + this + this + this + IsoBuster + Ratchet and Clank PS2 discoveries + Ratchet and Clank Hidden files extractor + this - PS2 Modding Tutorials + PS2 Modding Tools + PS2 AIO Project - [TUTORIAL] [PS2DEV] An Introduction to PS2DEV and it's History - Racing Lagoon Hacking Deep Dive (Translating PS1 games - tutorial) DOS Tutorials - DOS games reverse engineering guide - DOS file formats / encryptions / compressions etc. - DOS game "Nomad" (1993) documentation and tools Audio - The basics of VGM ripping + VGM Ripping Tools - Common Sound Formats - How to scan audio codecs with ffmpeg - Tutorial on vg-resource - Extract Binary Domain's Music/Sound (CRI .cpk bgm) - Batman Arkham Knight - Extract Soundtrack - Multimedia Wiki (Audio, Video, Codecs) - TXTH files documentation Graphics - Finding graphics - Graphics/Texture finders and viewers - Xentax Wiki - Image file formats - Tutorial : How to edit EA's FIFA PS2 TEXTURE Source code + documentation - PS1 BRender Engine (Harry Potter 1, Harry Potter 2 etc.) - PS1 BuggyBunny (Bugs Bunny) - Python Tools Collection - KAO2_PAK + documentation - J2ME game Stalker - Soul Calibur 3 Reversing Books - Reverse Engineering for Beginners + Reverse Engineering challenges + Compiler Explorer - Game Hacking: Developing Autonomous Bots for Online Games - Reversing: Secrets of Reverse Engineering - The IDA Pro Book, 2nd Edition: The Unofficial Guide to the World's Most Popular Disassembler - Mastering Reverse Engineering - Practical Reverse Engineering - [PL]Gynvael Coldwind Praktyczna inżynieria wsteczna - [PL]Asembler. Sztuka programowania 3D Models - Approaches of Parsing Bone Representations - Noesis tutorial Basic Model - Video tutorials on model formats reversing - Make_obj (C source) - Extracting simple models - Analyzing and Extracting a Game Model - [Tutorial] How to extract bones from any games with Noesis - Sanae3D - 3D format converter - Background Knowledge of Bone Stuffs - Extract 3D models from binary files - Writing an Obj Convertor in C - [crash course] How to get multiple submeshes using Make_H2O - Very Basic model format conversion (Shaiya). - INTEL GPA mesh ripper tutorial + tool (x32,x64,DX9,10,11) - 3ds Ram Dump - [Tutorial] Exploring model formats: 9 Dragon - Noesis tutorial Zlib - Video tutorial on full model format reversing (Planetside) krystalgamer's Lair - Marvel Avengers - Writing a server emulator - Spider-Man 2000 - Save file protection - Spider-Man 2000 - Re-enabling a cheat code - Spider-Man 2000 - Save file content exploration - Spider-Man 2000 - PKR Format - Spider-Man 2000 - Custom File Loader - Spider-Man 2000 - Apple to the Rescue! Mobile (Android, iOS, J2ME) - OWASP guide - OWASP guide crackmes source code (Warning! Big spoilers!) - Beginners Guide to Reverse Engineering Android Apps - [Android] Decrypt unity 3d files with Frida - Mobile Game Asset Download - [PL]Reverse engineering mobile app (Niebezpiecznik) - J2ME Reverse Engineering Capture The Flag - Solving CTF Challenges Part1 and Part 2 - [PL]Capture the flag Tutorials playlist Other - The Ultimate Game Hacking Resource - Low-Level Programming University - 1024bar tutorial - [PL]ReverseCraft blog and ReverseCraft playlist - [PL/ENG]Modding tutorials - UE4 games texture replace - nullsecurity.org - crackmes.one - RCE Tools Library - GHB1 - Start Here Beginner Guide to Game Hacking - Ripping Tutorials - Searching text strings using Total Commander

I'm working on a tool to modify existing models or import custom models into Horizon Forbidden West. So far my first test is to fix Aloy's face. I tried a few options, and now I'm sure it will work and looks good, and probably a few mods will be already released soon. Then after import tool is ready, it will be release here on reshax. Here are some example screens. First i reduced her cheeks to 70%, to be sure i can see difference. Since only face shape is changed, you can see the old "fat" shape of peachfuzz (which is not scaled down yet). And then i did 90%

I'm going to update my PS4 tool for this game to support PC remaster. Maybe it will only be some small change.

please update the script ! if you would be so kind.

Currently testing map objects placing. Not ready yet, but hopefully soon.

Got staticmeshes working, now time to place them on a map.

Due to a user's request I upload the script of Mariusz Szkaradek here (because I didn't find the link any more). All kudos go to Mariusz. Important! For Windows 7 and higher it's required to copy the newGameLib folder into the blender 2.49b root directory. And no, it doesn't work with newer blender versions. Blender249[WatchDogs][PC][xbg][2014-10-25].zip

ImageHeat Download --> https://github.com/bartlomiejduda/ImageHeat

sorry for the radio silence; when Lake House fully arrives along with the QOL update tomorrow i'll make an update to the script (eta tbd) that'll have updated offsets for hopefully all previously supported models (and new ones if applicable).

Looking to see if anyone is interested in this, 3D models/geometry isn't exactly my strongest skillset (which I'm sure you will soon notice). I was originally inspired by an old thread on Xentax for other Rareware games (primarily Grabbed by the Ghoulies) however Live and Reloaded seemed to get skipped over since no one could figure out the compression the game was using. Fast forward a few years and i learned that Xemu had a debugging feature with support for IDA which is a tool I'm fairly familiar with, using this i was able to extract the x86 assembly instructions the game uses to decompress the game assets and write a wrapper for it allowing me to unpack the files to a state similar to what's used in other Rareware titles. You can check out that tool here: https://github.com/birdytsc/clr_unpack I'm currently in the process of reversing the games model format but my limited experience with 3d models/formats is hindering my progress. While some of the data is pretty straightforward to obtain some are packed away in pushbuffer instructions, one example is the tri's/faces data: This makes it a little more annoying to tell what set of vertexes they belong to but they are (so far) stored in order that you will find any vertex data one problem i am having is im not sure whether im extracting the data properly, example: the first part for conkers main model is broken into 3 sets of triangles all sharing a single set of vertexes, uv's etc. the model only looks correct if i separate the 3 sets of tri's into there own mesh, keeping them together creates artifacts: Another issue im having is Texture alignment, the game stores the textures as raw DXT data (usually DXT1 or DXT5) even in simpler models that only consist of a single set of triangles im still having alignment issues, for example: Perhaps this is a sign that there is indeed an issue with how im extracting the Tri's? If anyone wants to play around with this stuff ive included some files in the zip: aid_bfdmodel_characters_conker.py - a script for ModelResearcherPro that will load the verts/tris for the main conker model retail_aid_zpackage_general_singleplayer.rbm.listfile.csv - list of file names (if they havnt been stripped from the asset packer) and offsets retail_aid_zpackage_general_singleplayer.rbm.unpacked - just the decompressed version of the file found in the retail game retail_aid_zpackage_general_singleplayer.rbm.unpacked.mapped - same file as above but after its had a bunch of pointers mapped, useful for diffing against the original to find pointers. retail_aid_zpackage_general_singleplayer.rbm.unpacked.mapped.hexpat - imhex pattern file for the previous file. conker_stuff.zip

There are at least two types of i3d file formats, used within the .i3d files used in ape escape 3 and Rule of Rose uses .i3d files in .mdl files. I3D_BIN: Mesh ✔️ Bones ✔️ Skin ❌ I3D_I3M: Animation ❌ Tools: https://github.com/Durik256/Noesis-Plugins/blob/master/fmt_i3dg.py - Supports meshes. fmt_RuleOfRose_PS2__i3d.zip - Supports bones (made by Bigchillghost from xentax, reuploaded into reshax for quicker accessibility)

I forgot all about this thread, I have skin weights imported, and level support

Hi, it was brought to my attention that the Beta xbox version has additional outfits that the PC version does not have. The models are in a different format, namely .xgg - Which is slightly similar to the pc version. The ps2 version is also in a different format .pgg - However I won't be looking at this at the moment. I created a script for the character models, it probably won't work for terrain or objects. At this stage I am not going to expand on it further or create a new thread as it is the same game. XGG_convert.py

Mod released: https://www.nexusmods.com/horizonforbiddenwest/mods/113

Yes, but it's still in progress, not ready to upload it yet while I iron out a few issues.

Here's an initial Noesis script for the TMD2 mesh files. I've probably made some assumptions with the format, so I don't know if it'll work for other tmd2 files that I don't have samples for. It doesn't load the textures/materials as yet, mainly because I'm not 100% sure on how they're referenced, but it will do vertex colours and the bones should also work. bleach_rebirth_tmd2.zip

Yeah, original scripts don't seem to account for all of the different vertex formats, so a lot of meshes won't work. I can get the skeleton working by doing some manual extracting of the data. I'm not sure if the original script author(s) will update theirs. If not, I may do an updated one at some point.

Is there a specific file you're having trouble with inside that archive? These appear quite similar. e.g. 0000000000000000_unpack.seg is uncompressed 8-bpp indexed pixels 512x1024 starting at 1600h and a palette at 200h. (you'll have to tell me if the red and blue channels are reversed, since you've played the game)

Tools for Spider-Man 2 PC port will be released here. Right now main priority is model export/import. Usage will be very similar to Spider-Man 1 import tool. Tool already works, but has some restrictions. And these restrictions are different from SM1. For example, there is no more limit for number of bones, which means any model can be imported, including any head model, or spiderman mask. Another example is that lookgroups now have more complex layout, which is not supported yet. Second UV channel not supported now, but will be added soon.

Lot of great work being done in this thread, I've done a Lot of IDV extracting with the old QuickBMS scripts initially shared around on Xentax, and thankfully was able to back up all the files from before the new engine update, and have been extracting from those. But there's quite a lot of skins I'd like to extract to use in animations, and the old script doesn't work obviously. Thanks to everyone for their hard work in here. I've not seen the NeoXtractor before, but it seems really good, and hella helpful! Thank you for sharing it! I'm hoping to see more updates to NeoXtractor though, as it seems a lot easier and better to use just one app, to view the .npk, rather than having to decompile the entire thing, and then blindly browsing via RMA, which is what I have been doing this entire time. (I don't know how most people here get their textures, but I just use Ninjaripper 2 to extract them from the game whenever I find a model to use, as the textures are All over the place when extracted from the .npks..) Also, TeaEffTeu I've seen you around a few times and matched with you a few times recently on tha NA server! I always thought your name was fun, but I had no idea you were up to all this in the IDV community. Thanks for contributing to this, it's a huge thing for me, as someone who is a 3D animator and artist, being able to extract the models to use in Blender and such is not only fun, but just really cool. Thanks for contributing to that! Small world lol I remember altering my old BMS script in the past to kinda work when they made the new-ish .npk format after Fools Gold came out, but a better edit came along from someone else soon after. I'll make sure to share any helpful info I can involving the BMS scripts, or just the file formats in general. Thanks once again to everyone helping with this process! ^^

Thank @Franco for help me test importing text into gameresources_patch1_pc2.resources. It will be completed at least by next week or later.

My job is not to do YOUR work. My comment is for other people so they don't have the hope for something that not exist

accumulate rotations

Yes, unified skeletons needed a fix. Now its better.

N64 logo and Rareware logo work aswell, forgot to test them

Hello, I've got some examples of some game engine files from the proprietary game engine used to make the BIT.TRIP games, a series Wiiware games made in the early 2010's. Almost all files contained in the attached file have file types that start with ".ae", followed up by a couple extra letters for each file type. There seem to be three notable exceptions to this. Firstly, all sound files are stored as .OGG's, and can be opened normally. These files contain everything from sound effects, cutscene audio, and the soundtracks used in game. Another file type that breaks the ".ae" convention are the .collision files. One of these files exist for each level, and each one varies greatly in size. Despite the odd file type, the contents can be viewed normally through a basic text editor. Each file contains a series of decimal values, each one being separated by a comma. An observation that gives insight as to what these files do is that levels 1 and 2, 3 and 4, and 5 and 6 each have similar sized .collision files (i.e, levels 1 and 2 have collision file sizes of 22KB and 18KB, whereas levels 3 and 4 have collision file sizes of 9KB and 4KB). Each pair of levels share a similar theme, and each theme has varying levels of obstacles that cannot be fired through. Levels 3 and 4 both lack obstacles for the most part, whereas the other four levels all have numerous obstacles throughout. Therefore, it's likely that these decimal values each map to the hitbox of the obstacles placed throughout the levels. the final deviation from convention is the .vs folder under the FATE/Hell/Layouts file path. this contains various json files along with other file types that I haven't seen before (what on earth is the file at the bottom of the FATE/Hell/Layouts/.vs/Layouts/FileContentIndex?) The remainder of these file types, as stated prior, are files made by the proprietary game engine used to make this game. Viewing and modifying these files are restricted to bitwise modifications via hex editors, and are much harder to modify without breaking things. That being said, the names of each .ae file betray their probable purposes. .aetex files store 2D texture information. most of these files are under the "Textures2D" folder. .aescn files store a variety of 2D and 3D objects. these files are stored throughout the whole game. These are used for the cutscenes, level backgrounds, player 2D models and animations, and all of the 3D models in the game. .aemenu files store information about the game menus, including those that display the final score for a level, the level select menu, and the startup menu. Interestingly, the GAME OVER screen is stored as an .aescn file, and not an .aemenu file, which explains how the player isn't booted back to the menu upon defeat in game, but instead is sent back to the start of the level. the .aeefx file type only appears one time under the Effects directory. the file "General.aeefx" doesn't have any obvious hints as to what it might contain (beyond the obvious "it contains game effects" observation). An interesting thing to notice is that the games files are split between two directories, a "General" directory and a directory called "Hell". The BIT.TRIP series released six games on wii ware, each of them having multiple instances of shared assets throughout. the "General" directory contains those reused assets, whereas "Hell" contains the assets from this particular BIT.TRIP title. Underneath the "General" directory is another file type labeled as .aeshader, which contains (you guessed it) shaders. Though these files are stored under the "Shaders" directory, the names attached to the .aeshader files makes it difficult to gauge what each file governs exactly. Lastly, the fonts used for this game are stored in .aefnt files. three of these files exist, with the difference between the three being unclear. I've attached some examples of the game engine files for those that wanna mess around with them, have fun and make friends! AtrophyGameEngineFileTypes.zip

No updated as yet. Haven't looked at it for a few days, but I'll have another look at it soon and upload an updated script.

Still working on materials. Diffuse/Normal maps look ok. But still quite a way to go.

You can use this Noesis script to get the textures from the LDS files. Not sure how the textures are integrated into the materials to allocate to individual submeshes. rebirth_lds.zip

tm2 and lds its zlib lds after unpack (dds texture) tm2 after unpack (3d model) structure: 8 bytes magic(PZZEtmd2) uint decSize uint zero uint ofsData uint zero bytes* comData EDIT: i made qbms script BLEACH_TM2_LDS.bms

Can you please explain your question more clearly as you've mentioned several unrelated things in one sentence.

https://github.com/rzhumen88/ptd-unpacker file was obfuscated, now it can be unpacked into other archives

All tools will be posted soon. Maybe even today. Making some final changes.

Hi I hope this helps, please use it in conjunction with the script if anything is unclear in either. I got lazy in some parts of the script. Documentation for WGG files: Header - 88 Bytes (All pointers and offsets always starts after the header) 8 Bytes - Magic(HVSIWGG) 4 Bytes - Version1, Always 2 4 Bytes - Version2, Always 13 4 Bytes - EndOffset, also Filesize 8 Bytes - Object Separator, used to separate objects in file 4 Bytes - Last Chunk Pointer 4 Bytes - Unknown, usually 0 4 Bytes - Amount of Tables 4 Bytes - Size of object list 4 Bytes - Number of Vertex Chunks 4 Bytes - Pointer to start of vertex information 4 Bytes - Number of Face Chunks 4 Bytes - Pointer to start of face information 4 Bytes - Number of vertex chunks with no face information, called "Positional Chunk" herein 4 Bytes - Face EndOffset 4 Bytes - Size of Last chunk to EndOffset 4 Bytes - Unknown, might be pointer to start of object list, always 0 4 Bytes - Size of "Unique Face data" 4 Bytes - Size of "Unique Face data" and "Unique Transformation Data" 4 Bytes - Size of unlisted chunk, mostly unused 4 Bytes - Size of Last chunk(Duplicate) Object List:(For each 16 bytes in "Size of object list") 8 Bytes - Object Name 8 Bytes - Object Separator Tables:(For each "Amount of Tables") Table Header: (24 Bytes) 4 Bytes - Number of entries in table 4 Bytes - Size of "Unique Face data" in objects 4 Bytes - Number of objects 8 Bytes - Name of table 4 Bytes - Size of "Unique Transformation Data" in objects Table Data:(40 Bytes - For each "Number of entries in table") 4 Bytes - Number of the Vertex chunk containing data 4 Bytes - Number of the Face chunk containing data 4 Bytes - Number of the Positional chunk containing data 4 Bytes - Number of vertices to skip in vertex chunk 4 Bytes - Number of faces to skip in face chunk 4 Bytes - Size of faces in object 2 Bytes - Unknown 2 Bytes - Number of vertices in object 2 Bytes - Unknown 2 Bytes - Which object from object list does this table belong to 2 Bytes - Number of faces in object 2 Bytes - Unknown 2 Bytes - Unknown 2 Bytes - Unknown Vertex Chunk:(For each "Number of Vertex Chunks") Header:(60 Bytes) 4 Bytes - Type of Vertex Chunk, 0 Normal, 4 Split, or 8 Transformational 4 Bytes - Count of vertex entries 4 Bytes - Flags, 80 = only vertices, A0 = Vertices and UV's, A8 = Vertices, normals and UV's 4 Bytes - Unknown 2 Bytes - Unknown 2 Bytes - Unknown 4 Bytes - Unknown 4 Bytes - Unknown 4 Bytes - Unknown 2 Bytes - Unknown 2 Bytes - Unknown 4 Bytes - Unknown Float 4 Bytes - Unknown Float 4 Bytes - Unknown Float 2 Bytes - Unknown 2 Bytes - Unknown 4 Bytes - Unknown 4 Bytes - Size of vertex entries Data:(For length of "Size of vertex entries*Count of vertex entries" either 12,16,20,24,32,36, or 40) 12 Bytes (3 Floats)= Contains only vertices * Count of vertex entries 16 Bytes (4 Floats)= Contains vertices and extra unknown float * Count of vertex entries 20 Bytes (5 Floats)= Contains vertices and UVs * Count of vertex entries 24 Bytes (6 Floats)= Contains vertices and extra unknown float and UVs * Count of vertex entries 32 Bytes (8 Floats)= Contains vertices and normals and UVs * Count of vertex entries 36 Bytes (9 Floats)= Contains vertices and extra unknown float and normals and UVs * Count of vertex entries 40 Bytes (10 Floats)= Contains vertices and two extra unknown floats and normals and UVs * Count of vertex entries Face Chunk:(For each "Number of Face Chunks") Header:(8 Bytes) 4 Bytes - unknown 4 Bytes - Size of face information Data:(For length of "Size of face information") 6 Bytes - face 1, 2 and 3 each 2 Bytes * ("Size of face information"/3) Positional Chunk:(For each "Number of Positional Chunks") - Unlike other chunks, all headers are together, no data is between them. Header:(72 Bytes) 4 Bytes - Count of entries 4 Bytes - Unknown 4 Bytes - Unknown 4 Bytes - Unknown 4 Bytes - Unknown 4 Bytes - Unknown 4 Bytes - Unknown 4 Bytes - Unknown 4 Bytes - Unknown float 4 Bytes - Unknown float 4 Bytes - Unknown 4 Bytes - Unknown 4 Bytes - Unknown 4 Bytes - Unknown float 4 Bytes - Unknown float 4 Bytes - Unknown float 4 Bytes - Size of entries 4 Bytes - Unknown Data:(Size = "Size of entries*Count of entries" Always starts at "Last Chunk Pointer") 12 Bytes (3 Floats)= Contains only vertices * Count of entries If the vertex chunk has a 4 or 8 in first 4 Bytes then a large portion of the file is dedicated to "strange" face and transformational data, called "Unique" herein, there is never more than 1. Sometimes with 4 you can extract the data from the usuall route through the tables, but 8 never has table data accompanying the header. If the "Unique Face data" or "Unique Transformation Data" has a value other than 0 then it is referring to this chunks data. The data starts at "Last Chunk Pointer", for the length of "Size of "Unique Face data"", what is odd is that it contains duplicates. Face Data(Count = "Size of "Unique Face data"/16): 4 Bytes - Face 1 4 Bytes - Face 2 4 Bytes - Face 3 2 Bytes - Unknown(Seemed like a index number from object list, but that is untrue for some/most files, unless some weird logix applys) 1 Bytes - Unknown 1 Bytes - Unknown After the face data is "Unique Transformation Data", it is used for normal data in the script, but this is wrong as some of the chunks that start with 4 have normal data in the vertex chunk. Transformation Data: 4 Bytes - Unknown float 4 Bytes - Unknown float 4 Bytes - Unknown float 4 Bytes - Unknown float 4 Bytes - Index number for face data 4 Bytes - Unknown 4 Bytes - Index number for other transformation data or 0xFFFFFFFF 4 Bytes - Index number for next transformation data or 0xFFFFFFFF Filling in any unknown data would be awesome, and very much appreciated, though I am pretty much finished with this project. I am attaching all the files I have hereto. WGG Sample.zip WGG_convert - Final.py