Defining new asset standards

[TheDuckCow]

With this newfound push for progress, I'm excited that we'll be having individuals like @MajesticalDiscomfort helping out with both asset contribution QA and even direct rig contributions.

But in order to do this, we need to establish clear standards to follow (so that QA can be done objectively enough). My initial proposals, I'll refine this as we discuss further - with the intent to eventually create it's own markdown doc for this.

Mob + Entity standard proposal

• The most important QA test: use "install rig" in MCprep, and then test importing

  • There should be no errors, and materials should work, and the armature and everything should be there with no unexpected parented objects or "extras" coming in.
  • Do this test in BOTH blender 2.80 and the latest (e.g. 3.6).

• The blend file must be last saved in blender 2.80 OR have version partitioning across all versions of blender 2.80+

  • This is important as we claim to support 2.80+, so all rigs need to adhere to that
  • You can check the last version saved by opening the given blend file, going to the Script tab, and then typing this command: bpy.data.version, it should print out something like the screenshot below
  • Not sure what rig partitioning means? Take this as an example, and hopefully it clarifies:
  • Warden - DigDanAnimates pre2.80.0.blend Will be used by anything before blender 2.80 (in other words, we'll be deleting this file soon!)
  • Warden - DigDanAnimates pre3.0.0.blend Will be used by anything before blender 3.0 (e.g. 2.80, 2.93)
  • Warden - DigDanAnimates.blend Will be used by blender 3.0 and higher (due to no other "pre#.#.# being higher than 3.0.0)
  • We should aim to NOT partition rigs by version as much as possible, as it bloats download size and becomes even more to maintain. But sometimes, we can't avoid it.

• The rig must be self contained. That means textures are packed

  • This is to negate the issue of relative vs absolute paths, which just become a pain
  • Best practice is still to run "relpaths" beforehand, to avoid having any user's paths hard coded into the file, which is more of a privacy thing than anything.

• Extra unused data should be purged, to minimize bloat

• All rigs should be defined in their own top level collection. All other collections in the file not related to the rig must be removed

  • If a rig itself has multiple nested collections, that's ok - the top level collection just needs to have "MCprep" in the name, e.g. "Warden MCprep" will be what gets listed in the UI list, and it won't list any sub collections or other collections in the file. The warden rig is again an example of this. But prefer to just have a single collection where possible.

• Custom bone shapes are ok and in fact encouraged, just don't put them in the rig scene. If you want to put them into their own collection, either give it the name MCskip OR make sure the primary collection (s) have the text MCprep in it, so that the

• The root-most bone of the rig must:

  1. Exist. Ie one central bone that everything is parented to, so if you move this everything, including control-only panels, also move
  2. Be named one of: ["main", "root", "base", "master"]; case does not matter, though convention is to primarily use ROOT in all uppercase.

• All bones should be named, no name.001's or anything like that.

  • Furthermore, left/right bones should be named as per the blender guidelines. See here, which helps ensure animation tools will work like flip pose left/right.

• All meshes should be named as well. No cube.001's, give them representation names

• The rig must be a reasonably faithful representation of a Vanilla mob or entity

  • No custom mobs that aren't in game (yet)
  • No highly detailed or stylized looks that would differ from the rest of the library, e.g. generally there shouldn't be beveling
  • Some extra details that accentuate and make high fidelity animations possible are OK. Examples include: Knees and elbows that bend (but it should still look vanilla if they don't bend), extra face controls or facial details (in the case of player rigs)

• Drivers are ok, but shouldn't be excessive - and minimize the use of python expression drivers where possible

  • Drivers add a lot of overhead, especially if you have many of one mob type in a scene.
  • Simple drivers, such as "SUM position" used to translate a control panel to bone transforms are fine - but they should NOT be python expressions, rather they should be SUM of [variable transform channels], as these run much quicker.

• A fun note: The default position of the rig should show off its flaire! Ie, the saved pose should be posted.

  • MCprep has controls for clearing the post on import. Meanwhile, having a posed starting point helps show off what the rig can do.

• If relevant, the rig can have a single default animation. There should not be more than one animation though, since it wouldn't be obvious and would clutter the file during subsequent imports

  • The bat is an example of this, with a simple flying pattern. The Enchanting table is also an example (although that is a "block" and not an entity or rig)

• Technically, rigs can have a single python script named after the same blend file that are used to draw custom interfaces

  • But this is strongly not encouraged, as we cannot guarantee maintaining these ad hoc scripts. Much preferred to have drivers in the system itself, so that we don't have to rely on the user finding a custom panel or anything like that
  • However, this feature of having python script loading will be kept, as it is very useful for users who have their own custom rigs they like to install and use.

Other asset contributions

QA will be done on a case by case basis. This would apply to meshswap mesh contributions, geometry node weather effects, and anything else not mentioned.

[TheDuckCow]

Oops I pressed shift+enter, this is still a draft WIP - I'll keep working on this

Ok updated now. @StandingPadAnimations and @MajesticalDiscomfort very curious to hear if you have any suggestions to add on here!

I know this seems like a lot... but, all of this will improve the user experience. I'm sure there's more too. And for many of these rules, we could actually make a little QA script that tells the user [edit: or QA tester] of anything wrong.

[StandingPadAnimations]

• Technically, rigs can have a single python script named after the same blend file that are used to draw custom interfaces

  • But this is strongly not encouraged, as we cannot guarantee maintaining these ad hoc scripts. Much preferred to have drivers in the system itself, so that we don't have to rely on the user finding a custom panel or anything like that
  • However, this feature of having python script loading will be kept, as it is very useful for users who have their own custom rigs they like to install and use.

I've actually asked a couple of rig developers why addons are so commonly required to use their rigs, and they say it's to give a nicer interface as properties are... not the most readable. That being said, I'm definitely on the boat of discouraging Python scripts merely for UI, I've seen rig developers do questionable things in their addons (like the use of eval with f-strings while not validating input... shudders)

This might be beyond MCprep (but is interesting nonetheless) but we could create a way to add custom UIs for rigs directly in MCprep itself (perhaps using JSON for ease of maintainability and maximum safety). It would likely be used beyond MCprep rigs as it's safe to assume most Minecraft animators have MCprep (and thus makes it easier for rig developers in general). How this would be implemented I'm not sure (since we'd have to do some complicated property management and dynamically update the UI based on selected rigs) but it's an intereatimg idea nonetheless

[TheDuckCow]

Yeah that's an interesting idea actually. Completely doable, though I'd say we have enough overhead in just trying to provide all the rigs in the first place before even worrying about providing some bespoke system to display a UI for those rigs. I think pushing contributors to use driver and in-scene "property bones" or better yet custom bone shape defined interfaces is standard enough that it's ok to suggest doing that instead. Both of those are still a bit clunky, but more expected at least.

[StandingPadAnimations]

Yeah bone interfaces are more reliable anyway

[zNightlord]

About the UI panel Most the rigs I noticed, the properties exposed, drive as the UI doesn't have extra use of API defined properties. So using pose bone properties is mostly fine. The users can load external python script themselves and use the fancy UI again. But can we have an exception for certain "verified" rigs? Like for example the Allay and Frog rig current in MCprep.

[TheDuckCow]

I think the exception will more be a "legacy" vs verified sort of thing, so existing rigs with scripts can remain (if they still work), but moving forward... well, I guess there can always be exceptions to the rule, maybe some rig really warrants it. But I also imagine it might be one which is better suited for users to manually install if it's so special.

[StandingPadAnimations]

I don't think we should make Python scripts for rigs never designed to use them. We're trying to discourage the use of scripts for things that could be achived in Blender, not make new ones willy nilly.

[TheDuckCow]

Agreed that we shouldn't be making python scripts, I'm really just thinking if we get a rig contribution that comes with a python script: should we ask to redo it so it doesn't need the script, or would it be accepted if it meets some conditions? I'm leaning to ask it be redone to not need the script (in some cases, it could mean no work; in other cases, might mean creating some property bone drivers)

[zNightlord]

It shouldn't be that trouble much. I was trying to say most rigs just have python script as exposed UI to drive the properties inside pose bone(s) in the rig. Without it the rig won't be broken or anything, just inconvenience finding those properties because some riggers like hiding/private vars. For the Allay and Frog, I mentioned those special cases because the scripts in those aren't really manually written, they are generated and put inside as a pointer in the object datablock because that is how that addon works. The script just came along with it. They should be functioning fine without a script so (if you don't mind about ikfk snap, bake function)

Rig asset or possibly complex setups should have a text note/documentation writes the important things out like where to find certain properties, explaining the basics, not touching this if you don't know what you are doing...etc

[StandingPadAnimations]

Can we create a list of old rigs that no longer meet these standards? That way, people who want to contribute rigs know what is needed

[TheDuckCow]

We can certainly do an audit at some point, though I generally think focus first should be on new rig contributions. Aside from allowing the couple python script examples, I've generally been applying most of the above QA steps myself as a part of accepting rigs. The more qualitative parts around density/topology I've been less picky about, it's a tradeoff to have nothing vs something that just could be better.

[StandingPadAnimations]

New discovery: just as rigs saved in 3.0 aren't backwards compatible, same with 4.0. Two rounds of FBX conversiom will now be needed for rigs made in 4.0

Correction: ignore that last statement, I forgot about FBX being version independent

[TheDuckCow]

A good point - created the issue referenced above, in the meantime I'm marking this as done for now.