Pokémon Model Ripping Project

[Fallenleader]

I tried to re-import Garchomp and Aggron after downloading the latest version of Spica. Aggron is now working perfectly! Unfortunately, Garchomp wasn't that lucky, as it's still as broken as before.

I suspect that's actually a problem with Blender, otherwise I don't think Unity would be able to get the bones working either. Would anybody with Blender please try to save a Garchomp model in .blend format and see if its animations are working correctly to see if it's just me?

I am curious on how you are exporting pokemon animations, though I have noted this issue report on Git for SPICA.


personal experiences:
(U)S/(U)M scaling is exactly 0.8X larger than XY. You are still scaling it 0.05X larger than a typical model of a proper 1x scale factor. If you plan on using X/Y/OR/AS models, you will want to amend this.
You are importing anims the PITA way. Blender is not necessary at all, and could even be breaking them. Just make a folder (e.g. Animations\PokemonName) and drop the exported anims into there. then you dupe your anim clips, and rename them as desired in the properties that shows when you click on it. General rule of thumb, use a standardized naming scheme, e.g. Idle, Attack1, etc. this will make life MUCH easier if you will be targeting animations (like a pokemon remake for example) where your battle code could have a process like:
GetAttack()
{
doAttack();
Animation(Attack1);
}
(do note this is very much pseudocode).
If the anims ripped properly, you can even ignore the extra data and simply leave the imported data as is, as the overhead in them is small, as the dae really only holds the animation data itself, the rest seems to be "generated" by Unity and use a minuscule amount of additional resources. even a complete project with that extra data shouldn't eat more than 10MB at most at worst case.

I don't understand this too maybe gamefreak was too lazy to make the other team leaders with the same quality

Optimization purposes, probably. When you're a game developer, chances are you're gonna make a few shortcuts in order to meet a budget and/or deadline.

I believe that those new models are also used on overworld scenes (with other characters and buildings n stuff), so a high poly model would be too much for the old 3ds gpu. They can afford using those high poly models in-battle because they only have a few models there.

But both models have about the same polycount, also the overworld models are not the same, they lack fingers and use lower resolution textures, the only logical reason is that a much younger team was behind the "new" games, they could very well use the x/y model for battle stuff and cinematics, but they didn't for some unknown reason and decided to remake it with much lower quality, same goes for maxie and archie of team magma and aqua, they instead decided to remake the old models instead of reusing the much higher quality ones from oras, they spent more time remaking models than actually making something new for the "new" games

PS: don't take this personally haha just a little grudge I have against these ultra games, they feel like a huge excuse for some quick cash

I can share my understanding of this to some extent. Pardon me being cryptic, as some of this info cannot be expanded on due to NDA. if you want to understand it better, go sign up and start developing for the device.
Gamefreak has 2 main approaches to how they use models:
Overworld models, which have less bones, animation data, and lower res textures, and less ploys (I dare you to prove me wrong here, as more polys are needed for separated appendages such as fingers).
Battle models, which have higher quality textures, sport more bones and separated appendages, and hold more animation data.

I have been working with the 3DS for a while now, and can explain to a degree why they do it this way:
Overworld has the additional load of being modeled as well, whereas battle scenes have simplistic and texture reliant backgrounds. This means they needed less resources in the overworld, and had more room to use more resources in battle, since the focus of the models and textures shift.

Their rendering pipeline is far from optimized, even up to USUM. I am achieving full 3D with 16 Battle models of Bulbasaur (animated), Red (animated), Santalune forest (sporting transparency), and dummy samples of particle effects for additional load. I am achieving 3D, albeit with severe frame drops (thanks a lot 16 bulbasaur). By shrinking this down, I am able to craft a full Viridian forest "clone" with over 60FPS on average. I have the additional bonus that I am not using their version of cel shading, or outlines for now, despite having clearly enough resources to even do that without negative effects.

This prompted me to investigate further. Aside from the bad rendering pipeline, they also attach another model ("low poly") to use as the pokemon's shadows, and even animate that. This is an effective 6 animated models in single battles, 8 models in doubles, and 12 models in battle royal. Sound similar to my mention of 16 bulbasaur PLUS my additional models and resources causing lag? Same effect with more resources to spare on my Unity project. The main difference my project has: I am not using another model for shadows, as I have better control over lighting and generating more convincing shadows without the performance hit, AND I still have resources to spare for 3D at all times. This could change, but ultimately it boils down to the fact GF is literally peaking their asset usage in a poor rendering pipeline that results in them being forced to take shortcuts in the over world as they have a LOT of data being stored in VRAM + whatever overhead their rendering pipeline uses in the background.

Lastly, I cannot reveal exactly how much ram the device has free, but I can definitely say that even in Extended Memory Mode, it is far less than the devices 128MB (O3DS). There is also a good chunk of that being used for the core of the game, so that gives even less to use towards graphics (some ram is used as swap, storing, and preloading models and textures). This causes additional rendering times, albeit on well smaller of a scale to be very noticeable since ram is fast.
Let me point this out though: For all it's coding flaws, (Ultra) S/M Is an amazing technical feat in that it actually runs in the quality it does on the 3DS. The only way they could improve it further would be to fix their rendering pipeline and do further optimizations to the engine itself, and even then it wouldn't guarantee overworld models would be able to be a higher poly count, or that 3D would be an option.

Also gdkchan, the Old and New 3DS GPU are identical. The primary changes was additional ram and a CPU clock boost, as well as the face tracking for 3D. While ti can perform better due to no longer being bottle-necked by the CPU, it still is limited in VRAM. This is also noticeably evident as the N3DS will also lag at times (mainly on the Battle Royal where the CPU boost can't compensate for limited VRAM).