Closed TheDuckCow closed 1 year ago
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.
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
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.
Yeah bone interfaces are more reliable anyway
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.
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.
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.
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)
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
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
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.
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
A good point - created the issue referenced above, in the meantime I'm marking this as done for now.
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
The blend file must be last saved in blender 2.80 OR have version partitioning across all versions of blender 2.80+
bpy.data.version
, it should print out something like the screenshot belowWarden - 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)The rig must be self contained. That means textures are packed
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
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:
["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.
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
Drivers are ok, but shouldn't be excessive - and minimize the use of python expression drivers where possible
A fun note: The default position of the rig should show off its flaire! Ie, the saved pose should be posted.
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
Technically, rigs can have a single python script named after the same blend file that are used to draw custom interfaces
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.