Skip to content
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

Moving Towards CommonMCOBJ #553

Closed
StandingPadAnimations opened this issue Mar 22, 2024 · 4 comments · Fixed by #555
Closed

Moving Towards CommonMCOBJ #553

StandingPadAnimations opened this issue Mar 22, 2024 · 4 comments · Fixed by #555
Assignees
Labels
enhancement Feature requests or new functionality suggestions
Milestone

Comments

@StandingPadAnimations
Copy link
Collaborator

As we get closer to finalizing CommonMCOBJ V1, I think it's time we start planing out how we should introduce support. Since the initial spec is simple, I think we'll be able to add support for 3.6. On the CommonMCOBJ side, there is now an OBJ exporter (forked from jmc2OBJ) called cmc2OBJ, which acts as the reference implementation for the CommonMCOBJ spec, so verifying compatibility with CommonMCOBJ should be trivial.

While CommonMCOBJ would make the current Mineways/jmc2OBJ options obsolete, I don't think it would be a huge maintaince burden to at keep them in MCprep, however they will become redundent for most use cases as time passes. As sucb, here's what I think we should do for those options:

  • Add some form of analytics tracking CommonMCOBJ usage, to get an idea of how often its being used
  • Add a CommonMCOBJ option where we have Mineways and jmc2OBJ options (replacing (none)) in 3.6
  • In MCprep 4.0 (assuming we're not skipping 3.7-3.9), if adoption is going well, then create a legacy option in user preferences (for exposing distinct OBJ exporter options), and completely eliminate user facing OBJ exporter selection by default
    • This would not eliminate special handling for individual exporters, as CommonMCOBJ gives that information anyway

Overall, I think we're ready to start adopting support for it in MCprep

@StandingPadAnimations StandingPadAnimations added the enhancement Feature requests or new functionality suggestions label Mar 22, 2024
@StandingPadAnimations StandingPadAnimations added this to the v3.6.0 milestone Mar 22, 2024
@StandingPadAnimations StandingPadAnimations self-assigned this Mar 22, 2024
@StandingPadAnimations
Copy link
Collaborator Author

V1 has finally been implemented, here's the 1.0 release of cmc2OBJ: https://github.com/CommonMCOBJ/cmc2obj/releases/tag/v1.0

@StandingPadAnimations
Copy link
Collaborator Author

I've been working a bit on this, and it seems like it won't be quite straight forward. In particular, contrary to what I initially assumed, keeping the explicit exporter options as is will be a bit of a burden and require hacks, unless we first remove them and then reimplement them.

I think if we want to implement CommonMCOBJ support, we have to do the following:

  • Remove the existing explicit exporter options and checks
  • Refactor all OBJ handling for CommonMCOBJ support
  • Reimplement explicit exporter options around whatever we've implemented for CommonMCOBJ, as well as reading properties on pre-CMC OBJs

More work overall, but I think it'll make the resulting code less hackish

@StandingPadAnimations
Copy link
Collaborator Author

jmc2OBJ has now implemented CommonMCOBJ in version 124: https://github.com/jmc2obj/j-mc-2-obj/releases/tag/124

@StandingPadAnimations
Copy link
Collaborator Author

Forgot to close this. Completed in #555

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Feature requests or new functionality suggestions
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

1 participant