Skip to content

Local Space Transforms #38

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open

Local Space Transforms #38

wants to merge 4 commits into from

Conversation

d87
Copy link

@d87 d87 commented Sep 14, 2024

Solves #36
Mostly taken from Ktisis.
The existing GetDescendants method was broken it seems.

MiqoTail.mp4

@RisaDev
Copy link
Member

RisaDev commented Sep 25, 2024

Hello. Thank you for your contribution. Unfortunately this cannot be merged as is. Contributing section of repository readme was written specifically to avoid such issues.

One of the biggest problems with your code is that it is not backwards compatible. Merging this will break majority of user templates. The solution for it would be to include a checkbox for every bone in the bone editor UI which will control if entered values should be propagated or not. It should probably be on by default, but it should be confirmed that older templates load with this option being off.

I would also like to ask you to research possible options of extending this functionality to scale option of the bones if possible.

There is also an issue of Ktisis and Customize+ licenses not being compatible. It should not be a huge issue, but we will have to ask Chirp for permission to re-use Ktisis code if this is to be merged. This is something I can deal with myself, but this is important to mention.

I also have several issues with various things in the code but those can be wait until this PR is implemented in a way that doesn't break existing functionality.

@d87
Copy link
Author

d87 commented Sep 29, 2024

Hi, I added checkboxes for all 3 types. And you can even scale the head now.
Scale definitely shouldn't be propagated by default or mashed with translation & rotation.

@RisaDev
Copy link
Member

RisaDev commented Sep 29, 2024

Hey, that looks really good. I assume there is no way of making scale compatible with the other two options? People will definitely be asking about that feature so I need to know if this is just something that is too much hassle to implement properly, technical limitation or something else.

Also there seems to be some issues when using both position and rotation, at least for the head bone. I assume nothing can be done about that as well?

image
Values to recreate that issue (head bone):
Rotation Yaw: -23.500
Position Y: -0.136

Also there seems to be some really weird thing with head bone not being affected by parent bones? You have any idea why that might be the case?

@d87
Copy link
Author

d87 commented Sep 30, 2024

No, scale IS compatible now. I just mean I split them into 3 settings because scale shouldn't be mixed with the rest into a single checkbox, as it is not propagated in Anamnesis/Ktisis/Blender, and it's just perfectly fine as it is mostly, it's easier to think about it when it's not.
Scale propagation is just for fun
image

Also there seems to be some issues when using both position and rotation, at least for the head bone. I assume nothing can be done about that as well?

Yep, some kind of face rigging magic is going on there I assume

Also there seems to be some really weird thing with head bone not being affected by parent bones? You have any idea why that might be the case?

I think it's something about these eyelid/lip bones not always getting correctly registered as children, no idea why
For me this only happens on Vieras, and even then far from always apparently.
When I start the game with Viera character in the login screen, then it's always fine. And once it works, it works for the rest of the session.

On the screenshot above everything was fine no matter what I did, then I restarted the client and...
image

@RisaDev
Copy link
Member

RisaDev commented Sep 30, 2024

No, scale IS compatible now. I just mean I split them into 3 settings because scale shouldn't be mixed with the rest into a single checkbox, as it is not propagated in Anamnesis/Ktisis/Blender, and it's just perfectly fine as it is mostly, it's easier to think about it when it's not.

Ah, I see. I thought you meant a different thing because I've noticed that it seems like scale doesn't work super well sometimes when used alongside with rotation and position, but I assume it's just what we'll have to accept as this seems like the same thing as with rotation and position when they are used simultaneously.

I don't really have time to review this properly at this moment, so I will leave this open for now. It is likely I will just merge it and do necessary changes/refactoring myself unless there there are serious issues.

@RisaDev
Copy link
Member

RisaDev commented Oct 26, 2024

Just wanted to give a quick update that this is scheduled to be reviewed for the version after 2.0.7.0

@d87
Copy link
Author

d87 commented Dec 9, 2024

So? It's been 3 months

@RisaDev
Copy link
Member

RisaDev commented Dec 9, 2024

I am busy with other things not related to XIV. Other features/bugfixes also had higher priority than this one, I will work on this one eventually but as of today I have no ETA as there are several things to consider which prevent me from just dropping this into c+ as is.

@RisaDev
Copy link
Member

RisaDev commented Feb 13, 2025

Small update on this - after careful consideration I decided it is not a great idea to merge this without ability to use this functionality with all available bone edit modes (position, rotation, scale) at once. Merging this as is will lead to a lot of confusion and will introduce issues down the line if this functionality gets necessary changes to fix current behavior.

I have spent around 5 hours trying to figure out possible solution and haven't really been able to come up with anything. I have also tried to find someone who can help me with figuring that out but no one really shown any interest.

I will keep this opened in case someone is willing to work further on this functionality.

@d87
Copy link
Author

d87 commented Feb 14, 2025

Man, do you think the current way of doing translation and rotation without propagation isn't confusing? it's so confusing and broken and it might as well not exist too.
And tbh I'm not sure what are you even talking about? All 3 worked as i remember, at once too, besides those issues with the eyes/eyelids, but they weren't happening because the math was wrong.

@d87
Copy link
Author

d87 commented Feb 14, 2025

Ah, you mean the face bones not working with rot+pos? Idk, disable propagation on the face bones if you want.
But what's the worst that's gonna happen? Someone will write a message?

@Warpholomey
Copy link

I was surprised to find that this pull request hasn’t been merged so far. It’s a useful change that I was really counting on. What are the next steps needed to get this PR approved?

On a side note (admittedly not the most representative sample, but based on everyone I’ve talked to): my friends don’t use the translation and rarely use rotation because, in its current state, it "breaks" the character model. If the concern with this PR is that the new settings’ behavior isn’t intuitive, I’d argue it’s already unintuitive as-is.

There are popular plugins that condition players to expect specific skeleton behavior when rotating or moving bones (e.g., Brio, Ktisis, and tools like Anamnesis): shifting or rotating a bone affects all bones attached to it. I’m convinced this behavior is more intuitive than what Customize+ currently does.

It’s worth noting that after DT’s release, issues with facial bones affected all the aforementioned plugins/tools. In my opinion, having propagation work for the entire skeleton except the head is still better than no propagation at all.

@RisaDev
Copy link
Member

RisaDev commented May 22, 2025

I already said what the issue is and how I expect it to be handled. The code which doesn't work on some bones and the explanation for that is "This code is taken from ktisis and we have no idea why this is going on" is not something that I consider reasonable releasing for 50.000+ people.

Even if I agree to releasing it with some bones disabled I still need a reasonable amount of research to be done and provided to me into what is going on. Because once this gets merged all of you will be gone and I am going to be the one who will have to deal with it if it explodes or cannot be refactored later because everything relies on it possibly working incorrectly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants