-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Minor refactor to allow for saving AnimLayers #2307
Conversation
* The composer that owns this layer. Were it not for cloning, this field | ||
* would be final. | ||
*/ | ||
private AnimComposer composer; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
redundant field
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I decided to only save name and mask. The other fields felt like they're only interesting for runtime.
clean up unused imports
Note that in my case, it's actions that give me heartburn for not being persisted. But my memory is that there are more demons down that rabbit hole. But it does mean that for every model rig I load, I have to do a loop like this with my own external fix-up config: for( BlendInfo blend : blends ) {
BlendAction ba = anim.actionBlended(blend.getName(), new LinearBlendSpace(0, 1),
blend.getBlendedActions());
ba.getBlendSpace().setValue((float)blend.getDefaultBlend());
} Actions enter this weird area where I can see defining them one-off in code to do some particular thing... while also wanting to preconfigure some with masks and blending and so on. But also, every other thing in JME operates this way... if I tweak a "runtime to me" material parameter and then save that j3o then it gets saved. So I'm not sure I buy arguments against saving them. |
If I can find a use case from the SDK's perspective, I don't mind making Actions Savable too (I actually started it). But atm I don't see exactly how you would use them. In any case, that's for another PR. |
clean up a few rows
To enhance clarity and facilitate review, please submit the optimizations as a separate pull request (PR). This will prevent confusion and simplify potential rollbacks. By separating these changes, you can maintain the flexibility to revert optimizations without affecting the core functionality. Edit: |
Ok, everything looks good to me. Thank you. |
Does anyone have to officially approve it? Or do I just merge it? |
The project isn't very formal these days. Merge when ready. |
While working on this jMonkeyEngine/sdk#612 I found out that AnimLayers couldn't be saved.
Tested in local SDK.
I'll look it over once more before turning into a proper PR.
The tests don't explicitly test the changes, just general AnimComposer behavior.