-
Notifications
You must be signed in to change notification settings - Fork 24
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
Comments
V1 has finally been implemented, here's the 1.0 release of cmc2OBJ: https://github.com/CommonMCOBJ/cmc2obj/releases/tag/v1.0 |
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:
More work overall, but I think it'll make the resulting code less hackish |
jmc2OBJ has now implemented CommonMCOBJ in version 124: https://github.com/jmc2obj/j-mc-2-obj/releases/tag/124 |
Forgot to close this. Completed in #555 |
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:
(none)
) in 3.6Overall, I think we're ready to start adopting support for it in MCprep
The text was updated successfully, but these errors were encountered: