Leaderboard

I have released an early version of the tool that can do just meshes with their material names/skeleton:

Actually the LZSS provide above, is wrong, for the files. I did the reverse enginner of the algorithim, Try the tool, see if the image get right TenchuWoH_DeCompressor.zip

I'm trying my best to make it load somehow

models.zip Here's the map FBX files I got.

Let's just say Im remaking a certain game. But in VR

I am updating the Noesis script from this post to handle more versions of the 3D model rsf format. Soon I will release an update to the script. Meanwhile, as a sample, I want to show some extracted models that we were not able to extract with the old script. On the top left corner we find the Orange Bowl stadium from NCAA 08. On the top right corner we see the hologram (a ficticious one) stadium from Madden 13. The low left corner shows the LA Memorial Coliseum from Madden 12 or 13 and finally on the low right corner we find the Louisiana Tech stadium from NCAA 12. All these rsf files come from the PS3 versions of the games with data in big endian. The script can handle data in little endian too, for example rsf files coming from PS Vita games. I am almost 100% sure that the updated script will be able to handle rsf files from NCAA 08 to NCAA 14 and Madden 07 to Madden 17 with no issues.

In the ..var01.st2 csv data is contained: edit: and xml data: <!-- ______________________________________________________________________________ Copyright 2004 The Collective, Inc. DISMEMBERMENT DEFINITION Character: Clone Trooper Author: Baback Elmieh Date: 01/07/2004 ______________________________________________________________________________ --> <!-- HEAD --> <DismemberablePart Name="Head" Hitpoints="25"> <!-- The Materials section is a list of materials in the original mesh that are to be turned off when the part is dismembered --> <!-- <Materials> <Material Name="headSG"/> </Materials> --> <!-- ReactionProcessing defines the chunks and particles to be spawned when a reaction dismemberment is processed for the character the definition requires a Bone from which a chunk should be spawned and the name of the chunkmesh. The ChunkMesh definition in turn can have several values set such as GravityScale and UseGinFile. GravityScale greater than 1.0 pulls a chunk down faster, UseGinFile will look for a bounding box with the same name as the chunkmesh in the damage mesh's gin file, if the bound is found, it is used instead of the default rendering bound which can help artists orientate chunks so that they land on their correct side --> <ReactionProcessing> <!-- particles --> <Particles> <!-- spark particle from the joint --> <Param Name="BoneEmission" Value="neck_g"> <Param Name="ParticleID" Value="IDS_FX_LIGHTSABER_BODY_IMPACT"/> </Param> </Particles> <!-- chunks --> <!-- <Chunk Typename="TSingleChunk"> <Param Name="Bone" Value="neck_g"> <Param Name="ChunkMesh" Value="head"/> <Param Name="GravityScale" Value="1.4"/> <Param Name="RandomVelocityScale" Value="0.2"/> </Param> </Chunk> --> </ReactionProcessing> <!-- The Capsules section provides a list of capsules that should affect the hitpoint of the part and should be disabled once the chunk has been dismembered --> <Capsules> <Capsule Name="Dneck_g"/> </Capsules> </DismemberablePart> <!-- LEFT SHOULDER --> <DismemberablePart Name="Left Shoulder" Hitpoints="25"> <Materials> <Material Name="Shoulder_LSG"/> </Materials> <ReactionProcessing> <!-- particles --> <Particles> <!-- spark particle from the joint --> <Param Name="BoneEmission" Value="shoulder_L_g"> <Param Name="ParticleID" Value="IDS_FX_LIGHTSABER_BODY_IMPACT"/> </Param> </Particles> <!-- chunks --> <Chunk Typename="TSingleChunk"> <Param Name="Bone" Value="shoulder_L_g"> <Param Name="ChunkMesh" Value="Shoulder_L"/> <Param Name="GravityScale" Value="1.8"/> <Param Name="RandomVelocityScale" Value="0.1"/> </Param> </Chunk> </ReactionProcessing> <Capsules> <Capsule Name="Dshoulder_L_g"/> </Capsules> </DismemberablePart> <!-- RIGHT ELBOW --> <DismemberablePart Name="Right Shoulder" Hitpoints="25"> <Materials> <Material Name="Elbow_RSG"/> </Materials> <ReactionProcessing> <!-- particles --> <Particles> <!-- spark particle from the joint --> <Param Name="BoneEmission" Value="shoulder_R_g"> <Param Name="ParticleID" Value="IDS_FX_LIGHTSABER_BODY_IMPACT"/> </Param> </Particles> <!-- chunks --> <Chunk Typename="TSingleChunk"> <Param Name="Bone" Value="shoulder_R_g"> <Param Name="ChunkMesh" Value="Elbow_R"/> <Param Name="GravityScale" Value="1.8"/> <Param Name="RandomVelocityScale" Value="0.1"/> </Param> </Chunk> </ReactionProcessing> <Capsules> <Capsule Name="Dshoulder_R_g"/> </Capsules> </DismemberablePart> </DismembermentDefinition>

