You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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)
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.
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.
The text was updated successfully, but these errors were encountered:
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)
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:
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
Automated steps, on the user's installed addon version
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.
The text was updated successfully, but these errors were encountered: