Namespace generation
Issue
The main issue we have encountered is that the namespace creation from the maya.pipeline.load is forcing us to recreate a namespace in all loader plugins.
Our current solution is to override the Loader plugin in our configuration but we think it will benefit all if we try to implement something along the lines of the proposition below
Proposition
Create an easier to access namespace generator for the the loaders with use of maya.unique_namespace as it provides everything we need.
- Add an optional separator argument to force "_" between name, format and suffix. Would remove code such as this:
name = name or subset["name"]
namespace = namespace or lib.unique_namespace(
asset["name"] + "_",
prefix="_" if asset["name"][0].isdigit() else "",
suffix="_",
)
- Allow for a configuration of the namespace generation.
- Step away from using the subset name by using the origin asset's name
Example use of namespace we have in mind,
{asset}_{counter}_{descriptor}(propose descriptor to be step)
hero_001_rigis loaded in animationhero_001_animis loaded in lightinghero_001_fxis loaded in lighting
Motivation
- Improve readability of scene construction in general
- Improves debugging of scene for TDs and artists
- Clear on content of loaded item:
asset, the asset's origin name ( hero )counter, the number of the namespace use for asset ( 001, 002 etc )descriptor, step / family / representation ( rig / mod / abc / fbx / yeti )
Great summary @aardschok.
The main issue we have encountered is that the namespace creation from the maya.pipeline.load is forcing us to recreate a namespace in all loader plugins.
Could you share an example of what it namespace you get with and without your subclass?
When loading model for hero : hero_01_
When loading animated abc of hero from shot1: shot1_01_
The latter is something which strikes me as odd, I would expect the asset who's animation was exported ( hero in our case ) to lead the namespace.
You're right, that is odd. Good catch!
propose descriptor to be step
Let's see, what is "step"?
I use the wrong terminology here but I think you know it better as "task", a step in production, rigging, animation, modeling, etc.
Ok, no that's what I thought. Wouldn't that be problematic though, how are you getting these:
hero_001_rig is loaded in animation hero_001_anim is loaded in lighting hero_001_fx is loaded in lighting
If in lighting, wouldn't the task be lighting, leading to hero_001_lighting when loading a cached animation of hero? And what about loading a rig, and model from hero, would that result in hero_002_lighting and hero_003_lighting respectively?
I think subset would need to be included in some way no matter how we twist and turn.
I think subset would need to be included in some way no matter how we twist and turn.
Maybe, I think we should avoid the step or task terminology for this anyway, the main family should suffice? (Even though those are currently prefixed with the company name, like "mindbender.model") My thinking anyway is that the instance itself (the output data) defines actually what it is that is loaded, not the workspace where it came from.
Whether we use family, representation or subset (or a mixture of them) is up for debate I suppose.
Note that a model and a rig (both .ma files) will have the same representation and I'd prefer to see _model and _rig, which is its family?
So {asset}_{counter}_{family} would be something like hero_001_rig (if we can somehow simplify the family to that, instead of mindbender.rig. We could split it on the last dot.
Yeah, family seems more reasonable. Could we simply use the suffix of the family name?
namespace = rep["family"].rsplit(".")[-1] + "01_"
@mottosso why split if we can store the abbreviations in the families? Maybe a family has a name which is too long. Animation for example will become _anim, simulation can become _sim.
I propose :
suffix = rep.get("abrreviation", rep.get("family")) #
Where abbreviation is optional as family is a mandatory property of families.
My only issue with that is backwards compatibility. We'll need to transition in such a way that it still works without this member. Have a think about how that could be achieved.
For the time being, I'd say produce your own mapping from family -> abbrevation in a subclassed Loader. If it works well, we could have a chat about backwards compatibility or worst case migration.
We'll also need some way of specifying.. essentially metadata, per family. At the moment, a family is just a name. Have a think about how to expose this choice to the user as well.