Leaderboard

Here is the script if you want to test it. You need to press F4 or the red icon on bottom("Toggle face cull"). fmt_fear_effect_inferno_ps2_rmd.py

I made a Noesis script to read all meshes from .RMD files but the meshes are in the center so we need the skeleton but I don't know how to do that, lol. I used the function "CreateTriList" from other PS2 script(made by leeao), it works fine. This function uses the last 4 bytes of vertices buffer as flag and pad: 12 bytes verts, 1 short flag, 1 short pad. Here is DBULL.RMD but like I said, we need the skeleton:

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

edit: seems instead of experimenting I'd try to get TGE's RMD maxscript, maybe from xentax backup archives edit 2; found Amiticia, but exporting the clump creates no file The bones with parent ids: 0 *jtroot* -1 1 *jtbody* 0 2 *jtwaist* 1 3 *jtchest* 2 4 *jtrshoulder* 3 5 *jtrarm* 4 6 *jtrelbow* 5 7 *jtrwrist* 6 8 *jtrpalm* 7 9 *jtlshoulder* 3 10 *jtlarm* 9 11 *jtlelbow* 10 12 *jtlwrist* 11 13 *jtlpalm* 12 14 *jtneck* 3 15 *jtmouth* 14 16 *jtlip* 15 17 *jtlleg* 1 18 *jtlknee* 17 19 *jtlankle* 18 20 *jtltoe* 19 21 *jtrleg* 1 22 *jtrknee* 21 23 *jtrankle* 22 24 *jtrtoe* 23 floats from the matrices (undefined values replaced by 0.0 0.0 0.0): 0.0 0.0 0.0 jtroot 0.413449 -0.995091 0.495473 0.357034 -0.674350 0.553032 0.982738 -0.695039 0.691009 0.253196 -0.269279 0.291826 0.216968 -0.236668 0.236830 0.0 0.0 0.0 jtrelbow 0.032668 -0.201254 0.164289 0.0 0.0 0.0 jtrpalm 0.253197 -0.269279 0.291826 0.216968 -0.228647 0.236830 -0.044276 -0.264800 0.184460 -0.039168 -0.199243 0.158531 0.0 0.0 0.0 jtlpalm 0.722860 -0.408135 0.387143 0.038753 -0.180144 -0.108344 0.0 0.0 0.0 jelelbow 0.016553 -0.456171 0.428642 -0.045874 -0.276716 0.403431 0.037943 -0.777463 0.348391 0.0 0.0 0.0 jtmouth 0.016552 -0.456171 0.428642 0.0 0.0 0.0 jtlleg 0.037943 -0.777463 0.348391 0.0 0.0 0.0 jtlankle edit: uvs are a little bit weird, as usual:

Those .PS2 files are textures, you can examine those with Console Texture Explorer. I found some info too like width and height, image data offset and palette offset. About .RMD files, these have a lot of submeshes but we need to find a way to collect all. I will try to check that later... Here is texture head0.PS2 from DCHAIR folder:

