MCprep 3.6 RC-2

[StandingPadAnimations]

This is the second release candidate for MCprep 3.6 (apologies for the long wait). Although not yet merged (#555), we feel CommonMCOBJ support in MCprep is ready enough for testing, hence this release candidate.

We highly encourage using CommonMCOBJ worlds, as we plan to phase out support for legacy worlds (by default at least) by the release of MCprep 4.0. See the list of exporters on the official CommonMCOBJ organization for which versions do CommonMCOBJ exports.

With CommonMCOBJ support, some changes are brought to how worlds are imported:

• CommonMCOBJ worlds now have their data imported and handled
• Legacy imports now have their exporter attached to a property, rather than it being thrown out. This is to ease the transition from legacy worlds to CommonMCOBJ
• All worlds are now parented to an empty
  • For legacy worlds, this is for convenience and consistency, and is located at the origin
  • For CommonMCOBJ worlds, this empty holds the CommonMCOBJ data for the OBJ (as such do not delete the empty), which MCprep references, and is located within the export region (thanks to CommonMCOBJ data); for most exports, this means the empty is located slightly above the OBJ, in the center
• The exporter selector on the top of the MCprep panel will not be automatically set for CommonMCOBJ imports.
  • This is because we now get the exporter directly from the OBJ itself (if it uses CommonMCOBJ), so this is no longer necessary. If one wishes, it can still be set manually, but it will be ignored for CommonMCOBJ imports
  • We plan to keep the selector until MCprep 4.0, at which point it will be hidden by default and require enabling in preferences

This RC is based on 6cfb455

---

This discussion was created from the release MCprep 3.6 RC-2.

[TheDuckCow]

We are keen to hear tester feedback! We know there are a couple things that might be rough, please be specific in your responses if you have any issues so we can investigate accordingly.

[StandingPadAnimations]

Anything in MCprep other then assets is version independent

[Dinohunterandmuncher]

AWESOME!!!! So with the assets deal in mind, when will the assets be updated? or is that the bottom of the to do list?

[StandingPadAnimations]

JSON models and items are updated quickly. Rigs are community maintained, so they only get updated when someone submits a rig for a particular mob

[Dinohunterandmuncher]

Thanks for the info! so with this in mind where do I go to offer rigs that I make? for example, if I upgrade the zombie rig so that it's more intuitive.

[StandingPadAnimations]

Asset sunmission form

[StandingPadAnimations]

Some additional info (last updated: June 17th, 2024):

• Q. What is CommonMCOBJ?

  • A. CommonMCOBJ is a common standard created alongside the developers of Mineways and jmc2OBJ to unify OBJ exports and the information they export.

• Q. Do I need to do anything extra in order to use CommonMCOBJ? \

  • A. No, CommonMCOBJ exports are the standard with jmc2OBJ 124+ and Mineways v11.07+.

• Q. What is the timeline for phasing out legacy imports?

  • A. We currently have the following timeline set:
    • MCprep 3.6: Introduce CommonMCOBJ support.
    • MCprep 3.7: Add the legacy imports compatibility option but have it enabled by default.
    • MCprep 3.9 (not yet decided): Experiment with disabling legacy imports compatibility for A/B testing purposes.
    • MCprep 4.0: Disable legacy imports compatibility by default.

• Q. After MCprep 4.0, what will happen with Blend files that use legacy imports?

  • A. Depends on how those worlds were imported:
    • If imported with either Blender's OBJ importer or the MCprep importer pre-3.6, legacy imports will be treated as regular Blender objects and not as Minecraft exports. This means features such as meshswap and textureswap will be disabled.
    • If imported with MCprep 3.6+, legacy imports will be treated as Minecraft exports, but features will be lacking as MCprep moves towards taking further advantage of CommonMCOBJ.

• Q. Will new MCprep features related to Minecraft exports be backported to legacy worlds?

  • A. If they depend on CommonMCOBJ data (which most likely they will), no, legacy worlds simply do not contain enough information for us to use.

[TheDuckCow]

Just to comment my own POV,

Q. What is the timeline for phasing out legacy imports?

I'm not sure we really need to commit to a timeline, or even commit to phasing out the old imports. We want to stay flexible and be able to handle obj imports from even new world exporters that might pop up but haven't been able to implement to spec yet. As long as we have the unit tests and sample files in place, it's not much if any overhead to keep the legacy imports present imo.

I do agree with the point that some features may not be available for legacy imports however, that's entirely fair.

[StandingPadAnimations]

As long as we have the unit tests and sample files in place, it's not much if any overhead to keep the legacy imports present imo.

The option would still exist for those that need it, just that it would be disabled by default after MCprep 4.0 (and even then it would be intended for old Mineways and jmc2OBJ exports).

Granted, that will certainly cause issues for users, but here's the way I see it:

• Exporters wanting full MCprep "integration" (i.e. support for meshswap, textureswap (since that is based on texture type), animate textures, etc) should adopt CommonMCOBJ at some point. By restricting imports to CommonMCOBJ ones at a certain point (by which CommonMCOBJ should become widely adopted), it encourages developers to adopt the standard. Otherwise, there really isn't incentive for developers to adopt it
  • We could make some prep material checks "in blender" as a fallback (for example, checking if an import uses individual textures or not). That way, developers could import through File > Import > Wavefront OBJ and still be able to test some features in MCprep that would normally be locked
  • We could also name the future compatibility option as "Allow non-CommonMCOBJ worlds" though, since that's a bit more descriptive and better explains what it does
• Legacy imports will always be categorized as either Mineways or jmc2OBJ, which isn't friendly to new exporters
• When we talk about phasing out legacy imports, it also includes recognizing existing imports as Minecraft exports in older files (specifically pre-3.6). Although some of these may have a few properties (like texture type), they're missing other properties like exporter name.
  • MCprep 3.6 helps ease the transition, as any legacy imports in MCprep 3.6 will be recognized as Minecraft exports, even after we phase out legacy import support

I am open to alternatives when it comes to legacy imports, however, I think phasing them out (which really means disabling support by default but still allowing users to opt-in) is the best option long term.

The timeline given is also not absolute; MCprep 4.0 is currently selected since by then CommonMCOBJ should be adopted more widely, but if it isn't by then, we could always push it back.

[TheDuckCow]

As I said, I'm in favor of not offering certain functionalities for imports that don't have the data we need. But at least for things like a simple layer on top of an OBJ import, no reason to disallow that as it does come up that one needs to import old OBJ formats. I do get the point of incentivizing, but better to incentivize with new features rather than feature reduction unless it actually represents less code (texture swap will still require the mapping json either way). If we are extending texture swap to depend on commonmcobj then sure, but users should still be able to at least import + prep materials I'd argue as that's the majority of value that many people get out of it.

When we do get to 4.0 or the equivalent, we can also make the call based on % of users still importing old obj formats, another motivator for getting that data right. That way we can be more confident that we're affected e.g. less than 5% of users or some threshold like that.

Anyhow, I think we're at least align that there's no immediate impact. Much of the above depends on how much it hampers our other plans to make use of the format.

[TheDuckCow]

Noted a couple things with meshswap and also the mapping file / reconnected textures function:

#555 (comment)