READ THE RULES: Click here

Follow us on Facebook: https://www.facebook.com/xentax/ :)

Metal Gear Solid 5 (MGSV) animations

Post questions about game models here, or help out others!
daemon1
M-M-M-Monster veteran
M-M-M-Monster veteran
Posts: 1887
Joined: Tue Mar 24, 2015 8:12 pm
Has thanked: 48 times
Been thanked: 1424 times

Metal Gear Solid 5 (MGSV) animations

Post by daemon1 » Tue Sep 27, 2016 8:49 pm

Image

I'm researching Metal Gear Solid 5 animations. They have unique and interesting system. So far I was able to read all position/rotation data for all frames/bones and unpack rotations to proper quaternions. They were packed another weird way I've never seen before. Another strange thing, they actually baked IK data INTO the animation, that is very unusual, most games apply IK AFTER the animation.

Image

This is the current state of research (200 extracted animations in one non-stop video). As for strange effects in transitions between animations, ignore them, it happens because they're not supposed to work in one go.

https://youtu.be/oUofIF7u1bQ

Also here's an interesting video recorded during quat research. Changing one component sign made snake (and everyone else) walk in a strange way. I also have a video of finding Paz in this way, its pathetic.

https://youtu.be/7pOoO4rhimY

Research thread: https://facepunch.com/showthread.php?t=1534738
Last edited by daemon1 on Sun Oct 02, 2016 6:45 am, edited 1 time in total.

Gh0stBlade
Moderator
Posts: 683
Joined: Mon Jul 05, 2010 8:55 pm
Has thanked: 20 times
Been thanked: 325 times

Re: Metal Gear Solid 5 (MGSV) animations

Post by Gh0stBlade » Tue Sep 27, 2016 9:30 pm

Excellent work!
Click the thanks button if I helped!

daemon1
M-M-M-Monster veteran
M-M-M-Monster veteran
Posts: 1887
Joined: Tue Mar 24, 2015 8:12 pm
Has thanked: 48 times
Been thanked: 1424 times

Re: Metal Gear Solid 5 (MGSV) animations

Post by daemon1 » Wed Sep 28, 2016 8:11 pm

Tool beta published here: http://zenhax.com/viewtopic.php?f=5&t=3172

It only works on snake (Ground Zero format) skeletal animations now, but soon there will be support for all kinds.

User avatar
Bastien
advanced
Posts: 69
Joined: Sun Apr 15, 2012 1:08 am
Has thanked: 26 times
Been thanked: 12 times

Re: Metal Gear Solid 5 (MGSV) animations

Post by Bastien » Sat Oct 01, 2016 7:49 pm

This looks like an excellent work. Some questions about the research:

1- How much time did it take you to figure out the format?
2- Are you going to release the format spec?

I always wanted to research animation formats, it always seemed to me like the most difficult, so any info on your workflow is appreciated.

User avatar
Mr.Mouse
Site Admin
Posts: 4037
Joined: Wed Jan 15, 2003 6:45 pm
Location: Dungeons of Doom
Has thanked: 412 times
Been thanked: 557 times
Contact:

Re: Metal Gear Solid 5 (MGSV) animations

Post by Mr.Mouse » Sat Oct 01, 2016 10:03 pm

mgs5_anim.rar
And here a local copy. :]
You do not have the required permissions to view the files attached to this post.

daemon1
M-M-M-Monster veteran
M-M-M-Monster veteran
Posts: 1887
Joined: Tue Mar 24, 2015 8:12 pm
Has thanked: 48 times
Been thanked: 1424 times

Re: Metal Gear Solid 5 (MGSV) animations

Post by daemon1 » Sun Oct 02, 2016 7:04 am

Animation research in "normal" games usually takes 1-2 weeks. That meaning they're using normal data types like ints, floats or half-floats. But recently I reversed Morpheme engine. This look about a month. They had mixed global/local rotations, variable bit-length packed data, specially packed quaternions, and so on.

Now to MGSV. The research is not complete yet. It took 2 weeks already, and probably may take another month. Just yesterday I found them sometimes using 16-bit float numbers, and not usual half-float format, but their own type. They also had variable bit-length packed data, and quaternions packed in another weird way. There are still facial, cutscene animations to do, maybe including some more non-standard types.

I will describe most of the special things they use when I have time.

So that's right. Animation research may be most difficult, because for that you need to know models and rigging with all their details and tricks, and above that, you have to understand quaternions and all those geometry calculations needed to build skeletons and animate models.

