Page 1 of 2

P5R Animation backport (done)

Posted: Sun Jun 07, 2020 9:10 am
by Elvagan
Here you will find my GFD Studio Fork that will automatically convert P5R Animations to be loadable in P5 vanilla.

https://github.com/Elvagan/GFD-Studio

It's still not in a release state so you'll need to compile it by yourself to test it. But I believe some people might be interested with it :)
It's kinda usable as you can see in "Kasumi over Haru 2.0 beta" mod viewtopic.php?f=15&t=301 (Cheers to DniweTamp as it requires a lot of time to do the work for all animations in the current state :D).

The main breakthrough is that P5 can now load these animations without crashing, but there are still works to do on controllers as they a pretty messed up: some bones flips, the characters rotate strangely, etc. But 3dsmax is able to fix that (tested on version 2021, some versions seems to not handle it though, like 2020). The full process is explained in the readme, if you still have problems i'll try to help the best I can.

I'm still working on trying to understand why I get those glitches in the controllers and trying to eliminate the 3dsmax steps so if you have insights don't hesitate to share your ideas :)

Cheers

Re: P5R Animation backport (first steps)

Posted: Sun Jun 07, 2020 4:02 pm
by DniweTamp
This new GFD is simply amazing! With it I could even port the infamous crashing bf_0001_001.gap


Re: P5R Animation backport (first steps)

Posted: Sun Jun 07, 2020 5:19 pm
by DeathChaos
I have what i assume is the correct data for the new key types in P5R (type 34 and type 35).

Key Type 34 is 12 bytes per keys, and then ends with 24 bytes, because it is a compressed key, these 24 bytes are 2 Vec3s, PositionScale and ScaleScale (they are defined as such in other compressed keytypes in the gfd 010 template).

Key Type 35 is 14 bytes per keys, and then ends with 24 bytes, same exact deal as the above key.

So with that in mind, I have implemented them in the gfd 010 template as such;

Code: Select all

typedef struct
{
    TVector3Half Position;
    TVector3Half Scale;
} TKeyType34P5R;

typedef struct
{
    TQuaternionHalf Rotation;
    TVector3Half Scale;
} TKeyType35P5R;
and then edited the compressed key type Vec3 to also be applied to these key types;

Code: Select all

// Read scale values for compressed keys
        if ( KeyType == EKeyType_NodePRHalf   || KeyType == EKeyType_NodePRSHalf ||
             KeyType == EKeyType_NodePRHalf_2 || KeyType == EKeyType_Type31 ||
             KeyType == EKeyType_NodeRHalf    || KeyType == EKeyType_NodeSHalf || 
			 KeyType == EKeyType_34P5R        || KeyType == EKeyType_35P5R      )
        {
            TVector3 PositionScale;
            
            if ( version < 0x01105100 || KeyType != EKeyType_Type31)
                TVector3 ScaleScale;
        }
You can find the repo for the P5 related 010 templates here;
https://github.com/TGEnigma/010-Editor-Templates,
download everything here, and then replace the gfd template with my updated one from here;
https://cdn.discordapp.com/attachments/ ... /p5_gfd.bt.

So Key type 34 is,
(per key)
Half Floats for XYZ Position,
Half Floats for XYZ Scale,

And then after all the keys the compressed Vec3 Floats
Floats for XYZ PositionScale
Floats for XYZ ScaleScale

While Key Type 35 is,
(per key)
Half Floats for Quaternion Rotations (XYZW)
Half Floats for XYZ Scale,

And then after all the keys the compressed Vec3 Floats
Floats for XYZ PositionScale
Floats for XYZ ScaleScale

Hopefully this information helps you successfully convert more animations.

Re: P5R Animation backport (first steps)

Posted: Sun Jun 07, 2020 6:09 pm
by Elvagan
Thanks a lot for the infos :)

I was pretty sure Key35 was a rotation+scale controller (this is how i currently read it in my fork), I'm happy to hear i wasn't wrong ^^. So Type 34 is a Position + Scale controller? i had the feeling it could be that (being the last combination not covered yet by known controller) but I couldn't confirm it yet because I never encountered it in the animations I tested.
While Key Type 35 is,
(per key)
Half Floats for Quaternion Rotations (XYZW)
Half Floats for XYZ Scale,

And then after all the keys the compressed Vec3 Floats
Floats for XYZ PositionScale
Floats for XYZ ScaleScale
I'm wondering something. For the Type 35 I noticed that after the last key and before the PositionScale-ScaleScale values there is a bunch of 0s (3 x Int32). Do you have an idea what thiscould be? I'm currently skipping them but they might be usefull information (assuming they might not allways be 0s).

Oh and I was also wondering why do they set a PositionScale vector even if the controller does not controls the Position ? Is it a standard behavior for animations encoding?

Re: P5R Animation backport (first steps)

Posted: Sun Jun 07, 2020 10:45 pm
by DeathChaos
Elvagan wrote: Sun Jun 07, 2020 6:09 pm I'm wondering something. For the Type 35 I noticed that after the last key and before the PositionScale-ScaleScale values there is a bunch of 0s (3 x Int32). Do you have an idea what thiscould be? I'm currently skipping them but they might be usefull information (assuming they might not allways be 0s).

Oh and I was also wondering why do they set a PositionScale vector even if the controller does not controls the Position ? Is it a standard behavior for animations encoding?
The oversimplified explanation is that PositionScale and ScaleScale are used by Atlus as a way to get more precision with their compressed key types.

I asked TGE about it some time ago and this was the answer he gave me;
Image

For type 35, PositionScale will always be 0s, because type 35 defines rotation and scale, so Atlus set the PositionScale value to 0 as it is not used, so it's safe to skip for type 35 specifically.

As for where to find the new types, I know Makoto's combat animations (bb0006_051.gap and bb0006_052.gap) have a few controllers that use type 34, while Joker's combat animations themselves (bb0001_051.gap) have a few that use type 35.

Re: P5R Animation backport (first steps)

Posted: Mon Jun 08, 2020 2:20 pm
by Elvagan
Aaaand I'm done. Everything should work now, no need to use 3dsmax anymore and bone glitches shouldn't be here anymore.

Actually most of the problems were caused by me not double-checking what I was coding :D
The main thing was really just converting P/R/S/PR/RS/PS controllers to PRS controller and it worked.

It still needs extensive testing, so if you want to grab it and give feedback don't hesitate the repo is updated :)
I'll probably make a release once i get the time to.

Sadly this version is not compatible with Catherine Full Body, because it uses the same version number but stores their controller differently. I will probably add a switch in the UI to set GFD to work with P5R or Catherine, but it's not a priority for me right now ^^.

Re: P5R Animation backport (done)

Posted: Mon Jun 08, 2020 2:35 pm
by DniweTamp
This is just too good to be true, but it's real!

Image



Both of these were done by just using the new GFD,
also this mod exists now

Re: P5R Animation backport (done)

Posted: Mon Jun 08, 2020 6:41 pm
by chlorophylls
I'm inexperienced in this; how do you compile this so that it's runnable as an executable? :) Alternatively, if someone like DniweTamp could toss up their compiled version, that'd be appreciated too.

Re: P5R Animation backport (done)

Posted: Tue Jun 09, 2020 12:00 am
by Poipt
Open the .SLN in Visual Studio and then build the solution from the build menu.

Re: P5R Animation backport (done)

Posted: Wed Jun 10, 2020 2:38 am
by DniweTamp
He released a "beta" on a discord server