MCprep icon indicating copy to clipboard operation
MCprep copied to clipboard

Moving Towards CommonMCOBJ

Open StandingPadAnimations opened this issue 1 year ago • 3 comments

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 avatar Mar 22 '24 21:03 StandingPadAnimations

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

StandingPadAnimations avatar Mar 23 '24 06:03 StandingPadAnimations

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 avatar Mar 24 '24 07:03 StandingPadAnimations

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

StandingPadAnimations avatar May 24 '24 15:05 StandingPadAnimations

Forgot to close this. Completed in #555

StandingPadAnimations avatar Jul 08 '24 02:07 StandingPadAnimations