User avatar
MrAdults
Moderator
Posts: 1007
Joined: Mon Mar 23, 2009 2:57 am
Has thanked: 44 times
Been thanked: 498 times

Re: Metal Gear Solid 5 (MGSV) animations

Post by MrAdults » Mon Oct 03, 2016 3:04 am

Bastien wrote:This looks like an excellent work. Some questions about the research:

1- How much time did it take you to figure out the format?
2- Are you going to release the format spec?

I always wanted to research animation formats, it always seemed to me like the most difficult, so any info on your workflow is appreciated.
Since you messaged me looking for info, here's some relevant free tidbits:

- Animation data can be trivial at times, but often if there's any kind of interesting compression or packing, disassembly becomes vital or at least very useful.
- PC games are way easier to deal with when figuring out any kind of complex data, like elaborate animation packing/encoding, compression, and encryption. Faster turnaround for debugging sessions, and faster turnaround for modifying data in-place, or even in memory, to observe the outcome. Additionally, capabilities like hardware read/write and conditional breakpoints can be hard to come by for some non-PC platforms.
- Start by learning how to debug and read through disassembly, using breakpoints and system hooks effectively to get at the routines you care about, where the data you care about is being utilized. Spend a lot of time with IDA just learning how to target data and understand the disassembly dealing with it. It will usually take you longer than just staring at binary for simple formats, but the practice will be very valuable for you for when you want to do something complicated.
- In-memory asset data like animation can be even easier to discern in this manner than something that's quickly flushed or copied multiple times at load time. For this type of data, just search for the data in-memory, set a read breakpoint on it, and you'll end up somewhere directly relevant to the data you care about.
- Even if you're dealing with an easier platform, still be prepared to lose plenty of hours of your life. Make sure you're married and have a nice family before you commit to flushing your days down the drain.
- For PC x86/x64 games, once you narrow down the range of disassembly you're dealing with, you can pull it out and compile it into your own program locally. This isn't terribly difficult, and it'll be a pretty obvious step once you've spent some time debugging your way through some disassembly. From here, all you have to figure out is what to feed in (e.g. what register and stack states are expected to be as you enter your initial function), and you can replicate the behavior (whatever it may be, such as decoding a frame of animation) in your own program. Once you have this happening, it's much easier to begin picking apart the isolated code, and test it on different assets in a more controlled environment. Translating it back to some other language is a simple matter of time at this point.
- If you're clueless about a certain type of data to begin with, it will be harder for you to reverse engineer it. Sometimes, broadening your knowledge in the related field is the right way to spend your time before you continue tackling a certain type of data.

People are petty and secretive with their findings, but other people are also dicks and steal things immediately, so it goes both ways. Often times, though, there aren't too many big global secrets that are going to help you across all games/platforms. If you can figure out the workflow above, you're pretty much set to accomplish anything on the Windows/PC side. Consoles are another matter. If you can get a debugger going on the target platform, great. If not, you're limited to offline disassembly and analysis, which can be much more time-consuming, but still viable if you're willing to put forth the extra effort.

User avatar
Bastien
advanced
Posts: 69
Joined: Sun Apr 15, 2012 1:08 am
Has thanked: 26 times
Been thanked: 12 times

Re: Metal Gear Solid 5 (MGSV) animations

Post by Bastien » Wed Oct 05, 2016 2:00 am

Thanks daemon1 and Mradults for your comments on your workflow. I don't want to pollute the thread with unrelated things to MGSV, so I'll post questions in other threads.
and above that, you have to understand quaternions and all those geometry calculations needed to build skeletons and animate models.
Yeah, I remember that when you talked about IK. I thought most games used FK data since they come from motion capture, but it makes sense to calculate data on the fly.
Spend a lot of time with IDA (...) It will usually take you longer than just staring at binary for simple formats, but the practice will be very valuable for you for when you want to do something complicated.
I've been using the Free version of IDA for some time, and reading a book, and it's been a little frustrating, specially the "using breakpoints and system hooks effectively to get at the routines you care about" I could identify where interesting strings where used (e.g. the name of a model file), but not where the actual parsing happens. Probably I didn't dedicate enough time to it, same with ollydb (seems to fail frequently in many games, probably an anti-debug system)
For PC x86/x64 games, once you narrow down the range of disassembly you're dealing with, you can pull it out and compile it into your own program locally. This isn't terribly difficult,
wow, amazing
Sometimes, broadening your knowledge in the related field is the right way to spend your time before you continue tackling a certain type of data.
I thought the same thing! I started learning a little directx.
People are petty and secretive with their findings

