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
P5R Animation backport (done)
- DeathChaos
- Posts: 12
- Joined: Sun Jun 07, 2020 4:40 pm
- Been liked: 6 posts
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;
and then edited the compressed key type Vec3 to also be applied to these key types;
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.
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;
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;
}
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.
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.
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?
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.
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).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
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?
- DeathChaos
- Posts: 12
- Joined: Sun Jun 07, 2020 4:40 pm
- Been liked: 6 posts
The oversimplified explanation is that PositionScale and ScaleScale are used by Atlus as a way to get more precision with their compressed key types.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?
I asked TGE about it some time ago and this was the answer he gave me;
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.
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 ^^.
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 ^^.
- chlorophylls
- Posts: 32
- Joined: Sun Nov 24, 2019 7:24 pm
- Has liked: 9 posts
- Been liked: 28 posts
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.
Created by ShrineFox. Maintained 2020 - 2024.
Support | Privacy | Terms
This site is NOT affiliated, associated, authorized, endorsed by, or in any way officially connected with Atlus Co., Ltd, Atlus U.S.A., Inc. or Sega Games Co., Ltd, or any of its subsidiaries or its affiliates.
Support | Privacy | Terms
This site is NOT affiliated, associated, authorized, endorsed by, or in any way officially connected with Atlus Co., Ltd, Atlus U.S.A., Inc. or Sega Games Co., Ltd, or any of its subsidiaries or its affiliates.