Hi all! I've been reverse engineering this engine on and off for a while now (specifically the engine for Spy vs Spy 2005). I'm assuming there wasn't major changes over the years, here is some potentially useful info. Custom File Format The game is actually fully programmed in the custom files described above (the engine itself doesn't have any game logic). Custom files are all serialized the same way, which is a series of versioned nested nodes that define objects/fields (in the 2005 engine, there's ~400 object types). The first reference to an object initialized it. These objects are everything from entities, meshes, textures, etc. The raw data often matches a standard format for the console (for xbox: textures are mostly mipmaps of A8/DXT images and audio is ADPCM). To put this in context, here is what you might have to do to go get a texture (assuming the first instance is being referenced by the script that fires when the map loads): .map file -> FileObject - field: object -> MapObject - field: onMapStart -> ScriptNode - field: children -> SpawnActionNode - field: entity -> Entity - field: materials -> Material - field: texture -> Texture - field: color_buffer TL; DR, it's quite hard to reverse engineer the custom file formats without deep understanding of the engine. My Research I made a GitHub org that has all my work: https://github.com/vicious-rebirth Currently, all the repos are private because I'm trying to figure out the best way to release without getting a cease and desist (I think Little Orbit still owns the engine and there's some algos that are patented by MS). This said, I'll try to release my web tool on GitHub page for extracting assets (mileage will vary). I can give read access to anyone interested. Useful Videos Vicious Engine Demo (a good summary of the features from the devs) Vicious Engine Tutorial (a partial series of tutorials of how to use the engine - useful to understand the various types of objects) Extract Model (a preview of a model I extracted for proof)

Railway Empire 2 translation tools and description. Railway Empire 2 Tools.zip

Donated! 5$ not much but it’s always better than nothing!

I have made a Noesis script but it's basic. Just simple mesh export. No materials/ no bones/ no skin. Anyway this is mesh struct. Just basic. //------------------------------------------------ //--- 010 Editor v14.0 Binary Template // // File: // Authors: // Version: // Purpose: // Category: // File Mask: // ID Bytes: // History: //------------------------------------------------ LittleEndian();OutputPaneClear(); local uint32 i,j,k,l,TotalSize=FileSize(); string MeshName; uint32 Unknown_0; uint32 Unknown_1; float Unknown_2[27]; float Unknown_3[5]; uint32 TotalVertexCount; uint32 StrideType; if (StrideType == 19) { byte VertexBuffer[TotalVertexCount*24]; byte ColorBuffer[TotalVertexCount*4]; } else if (StrideType == 23) { byte VertexBuffer[TotalVertexCount*24]; byte UVBuffer[TotalVertexCount*8]; byte ColorBuffer[TotalVertexCount*4]; } uint32 TotalIndexCount; byte IndexBuffer[TotalIndexCount*6]; uint32 ShapeIndex; struct { string MaterialName; uint32 IndexCount; // *3 uint32 Unknown_0; uint32 VertexCount; uint32 Unknown_1; }ShapeInfo[ShapeIndex]<optimize=false>; FSeek(startof(VertexBuffer)); if (StrideType == 19) { struct { float VPosX,VPosY,VPosZ,VNPosX,VNPosY,VNPosZ; }Vertices[TotalVertexCount]<optimize=false>; } else if (StrideType == 23) { struct { float VPosX,VPosY,VPosZ,VNPosX,VNPosY,VNPosZ; }Vertices[TotalVertexCount]<optimize=false>; struct { float UVPosX,UVPosY; }UnitVector[TotalVertexCount]<optimize=false>; } FSeek(startof(IndexBuffer)); for (i=0; i < ShapeIndex; i++) { struct { uint16 F1,F2,F3; }Indices[ShapeInfo[i].IndexCount]<optimize=false>; }

Donated! Thank you all for your great efforts.

//------------------------------------------------ //--- 010 Editor v14.0 Binary Template // // File: // Authors: // Version: // Purpose: // Category: // File Mask: // ID Bytes: // History: //------------------------------------------------ LittleEndian();OutputPaneClear(); local uint32 i,j,k,l,InfoOffset=FileSize(); FSeek(InfoOffset - 20); uint32 CheckSum<format=hex>; // Must be updated after edit > 32 bit LE checksum uint32 TableOffset; // Must be updated after edit uint32 TotalFileSize; // Must be updated after edit uint32 Flag; uint32 Unknown; // Not sure what is for... FSeek(TableOffset); ubyte ResourceCount; struct { ubyte StrLen; char ResourcePath[StrLen]; uint32 ResourceOffset; // Must be updated after edit uint32 ResourceSize; // Must be updated after edit uint32 Null; }ResourceInfo[ResourceCount]<optimize=false>;

Yes, I used VulkanRipper + ShadPS4.

Yeah, but the problem is that the previous maybe positions I found had too many zero vectors. These ones look better - maybe the previous ones are the rotations? edit: yay, that seems to work (without rotations atm), save as cityman1.smd file: version 1 nodes 0 "jtroot" -1 1 "jtbody" 0 2 "jtwaist" 1 3 "jtchest" 2 4 "jtrshoulder" 3 5 "jtrarm" 4 6 "jtrelbow" 5 7 "jtrwrist" 6 8 "jtrpalm" 7 9 "jtlshoulder" 3 10 "jtlarm" 9 11 "jtlelbow" 10 12 "jtlwrist" 11 13 "jtlpalm" 12 14 "jtneck" 3 15 "jtmouth" 14 16 "jtlip" 15 17 "jtlleg" 1 18 "jtlknee" 17 19 "jtlankle" 18 20 "jtltoe" 19 21 "jtrleg" 1 22 "jtrknee" 21 23 "jtrankle" 22 24 "jtrtoe" 23 end skeleton time 0 0 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 1 0.000000 3.300000 0.000000 0.000000 -0.000000 0.000000 2 0.000000 0.402560 -0.178039 0.000000 -0.000000 0.000000 3 0.000000 0.580854 0.078039 0.000000 -0.000000 0.000000 4 -0.400000 0.521687 0.100000 0.000000 -0.000000 0.000000 5 -0.354819 -0.119668 0.000002 0.000000 -0.000000 0.000000 6 -0.059615 -0.945793 0.041228 0.000000 -0.000000 0.000000 7 0.000000 -0.731849 -0.031247 0.000000 -0.000000 0.000000 8 -0.040038 -0.391559 -0.009981 0.000000 -0.000000 0.000000 9 0.400000 0.521687 0.100000 0.000000 -0.000000 0.000000 10 0.354819 -0.119668 -0.000000 0.000000 -0.000000 0.000000 11 0.059615 -0.945796 0.041228 0.000000 -0.000000 0.000000 12 0.000000 -0.731846 -0.031247 0.000000 -0.000000 0.000000 13 0.044455 -0.391561 -0.009981 0.000000 -0.000000 0.000000 14 0.000000 1.055681 0.036543 0.000000 -0.000000 0.000000 15 0.000000 0.060915 -0.159504 0.000000 -0.000000 0.000000 16 0.000000 -0.004216 -0.124180 0.000000 -0.000000 0.000000 17 0.300000 -0.398914 -0.076741 0.000000 -0.000000 0.000000 18 0.000000 -1.214391 -0.019746 0.000000 -0.000000 0.000000 19 -0.000000 -1.312631 0.048992 0.000000 -0.000000 0.000000 20 -0.000000 -0.374064 -0.777951 0.000000 -0.000000 0.000000 21 -0.300000 -0.398914 -0.076741 0.000000 -0.000000 0.000000 22 0.000000 -1.214391 -0.019746 0.000000 -0.000000 0.000000 23 0.000000 -1.312631 0.048992 0.000000 -0.000000 0.000000 24 0.000000 -0.374064 -0.777951 0.000000 -0.000000 0.000000 end

Whoa, I was not expecting that. It seems like they used squashed up low rez version of the game's DMAN (demon man) model as a placeholder for DCHAIR.RMD. As a quick point of reference: Even in this jubled state you can see all of the spikes protruding out of the model. From what I can tell, the .PS2 texture is based on an earlier rendition of the demon man enemy that used a more flat shading style. You can still see this version in the game's pre-rendered cutscenes. If it is of any help, I have attached the game's final DMAN model here as well. These are some pretty great discoveries. @shak-otay @roocker666 Thank you very much for giving it a shot. DMAN.zip

you mean this txt? https://github.com/zbirow/Monster-Jam-Unpack/blob/main/chunk_00000.txt

https://www.mediafire.com/file/waoa38f66z8g89v/AssetRipper_win_x64.zip/file

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

this could be a good idea.But, there must be ppl who are willing to fill the wiki up. I will think of something..

Thanks! Good to know!

on this, you cannot use this script with the latest release of uniloader from github, the API has changed since the IKV script has been written, only version works with it is 0.1.0, which is the one i have provided here and the one OP has shown in his screenshot In addition both the loader and the script have been designed for Blender 4.0+ so there might be issues if you use older versions

Hi I need to find my extractor I have written it a while ago, meanwhile you can just use the resources in the google drive link I gave earlier

I released the latest version (v11.304) now. Just use the Help/Check for updates... function to get it.

Uvs are there just have to bind the right texture!

Never played the game, there was one guy on a discord server that asked for help for this specific game and i decided to help him out Id like to once again credit REDxEYE for his blender addon

UniLoader.zip it was just a matter of unzipping the file renaming the folder within to "UniLoader" and zipping it. Now to install the addon you must compress that .py file in order to be installed

hi use this version of uniloader UniLoader.zip

Joschka from former Xentax? Great to see he's still active. Somewhere. I'm not too familiar with Noesis details. But since it's a very short script it should be doable. I'd insert a print line like so to get the addresses of the bone matrices. bs.readBytes(0x40) print(i, "addr mat", hex(bs.tell())) Basically it's 92 bones (or "joints") with their matrices (rotation and position). You'll need to handle a "matrix 4x4 to a matrix 4x3 transformation" including inversion. From Noesis you could export the skeleton to .smd to see the bones' structure (last number in line is parenting bone id, first bone has no parent, thus -1) : nodes 0 "joint_0" -1 1 "joint_1" 0 2 "joint_2" 1 ... edit: I strongly recommend to start with the positions only and care for the rotations in a second step.

It is from Joschka. By the way, could you please give me a brief explanation of the structure based on the Noesis script? I'm trying to fully understand it so I can make a Blender import script.

Okay, so someone helped me and figured out the skeleton. Here's a Noesis script fmt_spidermanskel.py

hi, i was able to extract older versions of idV and also load entire scenes and recover filenames.

Addon curtesy of REDxEYE __init__.py to be used with https://github.com/REDxEYE/UniLoader and with it there is my audio .raw file converter all the extracted resources can be found here ill link my extractor aswell if i can find it https://drive.google.com/file/d/10uo-DmmpNkiYlogR9eWmIyy74_AfaM05/view Program.zip

Nah no improvements so far and don't think there will be any... from inc_noesis import * import noesis import rapi import os def registerNoesisTypes(): handle = noesis.register("Richard Burns Rally - Geometry", ".mesh") noesis.setHandlerTypeCheck(handle, noepyCheckType) noesis.setHandlerLoadModel(handle, noepyLoadModel) noesis.logPopup() return 1 def noepyCheckType(data): bs = NoeBitStream(data) if len(data) < 20: return 0 return 1 def noepyLoadModel(data, mdlList): bs = NoeBitStream(data) baseName = rapi.getExtensionlessName(rapi.getLocalFileName(rapi.getInputName())) ctx = rapi.rpgCreateContext() Underline = "_" MeshName = bs.readString() Unknown_0 = bs.readUInt() Unknown_1 = bs.readUInt() bs.read(128) TotalVertexCount = bs.readUInt() StrideType = bs.readUInt() if StrideType == 19: VertexBuffer = bs.read(TotalVertexCount * 24) ColorBuffer = bs.read(TotalVertexCount * 4) elif StrideType == 23: VertexBuffer = bs.read(TotalVertexCount * 24) UnitVectorBuffer = bs.read(TotalVertexCount * 8) ColorBuffer = bs.read(TotalVertexCount * 4) TotalIndexCount = bs.readUInt() IndexBufferBaseOffset = bs.tell() bs.read(TotalIndexCount * 6) if StrideType == 19: rapi.rpgBindPositionBufferOfs(VertexBuffer, noesis.RPGEODATA_FLOAT, 24, 0) rapi.rpgBindNormalBufferOfs(VertexBuffer, noesis.RPGEODATA_FLOAT, 24, 12) elif StrideType == 23: rapi.rpgBindPositionBufferOfs(VertexBuffer, noesis.RPGEODATA_FLOAT, 24, 0) rapi.rpgBindNormalBufferOfs(VertexBuffer, noesis.RPGEODATA_FLOAT, 24, 12) rapi.rpgBindUV1BufferOfs(UnitVectorBuffer, noesis.RPGEODATA_FLOAT, 8, 0) ShapeIndex = bs.readUInt() IndexCountList = [] MaterialNameList = [] for i in range(0, ShapeIndex): MaterialNameList.append(bs.readString()) IndexCountList.append(bs.readUInt()*3) Unknown_0 = bs.readUInt() VertexCount = bs.readUInt() Unknown_1 = bs.readUInt() bs.seek(IndexBufferBaseOffset, NOESEEK_ABS) for i in range(0, ShapeIndex): IndexCount = IndexCountList[i] MaterialName = MaterialNameList[i] IndexBuffer = bs.read(IndexCount * 2) ShapeIdDigfmt = "{:04d}".format(i) rapi.rpgSetName(MeshName + Underline + ShapeIdDigfmt) #rapi.rpgSetMaterial(MaterialName) rapi.rpgCommitTriangles(IndexBuffer, noesis.RPGEODATA_USHORT, IndexCount, noesis.RPGEO_TRIANGLE) mdl = rapi.rpgConstructModel() mdlList.append(mdl) return 1 You can try on your own 😉

Edit 1: Yes read bone palette is part of the script but i am not sure what they are actually and if they get read or not by the script Edit 2: Added Importer Script SMWOS_MESH_Importer (2) (3).py

I apologize, here is an alt link: https://mega.nz/file/vBFxUK6B#0NrhJzeX_iRFlzDK8hq6ymTW1bLe6723_l-jJ12EIUM

Faces are simple for the mentioned mechanics:

Wasn't able to donate much at all, but something is better than nothing! I hope you guys keep holding on, you have a truly indispensable skillset here.

Hello, I have a déjà vue that I saw this "dragon" on former xentax years ago (ID_EPIK_EJDER.dec) :

Struct of SGS/SGC is pretty much same... Here's some info... //------------------------------------------------ //--- 010 Editor v14.0 Binary Template // // File: // Authors: // Version: // Purpose: // Category: // File Mask: // ID Bytes: // History: //------------------------------------------------ LittleEndian();OutputPaneClear(); local uint32 i,j,k,l,TotalSize=FileSize(); string Sign; struct { do { struct { uint32 ResourceSign; enum <uint32> { Mesh = 0, Bone = 3, Material = 5, MaterialEffect = 15, Skeleton = 18, }ResourceType; uint32 Unknown_2; uint32 Unknown_3; uint32 ResourceSize; local uint32 ResourceInfoEndOffset=FTell(); byte ResourceData[ResourceSize]; local uint32 cPos=FTell(); }ResourceInfo; } while (ResourceInfo.ResourceSign == 12 & ResourceInfo.cPos != TotalSize); }ResourceTable; EDiT: Now you can dump it with this bms script. ################################### get BaseFileName basename get FileSize asize get Sign string do get ResourceSign uint32 get ResourceType uint32 get Unknown_2 uint32 get Unknown_3 uint32 get ResourceSize uint32 savepos ResourceOffset getdstring ResourceData ResourceSize savepos cPos if ResourceType == 0 set Extension string "mesh" elif ResourceType == 3 set Extension string "bone" elif ResourceType == 5 set Extension string "material" elif ResourceType == 15 set Extension string "materialEffect" elif ResourceType == 18 set Extension string "skeleton" else set Extension uint32 ResourceType endif string FileName p= "%s/%u.%s" BaseFileName ResourceOffset Extension log FileName ResourceOffset ResourceSize while ResourceSign == 12 & cPos != FileSize

"stride" (or FVFsize in hex2obj) is a multiple of 4 for float based formats. Using vertex start address 0x3f94 (type in 3f94 without the 0x) for mechanic-1-4_01.sgs and trying 12 in a first step and pressing the go2 button you'll see "NORM" in each 2nd line in the lower left window. This means the FVFsize is 24 in this case. The vertexcount is calculated automatically (see lower left window) after pressing the go1 button. Provided you set the correct start address and FI count of the FI block. That's just a matter of experience. Or simply divide sizeOfVertex block by FVFsize. Works in most cases.

Char mesh format looks simple. For the skeleton you could try use Durik's skelfinder, read two posts here.

Dunno. If I had known the cars have already been reversed I'd checked the character SGS instead.

Low poly models usually don't raise that big interest but the mesh format shouldn't be a big obstacle, or should it? edit: didn't know whether triangle strips is the best choice here. Saved with normal triangles, drag&dropped it onto Noesis, F4 for backface culling, doesn't look much worse, imho. But after reviewing I'd suggest using strips.

You can download it online. You can use shadps4-win64-qt-0.7.0 to unpack PKG files. Or use fake pkg to unpack pkg files. With PS4, you need the sys_modules folder you need to run shadps4.

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

offset = bs.readUInt() + 0x20 bs.seek(offset, NOESEEK_ABS)

I opened the solid.mp file succesfully.

https://github.com/Ekey/BW.WPK.Tool

Some stuff for Insomniac game engine - https://github.com/team-waldo

Nice description. (Level) mesh format appears to be simple: Complete Level 1 seems to contain doubles (or whatever). See lower part of 2nd pic (not fully exploded). edit: I see. Parts overlap because rotation is missing.