In many threads (but from many years ago) I saw that working in collaboration makes the process of figuring out 100% something much faster, but usually is the work on only one person that happens to be interested in the game. I understand the shitty experiences with people stealing stuff and not giving credit.

daemon1
M-M-M-Monster veteran
M-M-M-Monster veteran
Posts: 1887
Joined: Tue Mar 24, 2015 8:12 pm
Has thanked: 48 times
Been thanked: 1424 times

Re: Metal Gear Solid 5 (MGSV) animations

Post by daemon1 » Wed Oct 05, 2016 7:44 pm

Bastien wrote:
and above that, you have to understand quaternions and all those geometry calculations needed to build skeletons and animate models.
Yeah, I remember that when you talked about IK. I thought most games used FK data since they come from motion capture, but it makes sense to calculate data on the fly.
Yes, most games use FK data. But what I said was about most games. You need to understand quaternions and geometry calculations even for simple animations.

daemon1
M-M-M-Monster veteran
M-M-M-Monster veteran
Posts: 1887
Joined: Tue Mar 24, 2015 8:12 pm
Has thanked: 48 times
Been thanked: 1424 times

Re: Metal Gear Solid 5 (MGSV) animations

Post by daemon1 » Wed Oct 05, 2016 7:48 pm

Bastien wrote:
For PC x86/x64 games, once you narrow down the range of disassembly you're dealing with, you can pull it out and compile it into your own program locally. This isn't terribly difficult,
wow, amazing
I'm doing this very rarely. Only if its absolutely needed, for some very complex procedures. Actually I never needed that for animations, only once for complex audio codec. Most of the time, its possible and easier for me to just analyze the data. And if it's something really complex, debug it for a while, but once I understand what it does, make my own code for it.

User avatar
MrAdults
Moderator
Posts: 1007
Joined: Mon Mar 23, 2009 2:57 am
Has thanked: 44 times
Been thanked: 498 times

Re: Metal Gear Solid 5 (MGSV) animations

Post by MrAdults » Wed Oct 05, 2016 8:27 pm

daemon1 wrote:I'm doing this very rarely. Only if its absolutely needed, for some very complex procedures. Actually I never needed that for animations, only once for complex audio codec. Most of the time, its possible and easier for me to just analyze the data. And if it's something really complex, debug it for a while, but once I understand what it does, make my own code for it.
It's often easier/faster to just stare at data and try to intuit it. I've done this with complicated animation formats that use variable adaptive delta compression, but I don't recommend it. I suggest not giving into the temptation to avoid understanding and analyzing the associated code/disassembly given any real opportunity to do so, you're going to get better and faster the more you do it.

On the other hand, guessing at someone else's approach to something is based on your broad-spanning knowledge and intuition, and you're always going to run into walls when someone decides to deviate from all the norms or hasn't based their work on anything that's well-documented/researched already. So when you run into something like this and you need your disassembly muscle, it'll be weaker than it should be if you haven't been using it. This is also the difference between a problem taking 3 days and taking a month. If I need to spend more than 2 days of solid effort on something, that usually means it's time to disassemble. Every time I've violated that rule myself, I've regretted the amount of time wasted in the end. On console games, I'm always weighing the options because debugging and disassembling can be a huge pain in the ass for certain platforms. But on PC, it's a no-brainer.

And of course, when it comes to analyzing large amounts of disassembly, you're naturally going to save a lot of time by isolating the relevant code to be able to run more tests and interactively debug it without worrying about the state of the rest of the program. You always want to do this right away when disassembling with a purpose, and it takes virtually no time at all once you've worked out how it fits into your workflow.

TL;DR - Even if it's easy enough to guess at, missing the opportunity to strengthen yourself puts you in a self-perpetuating rut. If you find yourself spending too much time banging your head against the wall, you can probably be doing something smarter to get the answer you're after. I'll stop semi-hijacking this thread now.

daemon1
M-M-M-Monster veteran
M-M-M-Monster veteran
Posts: 1887
Joined: Tue Mar 24, 2015 8:12 pm
Has thanked: 48 times
Been thanked: 1424 times

Re: Metal Gear Solid 5 (MGSV) animations

Post by daemon1 » Wed Oct 05, 2016 8:43 pm

