Ah, now I see. Yes, that’s right.
Without categories, maybe use a prefix?
$ be in thedeal testben modeling --enter
$ be in thedeal xBen rigging --enter
Again, I get your concern for order in explorer.exe, but I wouldn’t let it cripple or complicate your tools. A prefix would get you there, but is admittedly not as neat as dedicated parent directories.
So long as you’ve considered and accepted the cost, any option is fine.
Another reference, at Framestore we had thousands of assets.
It worked, because we never looked at the /assets directory directly. We either specified exactly which asset we were working with, most commonly, or let sorting, filtering and presentation be handled by a simple GUI, something better suited for the task than explorer.exe.
And it doesn’t have to be complex. Listing the directory and putting it in a QListWidget will do. Add a QLineEdit and QSortFilterProxy and you’re horselenghts ahead of what explorer.exe offers. From there, it only get’s better.
With tab-completion in be, some of that might not even be necessary.
$ be in thedeal b[TAB]
ben banana broccoli brock bill bert
$ be in thedeal brocc[TAB]
$ be in thedeal broccoli --enter
Let’s give no category a go with Magenta I suppose. To me (and all artists I had a check with) it just doesn’t make sense to put everything next to each other, or at least not categorizing it. Even when searching/browsing for the name of a character I would like it to be identified as a character.
Instead of knowing:
ben
banana
broccoli
brock
bill
bert
I would instantly know:
ben (character)
banana (prop)
broccoli (prop)
brock (character)
bill (character)
bert (character)
For all I know the banana is the main character of the show, not a prop at all.
Also this could be nice:
gangster (character)
testing_gangster (sandbox)
By the way I’ve had artists becoming confused with assets? They say why isn’t it called objects or models? Not that I agree with them, just raising the issue here.
Don’t get me wrong, categorisation is really important, and makes finding things easier, if not possible to begin with. But if categorising via parent directories degrades and adds maintenance cost to surrounding tools, then there might be alternatives which fills the same spot but yields a higher ROI.
You also open up the flood gates to the future. Categorisation has far more potential than could ever be achieved by explorer.exe alone. Sure, sorting by “characters” is good. But how would you like to sort by “hero” and “male” as well? It doesn’t take a rocket scientist to turn a QListWidget into an intelligent browser that recognises assets beyond their superficial directory name. This is where things such as shotgun, ftrack comes in, but any metadata anywhere will suffice.
It shouldn’t really be up to the directory structure to tell you what character is a hero character for a show. That’s the job of project management; either by word-of-mouth in a small production, or ftrack in a larger.
Call it what makes sense to you and those around you. If that’s “model”, then model it is. For me personally, I still get confused to see characters under model, and both modeling and geo under a character. But I’m not on your project, you should design towards your target audience.
I think we have a way going forward for now. Based on all that’s discussed in this topic we’re looking at using something like the following
Here’s an overview:
+---assets
| \---ben
| +---animation
| | \---work
| | \---maya
| +---conceptArt
| | +---publish
| | | \---v001
| | \---work
| +---lookdev
| | +---publish
| | \---work
| | \---maya
| +---modeling
| | +---publish
| | \---work
| | \---maya
| \---rigging
| +---publish
| \---work
| \---maya
\---shots
\---film
\---example_shot1
+---animation
| +---publish
| | +---v001
| | \---v002
| \---work
| \---maya
+---comp
\---lighting
+---publish
| +---v001
| \---v002
\---work
\---maya
We separate between Assets and Shots at the project’s root level.
Assets
Any object that needs to be created, used and re-used throughout the project. Like a character, prop, vehicle or an environment.
Shots
Any shot that needs to be animated and go through rendering. A shot always belongs to a sequence. Therefore to define what shot we’re working on we need one more variable.
be in the projectWe use the command-line tool be to set up the environment before booting into an application. This allows us to define our plug-ins a more universal manner, basically making it easier for other people to pick elements from Magenta and start (subsets of) it for their own projects. Of course using the whole Pyblish Magenta pipeline will also work, and becomes easier to build and maintain thanks to be!
Assets
To start modeling on our character Ben:
$ be in thedeal ben modeling
Then we start Maya:
$ maya
It’s similar for rigging:
$ be in thedeal ben rigging
Shots
For a shot it will require one more argument (the sequence), so if we want to work on the first shot of the film sequence in animation:
$ be in thedeal film shot1 animation
The structure is still open for discussion, so happily hop in to provide your own pros and cons to continue discussing it.
I pretty much got everything I asked for, so telling you how awesome I think this is would be scratching my own back. 
@tokejepsen and @mkolar, I think this should be encapsulated enough for you to provide some insights on what you think is good/bad, what do you think?
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?