SuperSmashNoob
Smash Rookie
- Joined
- Jun 5, 2014
- Messages
- 18
Hi guys, i'm trying to make a program that very accurately simulates NTSC melee's knockback system [hitbox/hurtbox interactions based on animations/frame data, accurate knockback velocities/trajectories, etc.]. I have the tools to do pretty much everything i want except accurately position/rotate hurtboxes during various hitstun animations [which is crucial for making the simulation accurate]. AFAIK, no one has been able to decode Melee's animation files, so I thought I was stuck. But Magus' debug mode tools lets you see the x/y/z positions of up to 4 hitboxes [which I imagine is the highest number any one move has at a time] which are themselves attached to bones and have x/y/z offsets from them [which I'm pretty sure are with respect to the bone's local orientation], and crazy hand lets you swap out subaction animations and alter their behavior. Which gave me this idea to determine melee's animations in a brute force manner. Note my terminology is probably pretty bad since i'm very new to this sort of thing. Also my methodology could probably be improved upon, so criticism is welcome. I also wouldn't be too surprised if a visualization dol mod like Magus' could display bone positions/angles frame by frame [I'd certainly like this to be made if it's possible, I have a sneaking suspicion that the top n value it displays is a base bone's position, but maybe not], in that case swapping subaction animations in crazy hand would be all that's necessary to determine the frame by frame positions/angles of the bones in a specific animation and it would involve substantially less work than my complete method below which assumes that it isn't possible. And finally if this idea has already been suggested and I simply couldn't find it when I searched through this forum, sorry to be a bother:
1] Start with a vanilla NTSC melee iso and apply Magus' debug visualization dol mod to it [as far as I know Crazy Hand doesn't utilize dol modifications so they should be compatible, correct me if i'm wrong though]
2] Open the iso in crazy hand. Choose a character and an arbitrary subaction, ideally one that is easy to trigger in game and has enough memory space to store bytes for what we'll do in step 4
3] Swap out it's default animation with whatever one you want to analyze [Say DamageFlyTop]
4] Alter the subaction so that all it does is play the desired animation fully, positioning up to 4 hitboxes active throughout the animation at the base position and at offsets from a bone [this can be accomplished fairly easily with timers and hitbox spawning]. My trig is a little fuzzy, but I want to say that recording, a bone's position from its base, from a fixed x-offset, and from a fixed y-offset is enough to determine the orientation of the bone, so spawn hitboxes accordingly. Note all this assumes that the bone hierarchy is known, but this shouldn't be to hard to determine with some experimenting [or it might be documented already]
5] If there is enough space in the subaction, repeat the process in step 4 by making the timer long enough to play the animation as many times as desired and spawn hitboxes at different bones and/or offsets for each repetition to capture data for all the character's bones. [Repeating animations in this way is possible afaik, it would certainly streamline the process of viewing the hitbox positions in debug mode by decreasing the number of times, or possibly removing the need to change the iso and reload it to capture all the animations desired].
6] Repeat steps 1-5 for as many animations as you want to/can analyze.
7] Load the modified iso in Dolphin. Pick a character you changed and perform one of the subactions you picked in step 2. With frame advance and Magus' hitbox position display, record the x/y/z positions of each hitbox [along with the bone and/or offset it corresponds to] and the topn position of the character on every frame of the entire action, including animation repetitions if any from step 5.
8] If you cleverly format the data from step 7, it wouldn't be hard to write a program that steps through it, subtracts the topn offset from everything each frame, performs the trig mentioned in step 4, and spits out the orientation of each bone each frame [accurate to like 3 or 4 decimal places] of the animation, success! I haven't thought about how scaling or bone offsets [if those are present] would be handled, it probably wouldn't be too complicated to account for them in step 4 though.
And there you have it. The whole process would be pretty painstaking [I was only planning on doing it for hitstun animations of top tiers], but a distributed [or perhaps automated with Dolphin Hooks? I haven't a clue about those, though] effort could decode all of melee's animations in this way. Of course the reason that people want to decode melee's animations probably isn't to fully understand the default animations, but to modify them, so I'm not presuming that anyone has my shared interest in simply calculating what the default animations are. Maybe having the calculated animations could help decode the animation file format, but this seems like a bit of a stretch given that the animations are probably keyframed and the calculations wouldn't be completely exact anyhow.
Thanks for reading and sorry for any typos.
1] Start with a vanilla NTSC melee iso and apply Magus' debug visualization dol mod to it [as far as I know Crazy Hand doesn't utilize dol modifications so they should be compatible, correct me if i'm wrong though]
2] Open the iso in crazy hand. Choose a character and an arbitrary subaction, ideally one that is easy to trigger in game and has enough memory space to store bytes for what we'll do in step 4
3] Swap out it's default animation with whatever one you want to analyze [Say DamageFlyTop]
4] Alter the subaction so that all it does is play the desired animation fully, positioning up to 4 hitboxes active throughout the animation at the base position and at offsets from a bone [this can be accomplished fairly easily with timers and hitbox spawning]. My trig is a little fuzzy, but I want to say that recording, a bone's position from its base, from a fixed x-offset, and from a fixed y-offset is enough to determine the orientation of the bone, so spawn hitboxes accordingly. Note all this assumes that the bone hierarchy is known, but this shouldn't be to hard to determine with some experimenting [or it might be documented already]
5] If there is enough space in the subaction, repeat the process in step 4 by making the timer long enough to play the animation as many times as desired and spawn hitboxes at different bones and/or offsets for each repetition to capture data for all the character's bones. [Repeating animations in this way is possible afaik, it would certainly streamline the process of viewing the hitbox positions in debug mode by decreasing the number of times, or possibly removing the need to change the iso and reload it to capture all the animations desired].
6] Repeat steps 1-5 for as many animations as you want to/can analyze.
7] Load the modified iso in Dolphin. Pick a character you changed and perform one of the subactions you picked in step 2. With frame advance and Magus' hitbox position display, record the x/y/z positions of each hitbox [along with the bone and/or offset it corresponds to] and the topn position of the character on every frame of the entire action, including animation repetitions if any from step 5.
8] If you cleverly format the data from step 7, it wouldn't be hard to write a program that steps through it, subtracts the topn offset from everything each frame, performs the trig mentioned in step 4, and spits out the orientation of each bone each frame [accurate to like 3 or 4 decimal places] of the animation, success! I haven't thought about how scaling or bone offsets [if those are present] would be handled, it probably wouldn't be too complicated to account for them in step 4 though.
And there you have it. The whole process would be pretty painstaking [I was only planning on doing it for hitstun animations of top tiers], but a distributed [or perhaps automated with Dolphin Hooks? I haven't a clue about those, though] effort could decode all of melee's animations in this way. Of course the reason that people want to decode melee's animations probably isn't to fully understand the default animations, but to modify them, so I'm not presuming that anyone has my shared interest in simply calculating what the default animations are. Maybe having the calculated animations could help decode the animation file format, but this seems like a bit of a stretch given that the animations are probably keyframed and the calculations wouldn't be completely exact anyhow.
Thanks for reading and sorry for any typos.
