• Models from Infninite Crisis
    169 replies, posted
Hello this is my second topic.I want some 3d model,animation,vfx file from the game infinite crisis.I have the fully updated version of the game.The file extensions are .rp could anyone please create or provide me a quickbms script or any unpacker so that i can decompress the files from the .rp format.I am pasting a link to the website from which you can download the files i uploaded. [url]https://mega.nz/#!NcMSCBAK!toGiEyc3hzf0YIzXPGce1ZLdtuUWxgmINLbDn-haHtA[/url]
wow... you got it uploaded to an external host? well then... into [url=http://forum.xentax.com/viewtopic.php?f=16&t=14162&p=117250]that thread[/url] with that sample. isn't that yours too? i'm sure shakotay2 will crack that faster then anybody else. aluigi does the scripts tho. you can only hope they got time or fun messing with it. ;)
why don't you create a quickbms script or any unpacker so that i can decompress the files from that .rp extension
why i don't? cause it's damn work to decode file formats. and i'm not really good dealing with scripts. i could pull some textures out of the hex, but that's where my motivation ends looking at that packed chaos. i should not have time for that really... anyway. :) juts post the file in that xentax thread. those peops there might enjoy that more then i would... perhaps.
I can't post it on xentax because the topic has been locked.
maybe it was locked for a reason. cause... ofc i hade to rip a texture. it was indeed a lil bit of manual hexery. this file format is a freaking binary mess. i got this texture thing. but... would you believe me if i'd tell you "those models can not be extracted easily." !?!
You mean to say that there is no way to rip the models and animations from that game
yes. that's what i meant to say. if the game still runs in - offline mode - maybe you could try ninja ripper to get some meshes and textures out of it the easier way. the files itself are protected of some sort. i think i found that 'duct tape' signature tho. plain hard to read to decode them tho. so... if you wanna try something hardcore you could try to write the scripts yourself. i got no clue how that bms language works. not my forte. aluigi is better at that. now... the duct tape signature to search for in the hex is '78 01 00 FB FF' the first jumps are rougly 0x10000 far. you should find '00 05 80 FA 7F'. you gotta remove the signatures then jump rougly 0x8000 forward each. find '00 00 80 FF 7F' and remove. every 4th jump is 4 bytes longer. after that you should have a plain packet. you could then start to process the DXT signatures. the width and height are stored before the signature. the length of the data chunks are stored after it. and maybe you wanna try hex2obj to find out where the meshes are. this is a lil beast tho. that's what i got real quick. i could post that on xentax for the guys with their tools, but it's closed. *shrugs* a reason to remove that stupid poster. but... i'll not do it. i'd say... if your smart you could do it yourself.
[QUOTE=episoder;50205486]'78 01 00 FB FF' .... '00 05 80 FA 7F' .... '00 00 80 FF 7F' every 4th jump is 4 bytes longer after that you should have a plain packet[/QUOTE] No. This is actually a little bit different. 1. the whole RP file is split by very long chunks with 0x400 padding. Such chunk can even be 100MB long, and their sizes are all mentioned in the beginning. 2. each big chunk is split into 0x20000 chunks. 3. each small chunk is again split into smallest chunks with variable size, that is usually 0xFFFB, 8005, 8000, so on. (you can see these numbers in figures you provided) That's why you have an impression of these 'magic' signatures, which are just chunk headers, and strange "every 4th jump". [editline]26th April 2016[/editline] And this is also a result of some h2o work here. Meshes are also chunked, but all this could be done, no doubt. [IMG]http://i67.tinypic.com/2jcag46.png[/IMG]
i still gotta work on that? i only slightly disassembled the 0xa0c122e2.rp. seems to be a texture only storage. in that... the thing at 0x400 is an 'file identifier (aka 'hash') table'. after that the stream starts with that duct tape symbol. data stream start magic. followed by '0x0400'. after that the first file identifier. the file header and the texture data. no sizes but in the files anywhere. i dunno how that game loads the files. it potentially loads everything and parses it atleast once completely to get file archive hashes, offsets and sizes? or there's another file for that. and the duct tape only follows that logic i layed down there already. it's seems rather useless. and i found no other chunk barriers in there. sure nice you got a mesh out of it. it shows it's possible with a lil bit of what?... work? :smile:
No, you don't have to work :) We are just talking about this archive format just for fun. [QUOTE=episoder;50207418]and the duct tape only follows that logic i layed down there already[/QUOTE] No, because the big chunks and small chunks are independent, and this "every 4th" rule will not work.
but that 'every 4th' is exactly what i did removing the tape to get a continous texture data chunk i hexed into a dds container. i jumped 0x8000 and removed 5 bytes of glue. every 4th jump the glue was 4 bytes further ahead. looking at dxt it's way too easy. don'tcha think so?!? who can't see that alignment? :v: [IMG]http://i.imgur.com/CUKYwiH.gif[/IMG] so bored. i read a lil more. those 0x20000 pointers are indeed in there. 0x5CFE0100 points backwards to the tape magic. this got no base pointer or arithmetic tho. and i might have accidentally removed them when i corrected the 'pattern' of the dxt. stupid me. :v: the test file on the xentax thread even has potential encoding errors. undefined shifts in the mipmaps. but it's a boring front end file. so it probably doesn't matter. the 2nd jump on that 8000ers is not really precise either. 5 off the target. weird how that even works. :smile:
And if you take another file, containing not only textures, you'll see that 3rd-level chunks are also there. I've seen that when extracted that gargoyle or something.
what? still more. bigger? nope. nothing in the beginning i can find. only some guesstimation of the raw data size. i don't wanna math that. and smaller might be just how the data is aranged? strip groups? or drawcalls maybe?
How did you extracted the gargoyle from the .rp file. which software did you use.If I provide you every file from infinite crisis will you be able to unpack the models and animations and vfx files from those rp files
I extracted gargoyle with hex2obj [editline]27th April 2016[/editline] [QUOTE=episoder;50210585]what? still more. bigger?[/QUOTE] Yes. For example in the file 0xa000024c.rp after about 100MB, the big chunk ends, there's another 0x400 padding, and the whole 0xFFFB, 8005, 8000... story starts again. I have an idea why small chunks are different. They probably have some prefetch system, like most games today. And they needed to load first 65k from each file for that. But because of 5 bytes chunk header, if you prefetch 65k, chunks will be cut in the middle. So they made the first one exactly 65k minus 5 bytes. Then, to compensate that, second is 32k plus 5 bytes, and then all others are 32k each. That's not a protection, just some technical feature.
Then there is no way then
i found that 'long chunk'. more weirdness then useful. cause/and... imho... chunk prefetch is bullshit. half a file is still useless for display. gotta do file per file. or the hdd hardware buffer cares about sector fetches when loading small crap. don'tya think? ssd and a fitting read cluster size would maybe work. faster scatter sector crap reads. just like ssd works. but yeah. they totally failed doing precise binary alignment for that sort of chunks. anyway... the ssd wear controller will scatter virt that crap even further then what you can try. you could still do 'sequential' and it might do it. :v: and... @Amrita 'we' are not sure yet. this stuff is a lil bit of data. without filenames or extensions. now... would it be enough if somebody'd write a depacker that depacks all that files as '0x12345678.bin' format into one directory and you gotta search it yourself. this is what that archive format would actually depack to natively... right now. you got no clue of that stuff... right?!? you think this is real easy to just push a button and have it. it's not like that. you gotta get that. i'd say... there's no way the way you want it. you can try it all manually yourself. all the methods are posted here. on the way you'll maybe find ways to extract what you need a lil quicker. but you gotta do it yourself. i don't feel like parsing that gig of random data to search for models i actually don't care about. *shrugs* @id-deamon for the heck of it... could you post that lil bugger as obj. [IMG]http://i67.tinypic.com/2jcag46.png[/IMG] i might wanna edit it a lil bit... paint it... make it a funny lil prop. :smile:
You have to wait then. This thing also has 4 small submeshes. Maybe wings? [editline]28th April 2016[/editline] No. No wings. Just some piece of architecture Here you go [url]http://pastebin.com/qbUEB2nR[/url]
cool. thx. mind telling how to identify uvs in that vertex format. or which position and format it was in that gargoyle. i don't get this. i tryna rip a pile of garbage i found. looks like i picked a crashed car or something. [IMG]http://i.imgur.com/iJZyOF2.jpg[/IMG] only 1 of 2 parts of the model. the vertex and index buffers are nicely tagged with the sizes. still gotta search for material and texture hashes in that pile of bits tho. :v:
I am very greatful to you.I am waiting to receive some more.If you are having trouble because i didn't send all the files from infinite crisis then i am pasting a link where i have uploaded all the files from infinite crisis. here is the link [url]https://mega.nz/#!8AUQyKSB!BRsL7_YT4oRSqWZ7tC1eo6X0q_rAoouy7AGYQ0PqKmo[/url]
UVs were 4 bytes after vertex coords, in 16-bit WORDs (not floats)
yup... they are. some of them look broken tho. and that lil model i got with it's 4 subsets overlaps and spans multiple uv spaces of what i think are baked lightmapped textures. gosh. -_- now... synced. this' a load. i sampled. you can sort them by file size. heroes seem compacted with their own stuff as embedded resources. varying from 1 to 10 MB. you could search for 'chr_' in the hex to find who it is. you can check the amount of entries in the hashtable. a lil lower then whole packages of models. note that i mentioned it's as long as you hit the 'chunk' aka 'duct tape' signature '78 01 00 FB FF 40 00'. a real quick look... for examples for your extracting pleasure. 0xa00001ec.rp is 'the flash' model. 0xa000025f.rp is 'the joker's animation file. both found by searching 'chr_' in the hex. i dunno what you'll find in there. but... happy extracting. :smile:
And now, let's think what to start from... [IMG]http://i66.tinypic.com/33e7v35.png[/IMG]
Wow thats the 3d model of harley queen
[IMG]http://i63.tinypic.com/13yl3ps.png[/IMG]
And now with specular & normal maps! [IMG]http://i66.tinypic.com/1zgpxcp.png[/IMG]
you got this done pretty good. i guess it was all in the same .rp file?!? and... you got any clue howto find the vertex and index buffers quick? anyting signature? you might post it. i'll not ask howto do bones. i'd not go that far. nice job extracting that tho. :)
Maybe you guys can post your findings over at xentax, hopefully this will give some of the brainy ones there enough of a starting point to figure out where the bones and weights are.
[QUOTE=episoder;50227592]you got this done pretty good. i guess it was all in the same .rp file?!? and... you got any clue howto find the vertex and index buffers quick? anyting signature? you might post it. i'll not ask howto do bones. i'd not go that far. nice job extracting that tho. :)[/QUOTE] Yes it was in one file. Buffers can be found, but there's a big problem here. The whole "stream" is just a serialized data. So to read it, or find anything in it, we need to de-serialize the whole thing, and for that we need a full structure description which we obviously don't have. So the only way is using workarounds.
Sorry, you need to Log In to post a reply to this thread.