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

Create backwards compatibility option for rig spawning. #317

Closed
TheDuckCow opened this issue Jul 10, 2022 · 1 comment
Closed

Create backwards compatibility option for rig spawning. #317

TheDuckCow opened this issue Jul 10, 2022 · 1 comment
Labels
enhancement Feature requests or new functionality suggestions
Milestone

Comments

@TheDuckCow
Copy link
Member

TheDuckCow commented Jul 10, 2022

The problem: Rigs made in blender 3.0+ aren't backwards compatible in a number of ways, and we are getting community contributions for mobs made in Blender 3+. The options would be:

  1. Completely drop support for rigs for old versions of blender, so those hanging on to old blender versions like 2.7 simply don't get the new mobs (not ideal)
  2. Create an alternate, minimal version of the rig for older blender versions via exporting of an FBX with most bones stripped down. Accept that no custom shapes, drivers, or constraints will survive.
  3. Completely remake the rig in blender 2.93 and follow the historical process to further make it backwards compatible to 2.7 (which itself is an arduous task, but has little to no loss of constraints/material shading/drivers/bone shapes when performed).

The proposal is to go with option 2) above so that we don't have to keep asking people to make rigs in very old versions of blender (as even 2.93 will feel old soon). The steps to perform to execute against option 2:

Manual steps, pre-MCprep build

  • Create a second copy of the given rig blend file
  • Export the asset to FBX, de-select "add leaf bones".
  • Import in a suitable version of blender (ideal is actually blender 2.79, to save steps in the future)
  • Do whatever minimal steps to make it work for general use. Likely requires using prep materials in cycles, and at most some minimal shader updates if it makes a big difference.
  • On a case by case basis, add some limited functionality constraints. But otherwise, just delete all the bones that are no longer necessary (e.g. IK poles and property-holding bones). And change the scale or type of bones to make it easier to see, since there won't be any custom bone shapes.
    • While it could theoretically be possible to script the transfer of bone shapes, blender 3.0+ adds transform options that are simply not available in older blender versions, so the bone shapes likely would need further editing nonetheless, making it not work the effort.

Automated steps, on the user's installed addon version

  • Update the mob spawner and lister to check for "pre#.#.#" in the names of rig files (such as pre3.0.0 means the rig file to use before blender 3.0). So if a user is using blender 2.93, then it'll use this file "pre3.0.0" file, otherwise it'll use the as-submitted one instead authored in blender 3.x (so long as it passes QA for working in 3.0).
  • When a user uses this old rig, it should display a warning like "Using stripped down rig; use blender #.# for better results" to indicate to users they are missing out due to their version of blender.
  • If a user is using blender 3.0 in this scenario, then it will skip any loading of any files with "pre3.0" or lower numbers in their titles, so they are effectively hidden.

The key here is that the files and collections contained by "pre3.0.0" and the original title should be both mutually exclusive and collectively exhaustive so that nobody fails to see the rig, and that nobody sees the rig listed twice. Although there could be some befit to having a tick box for "list legacy rigs" down the road, in case someone actually prefers the over-simplified rigs, but generally that's better suited to be included as its own separate rig.

@TheDuckCow TheDuckCow added the enhancement Feature requests or new functionality suggestions label Jul 10, 2022
@TheDuckCow TheDuckCow added this to the v3.4.0 milestone Jul 10, 2022
TheDuckCow added a commit that referenced this issue Jul 10, 2022
This resolves the need here to support new assets with minimal work to make backwards compatible: #317
@TheDuckCow
Copy link
Member Author

This has now been implemented, and is working well for the one use case implemented thus far: the Warden rig (though this rig is also affected by this issue, overall a great edge case rig)

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
None yet
Development

No branches or pull requests

1 participant