MrAdults wrote:...when you run into something like this and you need your disassembly muscle, it'll be weaker than it should be
But then when you run into something not like this and you need your analyzing muscle, it'll be weaker than it should be.

User avatar
MrAdults
Moderator
Posts: 1007
Joined: Mon Mar 23, 2009 2:57 am
Has thanked: 44 times
Been thanked: 498 times

Re: Metal Gear Solid 5 (MGSV) animations

Post by MrAdults » Wed Oct 05, 2016 9:20 pm

daemon1 wrote:
MrAdults wrote:...when you run into something like this and you need your disassembly muscle, it'll be weaker than it should be
But then when you run into something not like this and you need your analyzing muscle, it'll be weaker than it should be.
This is untrue. Understanding happens whether you do it the easy way or the hard way. Ease of analysis improves with understanding and knowledge. Wasting time with wrong guesses isn't actually helping you, because you aren't excluding possibilities for anything else you'll ever work on, just for the particular thing you're working on right at that moment.

So the "analyzing muscle" is actually going to grow more effectively if you're churning through problems efficiently to get to the root of the data and how it's intended to work, instead of wasting time banging your head against the wall for one thing. Not to mention, you may be making false assumptions about that data that you never catch or notice, because you weren't looking at the true source of its implementation.

daemon1
M-M-M-Monster veteran
M-M-M-Monster veteran
Posts: 1887
Joined: Tue Mar 24, 2015 8:12 pm
Has thanked: 48 times
Been thanked: 1424 times

Re: Metal Gear Solid 5 (MGSV) animations

Post by daemon1 » Thu Oct 06, 2016 5:34 pm

MrAdults wrote:This is untrue.
I disagree. I'm looking at this from a different angle. Let me just mention that my first assembler was a PDP system in late 1980's. Then 8080. I had to write my own disassembler for that, because there was no one on a particular platform, and I wanted to disassemble games for that. Then was 8086 and so on. I have almost 30 years of experience in both data analyzing and disassembling.
MrAdults wrote:Wasting time with wrong guesses isn't actually helping you
If you're good in analyzing, you don't have to make wrong guesses. All your guesses will be right. Have you heard about nonograms? Its very similar to it. You start from one corner, and one by one make it all out. There's no waste of time.
MrAdults wrote:you aren't excluding possibilities for anything else you'll ever work on, just for the particular thing you're working on right at that moment.
There are lots of tricks and methods in data analyzing. If you only disassemble, you'll never know these techniques, and will have no experience in using them. So analyzing does actually help. And not only for one case. And it doesn't depend on knowing common norms or well-documented things. When I first analyzed game archive, I had no idea how they're usually made, and that's why it was interesting to me. When I first analyzed sound files, I had no idea about adpcm codecs or usual segmenting/frame types. And that's why it was again very interesting to analyze.

Its a fact, that some people perceive visual data better than audio and vise versa. Can you admit that for some people, analyzing ability will grow more effectively when analyzing, rather than disassembling? I mean, in most cases reading the code will only confuse you and slow you down, but looking at the data will get you right to the point. So in most cases, disassembling will be a waste of time.

Not to mention that personally for me, disassembling is like instead of solving the puzzle, you're trying to find the answer in a big and badly organized book. That's not interesting. No fun. Every time I'm forced to use disassembly I feel disappointed.

User avatar
MrAdults
Moderator
Posts: 1007
Joined: Mon Mar 23, 2009 2:57 am
Has thanked: 44 times
Been thanked: 498 times

Re: Metal Gear Solid 5 (MGSV) animations

Post by MrAdults » Thu Oct 06, 2016 7:21 pm

daemon1 wrote:If you're good in analyzing, you don't have to make wrong guesses
How can you say this, when you've just spent weeks on an animation format? :) You know as well as I do, you will make guesses, and they will be wrong. Even if you have a limited set of possibilities, it's like using A* to pathfind - you can make good steps based on heuristics but you're still going to end up traversing nodes that you didn't need to because you didn't understand how to get where you were going when you started out. You've wasted time because you didn't collect the necessary data to start efficiently.
daemon1 wrote:I disagree. I'm looking at this from a different angle. Let me just mention that my first assembler was a PDP system in late 1980's. Then 8080. I had to write my own disassembler for that, because there was no one on a particular platform, and I wanted to disassemble games for that. Then was 8086 and so on. I have almost 30 years of experience in both data analyzing and disassembling.
You've been at this for even longer than I have. I got my first gamedev contract about 20 years ago, but have only been active in reverse engineering for maybe 10-15 years. But you could say that after 30 years, if relatively simple things still take weeks or months, it could be a problem with the methodology, or you just don't care about utilizing your time effectively. Sorry, I do respect the aspect of "fun", because there isn't much other reason to do this crap if it isn't fun for you in some way, but I also don't find it fun to have to tackle a single problem for weeks at a time unless the complexity or scale of that problem truly warrants it. When a format has many different facets that are taking that time justifiably, or I'm exploring something for new hardware that I'm not familiar with, then sure, great, that will take more time and give me new knowledge in the process. But instead of getting caught up on details like "which bit is signifying which packing format, how many bits are used in this mode, how many fraction/exponent bits are used for this custom floating point encoding, blah blah blah", save yourself all that time guessing and narrowing down your search potentials and just read the disassembly. Once you get into actual decryption or more elaborate forms of compression, this holds 200 times stronger.

Disassembling anything modern is certainly a lot different than it was 10, and I can only imagine 30, years ago. The difference in volume alone is staggering, and it requires many different methodologies to achieve efficiency.

Rather than solving a puzzle versus using a badly-organized book, at this level, it's blindly throwing A* at a nice uniform node grid when you have a starting node right in front of you that begins a perfectly visible linked list leading straight to your destination. The difference between being good or bad at reading through and understanding disassembly is the difference between going from one node to the next instantly or getting stuck at each node examining lots of useless pointers. It's a skill on its own that gets you faster, less frustrating results once honed properly.
daemon1 wrote:There are lots of tricks and methods in data analyzing. If you only disassemble, you'll never know these techniques, and will have no experience in using them. So analyzing does actually help. And not only for one case. And it doesn't depend on knowing common norms or well-documented things. When I first analyzed game archive, I had no idea how they're usually made, and that's why it was interesting to me. When I first analyzed sound files, I had no idea about adpcm codecs or usual segmenting/frame types. And that's why it was again very interesting to analyze.
Once you have the answer through either approach, maybe you've learned something new. But probably not. I haven't learned something new in reversing games in many, many years. I tend to learn all the new approaches and techniques that relate to game data through actual development instead. But it's certainly interesting to learn new things when you come across them. Using disassembly doesn't detract from this in the slightest, and it gives you better insight into otherwise-flawed assumptions you're going to make when you're first understanding data. Traditional "analysis" in the sense that you mean it leaves the door wide open for misinterpretation that happens to line up with your dataset. I think what you're missing here is that in the context of videogame data, you typically can't do anything very meaningful with reverse engineered data without understanding it anyway. Because you already have so much of this knowledge that your analysis and intuition is entirely contingent upon, maybe you've lost sight of how you acquired a lot of it, or made the mistake of thinking the way you acquired it was the only way to acquire it.
daemon1 wrote:Not to mention that personally for me, disassembling is like instead of solving the puzzle, you're trying to find the answer in a big and badly organized book. That's not interesting. No fun. Every time I'm forced to use disassembly I feel disappointed.
The book is very well organized, but if you aren't practiced in understanding how to effectively parse it to get the information you want, it will appear badly organized. This is rather speaking to my point. Again, if time/efficiency isn't important to you, then sure, take whatever approach you want. But when you start out, it's really undeniably easier to just stare at your hex editor and step through your process of elimination than it is to get down in the dirt and learn how to navigate a big sea of disassembled code.

I'm carrying on here because I think it's pretty important for beginners to take that step. Most of the people here don't take it, which prevents them from expanding into more areas of reverse engineering. I don't see a point to limiting yourself to a little puzzle-solving sandbox. It might provide you with some sense of fun and reward for a while, but keep it up for 5 or 10 years, and after a while it will just be depressing when you look back and realize you could've been building other useful skills alongside your efforts that entire time. You're advocating a methodology that will have that very result for beginners because they'll just stare at and "analyze" data as you're advocating, until they hit their fateful wall, and retreat back into the sandbox.

This is probably central to our disagreement, where you're looking at the methodology you "like" and that works for you, I'm looking at the methodology that provides the greatest extra-activity benefit and time efficacy. In practice, I rarely need to take the debugging & disassembly route, but it's pretty nice to have the option, and have it actually be a time-effective one at that. To me you sound like one of those people that says "I hate debuggers, I only use printf" because they haven't learned how to use a debugger. :)

Good talk! I wonder if anyone will ever find any of this useful.

Post Reply