Hello guys
I should say that Rig is completed now, and it is ready for animate.
it is in E:\Madoodia\Dropbox\Dropbox\pyblish\thedeal\assets\ben\rigging\work\maya\rig_madoodia_13_final_03_07012015
my friend @masoud created a test with version 11, i captured it and gifed it, the animate is not related to storyboard, just a fun walk cycle.
I will try to work on some of plugins that its idea is on my head. i will share it here when it is done
Sweet stuff! Looking forward to seeing it published through Pyblish.
Sounds like we’re about to head on to animatic/blocking for the film, going into shots! Should we need a previz-like version for the environment? Or what would you guys like to see progress on?
@Mahmoodreza_Aarabi did you have any issues with the model for the rig? Or did the Validators that were in place capture everything?
Thanks @BigRoy
i didn’t understand well your questions. can you explain more?
but beyond this model there is some point that is important for model, for validate:
if i remember anything else will tell you.
for second question, i don’t know what the means of capture in place, but i’m new in validator creating at all, i created many scripts but not great Validator sofar, i will start it from today, but if you explain more, maybe i have anything to say.
good luck
Were you having any issues with ben's published model?
I just wanted to check whether all the Validators where in place for publishing models to ensure the model is up to the standards you want it to be as a rigging artist.
mhm, you know! this is a basic model at all, and because its limbs are seperated many issues solved, i mean shoulder and hip. i didn’t have any problem in rigging it, but i think it have some extra edge loops that because i used deformer on it it may affect on performance that marcus said about it.
places that need enough joints are elbow, wrist and knee, and foot, but totaly it is good for this project, i hope we can work on more complecated things. and it will help all to know new things about Validating.
I know that Repairing is deactived at the moment in pyblish, but about rigging i think it is a fundamental thing to be.
A rig like rig of this character at least have 500 node, and i think more than 20 validator needs for checking the rig, so we will face with very much error that artist will confuse about solving them one by one. so
Autorepair is essencial for each validator ( i think), i have some validator idea in my mind that all of them needs autorepair, in these years i worked many times on repairing, not validating, so i think (again) it is essencial, we will talk more about it, now i’m reading Rapir_Faults
To be continued …
@BigRoy, i ask this question from @marcus, What is standard rig for us, ATM? that we can work on Validators based on it.
i mean i have some idea about creating some Validators based on my rig and your rules (because this is you project) to reach to a good standard.
what do you think?
i’m listing my ideas about creating Validators on paper for now. then i will put them here to talk more, and i will start to creating their code.
A rig is a complicated element. Because rigs vary from very complex with custom nodes/plug-ins to very simplistic constrained hierarchies. I think it would be great if you could set up the Validators you have in mind yourself and tweak it together.
Some things that I had in mind before were:
I think the same collaberative designing should be done with modeling, animation and the rest of the pipeline where we ensure it’s up to par with all our needs.
Most of these are already captured with validators, but I’ll check specifically these points again soon. What are you referring to with ‘cleaned’ model? And what’s the difference between a static channel and a keyframe?
What do you think about collecting suggested validators as GitHub issues? That way we can keep them organised and tick them off when done.
For example, I just added this.
Sounds good!
Just did a commit to my repository with a reference to it. 
Cleaned model i mean when you open cleanup menu and check all about model, all of them apply to model when validating.
Static channel happens in two state:
1- when a node have one keyfram on its animecurve (only one)
2- when a node have multiple same keyframe in different frames
it is good,
DAG Nodes:
Name | Suffix
------------------- | ------------:
Animation ctrl | ANM
Locators | LOC
Group | GRP
Curve | CRV
IKHandle | IKH
Effectors | EFF
Proxy Mesh | GEP
High Mesh | GES
Default Mesh | GEO
Joints | JNT
Parent Constraint | PAC
Point Constraint | POC
Orient Constraint | ORC
Aim Constraint | AMC
Distance Node | DST
Cluster | CLS
...
DG Nodes:
Name | Suffix
------------------- | ------------:
MultiplyDevide | MAD
Wrap | WRP
Expression | EXP
BlendTwoAttr | BLD
AnimCurve | ACR
BlendColor | BCL
Reverse | RVS
PlusMinusAverage | PMA
Condition | CND
CurveInfo | CIF
...
we will work on it more.
i want to know your opinion.
thanks
This is an interesting one. How do we define what are unrelated nodes? If it’s up to the rigger to tag a node as such how do we validate he didn’t mis-tag it?
Is this meant to ensure driven keys are locked?
Do you have your own implementation for finding these nodes? Or do you want to copy the behaviour of Delete Unused Nodes in the hypershade? If it’s the latter you would have to copy the behavior implemented in the corresponding mel script. That script by default only deletes the nodes, it doesn’t have a way to list the nodes. With the validator we first want to raise the issue of the unused nodes and not instantly delete them.
Rewriting it shouldn’t be too hard, though it always raises the question on how to keep it up-to-date with versions of Maya if it becomes an intricate process to find only the right nodes.
When is this useful? In the rigging scene it’s not really that useful, and I suspect the animator never imports the rig but only references it. Thus by default it’s not possible to delete its nodes. Or what are you defending it from?
If we take this list of Suffices you wrote we should be fine covering your three points! I always wonder how important it is that things like multiplyDivide nodes end with a common suffix. If it’s purely to find them in the scene there’re more universal ways to find only that type. It does make it look like a neater scene though, but how much does anyone gain from doing it I wonder. I would rather have the rest of the node’s name make sense than the suffix. Let’s give this a go.
You can find a naming convention check for Maya in validate_transform_naming_suffix.py. Use it as a reference if you need to, but I would also praise it if you clean it up and define your own. It can probably be simplified a bit.
@Mahmoodreza_Aarabi All sound like really good ideas. Let me know if you need help implementing one of them.
mmm
i mean not related to visual stuff of rig. like distance nodes, locators and other things.
if you hit display > show > all many nodes will apear on the scene that should not, just need to off and lock its visibility.
yes driven keyframes (AnimCurves)
it is not difficult to find. we just find them, not delete them. (a process like optimization)
i believe that rig should be animator-proof. maybe a guy open the final rig and accidentally remove a node.
About suffix of DG nodes, it is just a recommendation, not very important now.
thanks, i try to focus on more important validators. and if i find a new one i will say here.
good luck
So we consider everything that isn’t a nurbsCurve or polygon mesh to be unrelated nodes? Great. Let’s see how it will turn out.
Finding unused nodes is actually trickier than I initially thought looking at the implementation of Maya’s Delete Unused Nodes function. Apparently there are nodes who are not considered ‘unused’ if they don’t have any connections. A quick look at that code shows a heightField node which behaves like that. Also it triggers a custom callback for plug-in nodes to ensure it doesn’t try to delete custom nodes that are useful without being connected. But give it a shot implementation wise and we’ll see if there are any issues.
Locking nodes in the scene so someone can’t delete it if they are opening the file might become rather annoying. The work file is only there to work in it, you might not want to have to unlock and lock everything each time you need to update the rig. I’m probably misinterpreting, but it seems that you’re trying to protect opening the work file plus the published asset. The first sounds odd and the latter should never happen! What do you think @marcus?
I think we’re getting a bit overprotective.
I would limit validations only to things that could cause trouble further down the pipeline. Deleting unused nodes isn’t one of them and certainly not locking of nodes.
Protecting against locking of nodes, to me, suggests a fault in responsibility and contribution. For example, to me, an animator delivers either a point-cache, or animation curves. He does not deliver the rig. If nodes have been deleted in the rig during animation, then it shouldn’t have any effect on his contribution, other than a potentially messed up animation, which is his responsibility.
From reading this thread from the outside (not working with magenta), I have to agree with @marcus completely. Don’t go over the top with validators, because apart from from marcus mentioned, you might also be restricting non-character rigging (unless you consider that a completely different type of task). I’ve seen rigs of props that have all kinds of awkward setups, hierarchies, separated nodes, all for good reasons. With so many validators in place you are restricting magenta to your way of thinking rather than building a pipeline that if flexible enough for other small studio to potentially adopt.
It’s more important to ensure unused nodes are not in the output than that they are in the work file. It would be useless output since they are unused. In that sense it would be great if a Validator could ensure nodes in the instance are actually of use. Figuring out which nodes are actually of use still stays tricky.
There’s a balance to be struck here, I think.
I think that absolutely everything that can cause trouble down the pipeline should be validated where possible. My only objection is to validate things that are pure cosmetics. Cosmetics are obvious and annoying, sure, but they don’t do any harm. I.e. they are subjective.
My vision for publishing in general is to enable a strong integration between disparate parts of a pipeline, such that a rigger can come to expect a certain format of any models coming in, and an animator can come to expect a certain format on any rigs coming in.
This way, there is unbounded flexibility and potential in the tools that can be built to facilitate and automate these processes.
If publishing is done right, than every possible step in your pipeline, once crafted by an artist, should be reproducible in an automated fashion. That means that once rendering is done, the modeler should be able to modify UVs, a lookdev artist should be able to add some splashes of blood to the murder weapon, and neither of those interactions should require any intervention from any other artist to get a new render out.
That’s the kind of strong integration I’m working towards and hoping you are interested in striving towards too.
Hope everyone can have a look at the Github issue about the Collector, Extractor and Integrator chain we’ll have to implement.
Currently the discussion is wide open. The workflow can become anything we want so hop in with best practices, ideas and let’s see where we can go.
I’ve pushed what is from my perspective an ideal method of collecting an asset from a Maya scene here.
It boils down to this.
# Capture nodes relevant to the model
with pyblish_maya.maintained_selection():
cmds.select(assembly)
nodes = cmds.file(exportSelected=True,
preview=True,
constructionHistory=True,
force=True)
# Reduce to relevant nodes
shapes = cmds.ls(nodes,
noIntermediate=True,
shapes=True,
long=True,
dag=True)
Which does a few important things.
From here, data is solely filtered downwards and no new data is added related to this instance.
The benefit is that (1) validation only ever touches data that is actually relevant and (2) a scene can be infinitely messy, but still come out ok. No validation happens on data that isn’t collected, and only relevant data is guaranteed to be collected.
This is in contrast to collecting via cmds.ls(type="mesh") or similar, which assumes an entire scene is of interest, even though only part of it is ever exported, in this case an assembly by the name of {asset}_GRP, e.g. ben_GRP.
Extraction at this point may look like this.
with pyblish_maya.maintained_selection():
cmds.select(instance, noExpand=True)
cmds.file(path,
force=True,
typ="mayaAscii",
exportSelected=True,
constructionHistory=False)
The constructionHistory=False is the key here. It will extract only what has been collected during collection, which is exactly what we are guaranteed to have validated.