Just found these forums, that's my github in the OP. Happy to help. This may help you too https://github.com/taylorfinnell/on3diimporter/blob/main/on3diimporter.py

Yes! I´ve to create a tool to merge and split image, so i can merge them, edit and later split to insert.

Hi Shak-otay, yes it's me, I never imagined you would remember me 😄. I found this texture in the file.

Bumping this again because I really don't want this thread to quietly die, as it seems the edits to my message are not enough to constitute a bump. Every single possible 16 bit float format I've tried does not work. Indicating this is some proprietary cursed format. Maybe a LUT. Maybe encrypted. Maybe something else. Which probably explains why the .mot files still have not been decrypted all these years. I do suspect what certain bits mean but I am really unsure. I have the model .bin and some other examples of .mot in hand as well so if you would like me to send it I will gladly do so. Just note I do need these files decrypted for a project so I would like this done as fast as possible it would be nice. What I do know is that this is little endian. Z-Y-X order. I have no clue what else. Help is much appreciated please 🙏 (I am not sure what y'all want but I am interested in a way to export the .mot to .csv with a Frame # column. For my application, that is enough.)

Well, I did a little research on Flash Cookies (SOL files) and I put it all together in the article on RE Wiki https://rewiki.miraheze.org/wiki/Flash_Cookie_SOL I saw notes on your github and you were sligthly wrong with some fields, so you can compare it with my article on the wiki and make some corrections in your tool. The most important thing is that you should understand that SOL file is an Adobe format and payload (data block) follows AMF file format documented by Adobe https://web.archive.org/web/20220122035930/https://www.adobe.com/content/dam/acom/en/devnet/pdf/amf-file-format-spec.pdf So anything after data block header is a payload section that needs to be properly serialized by your tool. There are many tools that allow you proper serialization like: minerva, SOL Editor, Adobe AIR SDK, JPEXS Free Flash Decompiler etc. Some code for serializing is available on JPEXS github page: https://github.com/jindrapetrik/jpexs-decompiler/tree/master/libsrc/ffdec_lib/src/com/jpexs/decompiler/flash/sol https://github.com/jindrapetrik/jpexs-decompiler/tree/master/libsrc/ffdec_lib/src/com/jpexs/decompiler/flash/amf/amf3 You can test this code by going to Tools > Sol cookie editor in JPEXS Free Flash Decompiler: So you shouldn't ask "what are those three bytes". You should ask "how can I properly parse AMF3 serialized data" 🙂 There are lots of information (articles) about this, for example on wikipedia: https://en.wikipedia.org/wiki/Local_shared_object https://en.wikipedia.org/wiki/Action_Message_Format Good luck. 🙂

Okay, thanks for the lead. I successfully uncompressed the PUD file, and it is indeed a container. The value 0x2 represents the number of files within it. The uncomressed images are raw pixel data and need to be combined with the PAL file to get the correct image. can use imageheat to view the correct image.

fmt_psaVita_ValkyrieDrive.py Here's a old noesis plugin to view and export most of the mib, msb and mab of the PSVisa version of the game.

Edit - just tested it and no 4 mrts is uv, you was right in saying the 4th one is the uv maps by the rule

Hi experts. I'm trying to read the MT2 images from Indiana Jones and the Emperor's Tomb (PS2), but I'm stuck trying to piece it all together. The images in the PC version are 32-bit RGBA, so that's easy, and gives us a comparison. For the same image in the PS2 version, it seems to be broken down like this... 64 bytes - basic image data (filename, width, height, etc) width*height/2 - 4-bit pixel values (with 4bit PS2 swizzling) width*height/8 - color values This is what the pixel block looks like, as 4-bit values in grayscale: The color values in the last block, look to be something similar to RGBA5551, so even though the length of this block is width*height/8, as they are 16-bit colors, there are actually only width*height/16 colors. This is what the color block looks like when read as RGBA5551 color values: ... you can see the image in that "color block". I know it's not quite the right colors, but think it might just need some color striping applied to it, or it might not be exactly RGBA5551. As the width/height increase, so does the size of the color block, so it's not a plain palette, it's proportional to the image size. For example, for a 128x128 image, the color block is 2048 bytes. For a 256x256 image, the color block is 8192 bytes. I'm struggling to work out how to join the "pixel" block and the "color" block together so that we end up with a usable image that looks similar to the PC image. I'm assuming maybe we need to generate some in-between colors like in a DDS image, or otherwise apply some kind of "intensity" to the colors or something like that. I've never seen anything like this before - is anyone able to assist in understanding this please? I have attached a ZIP with the PC image, the PS2 image file, and PNGs for both the "pixel" block and the "color" block, so you can clearly see there is a correlation between the 2 blocks. Thanks for your help! vinehead.zip

Anybody could share mot, tex_db.bin and a model file .bin of a character

for the mcgregors normal you can use this bms Decompressor.zip

Well, use my old c++ tool, it should work now, tried to rewrote in python for training python syntax, and maybe i did something wrong. ZstdMagicExtractor.zip ZstdMagicExtractor-release version.zip

I know I’ve already posted my progress with materialising Mike Tyson but I thought I’d show these also as I managed to convert the normals from green to purple which for me personally and unity mods it works better

I've just released a new version of ImageHeat 🙂 https://github.com/bartlomiejduda/ImageHeat/releases/tag/v0.31.2 Changelog: - Added new pixel formats: APLHA4, ALPHA4_16X, ALPHA8, ALPHA8_16X, RGBA6666, RGBX6666, BGRT5551, BGRT8888, PAL8_TZAR, BGRA5551, BGRA5551_TZAR, BGRA8888_TZAR, BGRA4444_LEAPSTER - Added support for LZ4, Emergency RLE, Neversoft RLE, Tzar RLE, Leapster RLE, Reversed TGA RLE - Fixed issue with x360 swizzling - Fixed issue with PS Vita/Morton swizzling for 4-bpp images - Added support for palette values scaling (1x, 2x, 4x, 8x, 16x) - Added dropbox for palette scaling in "Palette Parameters" box - Added funding info

Hello guys, I need help to the correct read UV`s and Textures, from the Reckless Racing game. Earlier, durik256 helped me read the mesh format and some UV data from the *.sggr format, but to this day I haven’t been able to figure out the UV scaling and materials. Here’s the link to the discussion: https://reshax.com/topic/1067-reckless-racing-ios-vfs-files/ Below is the Noesis script for reading the mesh data. Script have two problems: - Sometimes the script reads the LOD versions of the mesh models. - It also doesn’t read the UV scale, and the mesh isn’t split by materials. I’m asking for your help in updating this script. from inc_noesis import * def registerNoesisTypes(): handle = noesis.register("Reckless Racing", ".sggr") noesis.setHandlerTypeCheck(handle, noepyCheckType) noesis.setHandlerLoadModel(handle, noepyLoadModel) return 1 def noepyCheckType(data): if data[:4] != b'\x4D\x3C\x2B\x1A': return 0 return 1 def noepyLoadModel(data, mdlList): bs = NoeBitStream(data) ctx = rapi.rpgCreateContext() ofs_res = data.find(b'#RES') if ofs_res != -1: bs.seek(ofs_res + 44) unk, vnum, zero = bs.read('3I') skip = 12 if unk == 4368 else 0 vbuf = b'' vbuf, uvbuf = b'', b''#bs.read(vnum*24) for x in range(vnum): bs.seek(2,1) vbuf += bs.read(2) bs.seek(2,1) vbuf += bs.read(2) bs.seek(2,1) vbuf += bs.read(2) bs.seek(5,1)#4 uvbuf += bs.read(2) bs.seek(2,1) uvbuf += bs.read(2) bs.seek(1,1)#2 bs.seek(skip,1)#12+ rapi.rpgBindPositionBuffer(vbuf, noesis.RPGEODATA_SHORT, 6) rapi.rpgBindUV1Buffer(uvbuf, noesis.RPGEODATA_USHORT, 4) u0, inum, u1 = bs.read('3I') ibuf = bs.read(inum * 2) rapi.rpgCommitTriangles(ibuf, noesis.RPGEODATA_USHORT, inum, noesis.RPGEO_TRIANGLE) try: mdlList.append(rapi.rpgConstructModel()) except: mdlList.append(NoeModel()) return 1

Hey all, I also recently got interested in modding the original QP Shooting. I'm currently working on a command-line tool that so far allows for extracting and repacking the LAG assets, with decoding and encoding of dialogue/system files also now planned to be implemented. However, it seems after reviewing this thread that I wrongfully assumed that the graphics were red-blue-swapped A16B16G16R16 DDS surfaces rather than a special Luna/LAG image format... so that's probably another thing I need to fix up (although the assets can be modified fine with an editor that supports that DDS format once the header is written, so maybe it is just a slightly tweaked version of DDS). I'll post the GitHub link here when I polish and finish it up : )

Awesome man, glad to have helped! If there's any other static meshes you need let me know

Sorry, my bad, now i see, list look similiar how my old

Hello, here the decompressor, it´s a custom lzss. LZSS_DGirl-ps2.7z

Because the fmlb and sound file does exits anymore because when before Game shutdown that files are dynamic content but some files like that are available in beta versión APK and obb but no all files

import struct import os import sys from PIL import Image # Constants for offsets FILE_COUNT_OFFSET = 0x28 FILENAME_TABLE_OFFSET = 0x2C DATA_INDEX_OFFSET = 0x178C # A SINGLE, CORRECT LOOKUP TABLE FOR IMAGE DIMENSIONS BASED ON FILE SIZE. # All files are grayscale (1 byte/pixel). SIZE_TO_DIMENSIONS = { 262144: (512, 512), 524288: (1024, 512), 1048576: (1024, 1024) # Add more entries here if new sizes appear } def extract_grayscale_images(file_path, output_dir): """ Extracts all image files from a given .dat archive, assuming they are raw grayscale pixel data. """ with open(file_path, 'rb') as f: # Read the total number of files in the archive f.seek(FILE_COUNT_OFFSET) file_count = struct.unpack('<I', f.read(4))[0] # Read the filename table f.seek(FILENAME_TABLE_OFFSET) filenames = [] for _ in range(file_count): try: name_len = struct.unpack('<I', f.read(4))[0] filenames.append(f.read(name_len).decode('ascii', errors='replace')) except (struct.error, IndexError): # Stop if the file ends unexpectedly break # Move to the data index table f.seek(DATA_INDEX_OFFSET) print(f"Starting extraction of {len(filenames)} files (all as grayscale)...\n") success_count, skipped_count = 0, 0 for i, filename in enumerate(filenames): try: # Read the offset and size for the current file entry_data = f.read(8) if len(entry_data) < 8: break # Reached end of index offset, size = struct.unpack('<II', entry_data) # Check if we know the dimensions for this file size if size not in SIZE_TO_DIMENSIONS: print(f"[{i+1}/{file_count}] {filename} -> UNKNOWN SIZE ({size} B). Skipping.") skipped_count += 1 continue width, height = SIZE_TO_DIMENSIONS[size] # Read the pixel data current_pos = f.tell() # Save current position in the index f.seek(offset) pixel_data = f.read(size) f.seek(current_pos) # Return to the index # Prepare the output path, preserving directory structure safe_name = filename.replace('.dds', '.png').replace('\\', os.path.sep).strip(os.path.sep) out_path = os.path.join(output_dir, safe_name) os.makedirs(os.path.dirname(out_path), exist_ok=True) # ALWAYS convert as 'L' (grayscale) img = Image.frombytes('L', (width, height), pixel_data) img.save(out_path, 'PNG') print(f"[{i+1}/{file_count}] {filename} -> {out_path} ({width}x{height}, Grayscale)") success_count += 1 except Exception as e: print(f"[{i+1}/{file_count}] {filename} -> CRITICAL ERROR: {e}") skipped_count += 1 print(f"\nFinished! Converted: {success_count}, Skipped: {skipped_count}.") if __name__ == "__main__": if len(sys.argv) < 2: print(f"Usage: python {os.path.basename(__file__)} <file.dat>") sys.exit(1) input_file = sys.argv[1] # Create a more standard output directory name output_dir = os.path.splitext(input_file)[0] + "_extracted_images" print(f"Input file: {input_file}") print(f"Output directory: {output_dir}\n") extract_grayscale_images(input_file, output_dir) This script unpack texture. The file names are given with the .dds extension, but these are not DDS files. There are two types of files: those with [e] in the name build correctly, and those without [e] are strange. That's all I can help with. Script usage: python <scriptname>.py <path to file> e.g., python unpack.py sky.t000 - if it's in the same directory as the script.

It seems like at 0x24 is vert count(4F8=1272), then at 0x40 is a pointer to vertices(0x70780). After that a line of zeros and then other block of vertices, maybe other facel?(I don't know why are 2 faces). But vert count is taking that line of zeros. I tried to ignore that line and then including that line but is the same result. The only differenece is that large triangle that goes to the floor. So it both cases is a mess, lol. Oh, probably after pointer to vertices, are pointers to Normals(0x44), Uvs(0x48) and vertex colors(0x4C). I don't understand, this is so werird...

You can use my latest Fmod Bank Tools - https://www.nexusmods.com/rugbyleaguelive3/mods/2 https://github.com/Wouldubeinta/Fmod-Bank-Tools Just PM me for the bank password.

*(I think you should mention the author.)

bumping this 2

So I was wrong, Conker's Eyes don't rely on a shader to make them look correct, the eyes have 3 UV channels for the Pupil, Highlight, and the Eye Lids. I just recently implemented the Multi UV Channel support

I know this is from April but I want to give my two cents on this because I just figured out how to do this myself and I hope this can help other people as well. I'll try and simplify this in a step-by-step format as best as I can. Preliminary requirements Programs you will need include: Ryujinx (or any application that can extract NSP files) RevilLib (for file conversions) Kuriimu2 (for .arc file viewing & exporting) (Optional) Notepad++ or VS Code, I prefer these to create and format .json files in. 1. Getting the extracted files Using Ryujinx is the easiest way to convert the switch rom format (NSP) into something that will be readable by other programs. Right click on the game in the game list>Extract Data>RomFS. It will ask you where you want to output the files, I recommend somewhere you'll easily remember. This will take a few minutes. 2. Locating the desired files After you're done exporting the NSP, open Kuriimu and find the .arc file that you want to open. I haven't (for now) put together a library of monster IDs, but know that large monsters start with "em_xxx" in their file IDs, and small monsters are "ems_xxx". This is where the model and texture files for whatever monster you have selected will be (generally). The "mot" folder has the .lmt files in it though, so I would recommend exporting those into the same folder as the model and texture files. 3. Converting the .mod file(s) This is by far the easiest step. You can simply drag and drop the .mod file onto the mod_to_gltf batch file in RevilLib's folder and it should automatically convert the .mod file to .glb in the same location where the .mod file is stored. 4. Converting the .lmt files After exporting your .lmt files, make sure that your .mod file is in the same location. This will speed up the rest of this process, and is also necessary for the spike batching we're about to do. In the same folder as the .lmt and .mod files, create a .json file (I usually just name it "batch.json). Open it up in your text editor of choice, and now I will quickly explain how the spike batching works. 4.1. Spike Batching Here is an example of my code (which exports the Rathian animations): [ [ "em001_00.glb", "em001_00_0.lmt", "em001_00_1.lmt", "em001_00_2.lmt", "em001_00_3.lmt", "em001_00_4.lmt" ] ] The .json file reads from its root directory, so there is no need to link to individual file paths. Thankfully, this program will also automatically group all the animations together, so when you view them in Blender (using the action viewer, in the dope sheet), it is nice and consolidated. What this does is pretty obvious, but we are just telling the program that the .glb file is the model we want to use with the animations, and the .lmt files are the animations that we are assigning to the model. When you are done with this file, drag and drop it onto the lmt_to_gltf batch file (located in the RevilLib folder, same as mod_to_gltf), and you should have the .glb file containing the animations in your root folder. It will have "out" at the end of the filename, if it isn't clear to you which one it is. 5. Importing to Blender Because I use Blender, that is the program that I will refer to in this step. It's really simple to do this because Blender, thankfully, has .gltf and .glb file-reading built-in, so import the xxx_out.glb file that we just got and everything should import correctly, animations and all. The textures are another beast, but I'm willing to explain those as well if needed.

I checked jmox files but mesh needs transformation... Here's quick sum up content of *.pack archives. main = ? > mixed mdc = jmox > models cars mde = jmox > models environment so = xvs > sounds lm = jtex > textures prb = jtex > textures gin = jtex > textures

why don't you just connect the vertices in a 3d editor. the plugin opens the models, that's all you need. the rest you can work on yourself

Bumping this, if anyone would be an absolute unit to solve the animations it would be greatly appreciated! 🙃

Does anyone know more about the mcd format used by EA? Models are packed inside the rsf format and it is possible to extract them with the rsf.bms script. I managed to make a Noesis script to view the models, but reading the skeletons is hard for me and I don't know how to proceed with them. Vertex weights are stored in a table that starts with the tag TIEW in mcd and skeleton data in FRGS in .skel file. I would appreciate any kind of help to import the skeletons into noesis. Preview in Noesis: https://imgur.com/a/o2dQvCl fmt_NHL21_mcd.py rsf.bms.zip nhl21model.zip

I've written a Noesis script to make things easier for you tex_CarsPST.py Put the script in <NoesisDirectory>\plugins\python Some of the PST textures you sent has a mip levels more than one but due to how Noesis works I decided to only handle the highest one (Or probably I just don't know a proper way to do it anyway they were ordered from low to high). Also I assume every PST textures is palettized 8-bit image?

Maybe you should open a new thread and ask in there, not here, because this thread is for discussing the motion file.

for fgo's script, you just need run this: python FGOArcade-FARC.py "your farcfile path" for farcpack tool, Run it in the shell to see the cli commands.

yeah i guess so. but I think we need to find something to differentiate between rotate data or transform data, and it's hard to find that, so we need something reverse work

https://github.com/h-kidd/noesis-project-diva AFAIK this uses the same (or highly relevant - Virtua Fighter 5 based) engine as other arcade games such as Project DIVA Arcade or Fate Grand Order I guess the animation format would be relevant (and hope this be helpful for REing)

Guys just close this post make no sense, The forum is new in 3d category are 260 post and 4 of this are with the same title "please help .......3dunity". Please search first in forum if exist a answer next make post. Its more easy if collect all the info for type of file in 1 place, honesty the old xentax have guys who redirect to main post if some1 go like this for every little thing. And I see the OP make 3 post in row 5 min from each other for almost the same thing. Just start over this obvious goin anywhere.