Model Research

[SmashMods]

I'm making this thread for anyone who wants to contribute to model / character research for SSB64. From what I can tell, the model format itself has already been deciphered. The bigger issue is figuring out how the game loads the models, character attributes, etc. To explain why this is the issue, swapping the character model file from one character to another will cause the game to freeze. In order for a character mod to be successful at this point, no data must be added or removed from the character file. Thus vertices can only be modified rather than added.

I don't think the game can be analyzed with IDA since it is compressed. It can be decompressed but, but at this time I'm still not sure how that could be used with IDA.

When the ROM is decompressed with midway dec it yields a file called fileloader.bin. I've noticed that at the end of this file, it has a list of variables with format specifiers (eg: %d for integer or %x for an unsigned int). The things here look like function names or results such as atk stat, weapon kind, BF addr, GP thread, DFC addr, DFO cam addr, disp addr, etc.

This looks to be a lot of character specific information, and I'm thinking that wherever one of these things is declared, the other is close by. My initial thought is to search for master hand's 300% initial damage just to get a starting place. I believe damage is stored as an unsigned int but I could be wrong.

Let me know what you think or discover.

 

[L-a-t-e-r-a-l-u-s]

Thanks for making a separate thread for this, when I get some free time I'll try playing around with the data myself.

 

[Cyjorg]

Good post.

From what I can tell, the model format itself has already been deciphered

Kali-Yuga show me the way.

Seriously if you actually understand this, I can easily play around with the file size. I managed to shrink the Dream Land background size (it shared between the beta stages and the in game one) to like 16th of its size by changing pointers. Size shouldn't be the issue.

Edit: lost the notes but it shouldn't be hard to recreate

 

[Deleted member]

I am down, but probably only Jigglypuff and Yoshi specifcally.

 

[Cyjorg]

Couldn't sleep so I started looking into Roja's rom to see what's going on with the Falco/why it doesn't work on console. Few interesting tidbits.

1. The Glide64 graphic plugin does not like his model at all. In fact, it's clear after seeing it in this form that he did exactly what I said not to do from the beginning to make the model, he just changed vertices and palettes until the model was passable for Falco.
2. He definitely messed up something RAM wise. The area of RAM never used in vs (and the area I have all my 0.11 functions for 19XXTE) is used. If he tried to DMA data at the wrong time, he could easily have crashed the game (something both tehz and I struggled with for a long time).

Edit: no changes in code. Not a DMA issue.
Edit: um idk how 19XXTE 0.11 is crashing constantly lol

I'll keep looking into it and let you know if I find anything.

 

[Enigami]

L-a-t-e-r-a-l-u-s had asked for a polygon limit for character models in the Falco thread, and I think I've got some idea of what it could be. I'd expect Link to be the most complex model, and looking at the ripped model from Models Resource:

Link
-291 Vertices
-338 Triangles
-1 32x72 texture
-6 32x32 textures
-8 16x32 textures (+3 for alternate costumes)
-7 16x16 textures
-2 8x8 textures
-14,464 combined pixels for textures

Then we have Mario:
-136 Vertices
-200 Triangles
-1 192x96 texture
-18,432 combined pixels for textures

It seems that the target number of vertices / triangles for a character model are about 150-300 vertices and 200-340 triangles.

Mario & Link look like they were ripped with different methods, so I don't know if Mario's textures were originally split like Link's and the info I give here is inaccurate, but it looks like 128x128 total pixels is a safe upper limit of texture space to work with.

Until animations are figured out, there probably isn't any way to get solid numbers for animations, but especially with Frame Display it shouldn't be too hard to eyeball and guesstimate things like bone count, keyframes, etc. and get a head start on that if you wanted.


Of course, even with the ability to import models or even animations, you're pretty limited in what you could add as new characters without the ability to clone and edit things such as projectiles or items, modify the game engine, etc.

Ganondorf would probably be the easiest to add, since you could have a perfectly serviceable Ganondorf just by editing Polygon/Clone Falcon's model, texture, properties (like weight and run speed) and frame data. All the other Melee clones shouldn't be too hard either, but I don't know how projectiles/items work and how hard it'd be to edit Falco/Dr. Mario/Pichu/Young Link's projectiles to have different damage/knockback/etc. Young Link would probably be the hardest clone to make if you wanted clones to have different properties for their projectiles because I'd expect you'd have to figure out how to clone items to make his bombs different from Link's.

If animations/projectiles are worked out, Bowser, Charizard, Ivysaur, Lucas, Mewtwo, Wolf, Zero Suit Samus and maybe King Dedede should be possible since I think all the mechanics/projectiles they'd need (especially since they drop a Special move) are already present in 64. Adding Counter mechanics from there I think would make it possible to add Marth, Roy, Lucina, Ike, Little Mac, Lucario, Greninja and Corrin as well. From there I'd expect the rest to require some degree of hacking for each individual character to make them accurate to how they play. L-a-t-e-r-a-l-u-s said he wanted to make Peach, but I expect Peach would be one of the harder characters to add because of needing to add the mechanics for her float, counter (for toad) and turnips (item cloning). I'd expect though that no matter how talented hackers for the 64 scene become, Ice Climbers, Rosalina and Olimar would never be possible.

 

[L-a-t-e-r-a-l-u-s]

Yes thanks, I figured it was around that as I was glancing at the player models myself in gameplay. Falcon/Link/Samus to me seemed like the most polygonal, but I never actually checked the numbers so thank you! As far as characters, I figured I'd be sticking with the obvious ones at first. Ness/Lucas, Falcon/Dorf, Pikachu/Raichu/Pichu, Fox/Falco etc. Peach is just something I'd like to see happen at some point some day at some time. No expectations or anything haha. Textures are less of an issue as I can test most textures using an HD Texture Replacement Plugin to get it all figured out.

 

[Cyjorg]

Then we have Mario:
-136 Vertices
-200 Triangles
-1 192x96 texture
-18,432 combined pixels for textures

It seems that the target number of vertices / triangles for a character model are about 150-300 vertices and 200-340 triangles.

Mario & Link look like they were ripped with different methods, so I don't know if Mario's textures were originally split like Link's and the info I give here is inaccurate, but it looks like 128x128 total pixels is a safe upper limit of texture space to work with.

That 192x96 texture causes issues for sure. I was messing around with @mib_f8sm9c obj to f3dzex and couldn't get Mario to load because of it.

Ganondorf would probably be the easiest to add, since you could have a perfectly serviceable Ganondorf just by editing Polygon/Clone Falcon's model, texture, properties (like weight and run speed) and frame data. All the other Melee clones shouldn't be too hard either, but I don't know how projectiles/items work and how hard it'd be to edit Falco/Dr. Mario/Pichu/Young Link's projectiles to have different damage/knockback/etc. Young Link would probably be the hardest clone to make if you wanted clones to have different properties for their projectiles because I'd expect you'd have to figure out how to clone items to make his bombs different from Link's.

At this point, the only limitations are what we can change. If it's possible to edit Link's bombs to behave differently (I know nothing about character editing so idk), then we can make them behave differently between the two characters.

 

[Cyjorg]

https://sites.google.com/site/flotonic65/modding/n64zeldadoc/zobjformat

Edit: for anhyone looking into this like me, the "01" type appears to be the same except that XX XX is 8 times lareger than YY istead of 2 times.

Edit: No I'm wrong. It varies.

http://wiki.cloudmodding.com/oot/F3DZEX

"All the model information inside the ROM appears to be of identical format to Ocarina of Time (minus the .zobj hierarchy information, I have found similar data but I haven't figured out how it works yet).
So it's not hard to do manipulation to the data like moving vertices or editing texture information.
But I'd prefer to start with texture modification before moving vertices.
Texture modification is something that can be done simply and effectively, and we could release it to the public and let them play with it without their needing much romhacking experience.
It won't allow for increasing texture resolution yet, but it'll be a nice toy that people can play with and let them know that we're serious about making an editor.
Vertex editing is more difficult since all the vertices are grouped together, and there's no real clear indication of which vertex belongs to what object, and finally changing vertices can really screw up the texture offsets and make them look awful."

This is a conversation SoundBlitz had with mib. Didn't know what "zobj" was at the time so I completely overlooked it. However, the FA command alone is so useful (look at mario's nose and ears).

I'll be looking at this stuff all day honestly.

Edit: yeah no this is 100% where we need to be looking (01 display list hype)