Pyblish Magenta

Pipeline Development
#83

Let’s give it a go.

Possible Issues

During layout/animation
It would mean that you would be referencing files from ‘outside your Maya project’. That would likely mean that references will not be resolved with their ‘relative’ project paths. If a file would be ever opened where folders are mapped differently, eg. project is moved (or even used on a different dropbox path), then the references couldn’t be resolved and each have to be relinked individually (and manually).

During rendering
The only other issue I can think of is with rendering. Since Maya always test renders into a /tmp directory within it’s images folder defined by the images rule. (Also the /tmp directory for preview (non-batch) renders can’t be avoided.) So the workspace would have to be set correctly based on the project’s schema. In practice that would mean it’s not only dependent on setting a default workspace, but also setting the rules of that workspace correctly.

#84

Ah, good points. We’ll have to keep that in mind, I can see how an alternative could get more complicated than what Maya gives you by default.

How about we uncover the problem, stare it right in the eye, and then we can talk about how to simplify it?

1 Like
#85

Sure. Another benefit is that facing issues we think might arise learns us whether they are actually there.

Plus if issues arise we can build Validations to ensure those issues we are avoiding by experience to be caught when a less experienced user does cause them.

1 Like
#86

Hey @BigRoy, I noticed you’ve made some changes to the model. Don’t forget to share what it looks like here, as a 512x256 gif. :blush:

#87

What’s the workflow for making the gif?

#88

It’s more complicated that it should, that’s for sure.

The simplest thing is to import the mov from Maya into Photoshop and Export for Web. I’m working on an extractor to do it automagically using ffmpeg, like this.

It’ll be a 2-step process.

  • Extract mov
  • Convert to gif

Edit, other alternatives.

Folder Structure Resolver
#89

I’ve added configuration files for be, the new dash, to The Deal and here’s how to use it.

install be

$ pip install be

enter an asset

Similar to before, you can enter the asset like this.

$ be in thedeal/ben/modeling --enter

Though the newer syntax is to use spaces.

$ be in thedeal ben modeling --enter

Like before, the command-line session is dropped into the development directory and you can start working.

Unlike before, you can now start Maya directly from the terminal.

$ be in thedeal ben modeling --enter
$ maya

It assumes you’re running Maya 2015 on Windows.

Technical details

The full configuration consists of three files.

inventory.yaml

characters:
- ben
- jerry
- hand

setdressing:
- table
- cup
- bangGraphic
- speecBubble
- gunA
- gunB
- window

shot:
- shot1
- shot2

templates.yaml

characters: "{cwd}/{0}/dev/{2}/characters/{1}"
setdressing: "{cwd}/{0}/dev/{2}/setdressing/{1}"

be.yaml

alias:
    maya: start "" "c:/program files/autodesk/maya2015/bin/maya.exe"

redirect:
    BE_PROJECTSROOT: PROJECTSROOT
    BE_PROJECTROOT: PROJECTROOT
    BE_DEVELOPMENTDIR: DEVELOPMENTDIR
    "{0}": PROJECT
    "{1}": ASSET
    "{2}": FAMILY

Future

I’ll be developing plug-ins with these environment variables in mind and would like you to do the same as they are awesome.

More about be can be found here.

1 Like
#90

Hello again guys.
sorry for my delay in rigging the character.
unfortunately i was so busy last week. but today i start it and i think tomorrow it will finnish.
today i riged the torso of character. take a look at in dev directory and let me know how is its naming conventions and other things.
i will finnish it soon.
sorry again.
good luck

1 Like
#91

Super-busy here as well. :wink:

It’s looking good. Continue forward and let’s see what happens once we start building the publishing solution for rigging.

Any reason the templates are formatted differently than in the original thedeal templates?
I’m mostly looking at why it’s categorized on characters and setdressing and not on families?

characters: "{cwd}/{0}/dev/{2}/characters/{1}"
setdressing: "{cwd}/{0}/dev/{2}/setdressing/{1}"

Purely looking at the data that is provided in the yaml files it would allow me to enter any family (even if I mistype one?). For example:

$ be in thedeal ben mudeling --enter

I’m also wondering ‘how far’ be should bring us with the project. Will it also provide the destination location for assets? Or is it only providing the initializing on the development side? If it’s only the latter don’t you think setting up the inventory.yaml and templates.yaml might be too much work for too little in return?

Other than that I’m loving the ability to add aliases (eg. for maya). That will really ease working in a multi-version environment. Wondering how that would work multi-platform.

#92

Yes, it’s because be has a higher purpose than for use with Pyblish alone and families is Pyblish-specific. Here, it has to do with the binding between an item in the inventory and its template.

Any item in the inventory under characters will be assigned the corresponding template. The 0-1-2 are the positional arguments you type at the command-line, in this case 0=thedeal, 1=ben and 2=mudeling.

We could use the last argument to determine the family.

if os.environ["FAMILY"] == "mudeling":
  family = "model"

That’s right, I haven’t yet discovered a compelling enough reason to limit the arguments beyond project and asset. In this case there’s one extra which we’ll use to determine family, but there could be any arbitrary amount based on what you are looking to do with it.

The safety net in this case is the fact that it alerts you to the fact that a new development directory would be created here, and that you wouldn’t be entering an existing one.

In a larger environment, I’d also like the non-mandatory argument to be fully optional and instead default to who’s asking. An animator for example would head into animation whereas a modeler into modeling, unless they specified otherwise.

Have a look here for how that could work.

I realise you haven’t yet worked with initialisation and that it can be hard to picture what you would be given in return because of that. It would be quite the task however to tell and easier to show, and since we’ve got our demo project for exactly this purpose I figured it would be a good environment in which to demonstrate it.

So, we could either a) discard it, do what we know, or b) taste it, discover what we’ve missed.

As it’s your baby, I’ll leave the decision to you.

1 Like
#93

Let’s definitely taste this! I want Pyblish Magenta to be the messiest project ever… just kidding! But I do think that we should get the most out of this as a test-case and I think be can be an interesting addition.

Would be sweet if we could even get a minimalistic GUI (even if it’s just to choose the asset you’re working on and choosing the family) to reap the benefits of a minimalistic pipeline. Still wondering how we can get non-tech-artists to join this test project? :wink:

I think it would be best if be could be set up with a custom Getter class that instead of reading from a .yaml file would allow anyone to even match it up with their database? In theory that way the actual lookup can be customized to anyone’s needs. What do you think?

#94

Realistically speaking, there were 500 non-technical artists working with a tool very similar to be during Gravity, and they still do for all their projects at Framestore, and I personally did not have any problems with it. Anyone can type the name of the project and asset they are about to work on.

Heck, people built their own aliases and tools on top of it to get to common tasks more quickly, it was great.

That’s an option, for sure. Put it up here? https://github.com/mottosso/be/issues/new

Spontaneously, it would mean loosing per-project sensitivity, which is a primary feature of hosting these things within the project directory. But I can also see the advantage of centralising things, and I’m sure there’s a way to get the best of both.

1 Like
#95

Had a quick go with jumping into ben’s modeling file with be. First run worked perfectly, awesome @marcus!

At this stage it seems to provide the family, asset and project but is lacking the container data in the environment. What’s the easiest way to also get the container upon entering with be. Where container is something like characters or setdressing? With that added we should have all the information required for our selectors.

That’s an option, for sure. Put it up here? https://github.com/mottosso/be/issues/new

Spontaneously, it would mean loosing per-project sensitivity, which
is a primary feature of hosting these things within the project
directory. But I can also see the advantage of centralising things, and
I’m sure there’s a way to get the best of both.

Not necessarily. The project could host the Getter class as well! :wink:

I must be harder on our artists (and myself?)! :wink: Once they need to type their way instead of clicking through something they are already opposed to the workflow. Anyway, let’s nail this with be. Would you recommend grabbing the value through os.environ? Or would you rather do it another way?

#96

Awesome to hear it worked for you.

That would be either via parsing the path, or reading either inventory.yaml or templates.yaml yourself. But do we really need it? Here, it’s mere coincidence that the name of the template matches the parent directory of the asset, it should have little to do with artist intention.

If it’s for building a output path for publishing then don’t bother. be is about setup, pyblish is about sharing. Input/output. There may be a layer of translation inbetween, that’s ok.

I see… or actually I don’t. Could you elaborate, maybe with a small psuedo example?

Yeah, don’t get too hung up on the interface, it’s the concept and it’s benefits that matters. Once we’ve had a taste of it, you could wrap it up in whatever pretty GUI you’d like. The thing about command-line is that you get a lot more bang for your buck during both development and usage. The things you can already do would have taken months to wrap up in an equally capable GUI. It’s almost like the difference between a good book and a good movie. In a book, your imagination fills in the blanks and you get close to the experience of a good film, but with much less effort.

I also think of it as the underground/tube/trains here in London. They’re dirty, loud and crowded. People hate them for what they are. But for some reason we use them anyway. Because of it’s benefits. They’re hard to beat and come incredibly cheap for what they are. That’s be today.

Exactly, consider the environment to be “aware” of an artist’s intentions, of his task.

The next major feature of be will be the Python API through which some of this can be prettified.

>>> import be
>>> be.template
characters
>>> be.format_string
{cwd}/{0}/dev/{2}characters/{1}
>>> be.environ["FAMILY"]
modeling
#97

I totally see your point, but would show the other side of the coin. In the small studios where I’ve been and the few, that I’m collaborating externally with right now, Not a single one was willing to go with anything cmd/shell based. I had producers specifically telling me, that anything like that is useless for them, because when they tried, people were simply trying to ignore it and work around it. This should all be about minimizing the learning curve and forcing an animator, who’s scared of info messages, is next to impossible.

I agree that the big houses would probably be a different story, but also know that all of them have so much overhead, that they probably don’t even notice when someone struggles with a tool for a few days.

I’m really not trying to fight the cause here and if you guys get it up and running I’m more than willing to give it a go, but I can’t imagine having people asking me for a KISS style system and I’d give them a command line tool. Even though saying that adding GUI would double the costs, might move some producers towards command line love :smile:

1 Like
#98

What cmd/shell based tool did you propose?

#99

Mostly it was related to publishing of external resources coming in. Footage get’s downloaded from ftp for example and the you go into the folder, launch shell from there and type publish plate. It would take files in the folder and publish them to correct location based on their file name.

It doesn’t get much simpler that than and still they were not keen. Other studio outright told me they don’t want any text tools, because they don’t have staff to support their artists with problems when something goes wrong. The point being for almost everyone I’ve met who wasn’t very technical, command like is like a plague they try to avoid.

#100

I suppose we’ll have to imagine a GUI for now. :slight_smile:

#101

Not sure what you mean here. But for me the container is information about the workspace, the actual asset you’re working on. The actual assets’s name being in the directory is also not a necessity. Each shot could be saved with a UUID where the artist never actually sees the underlying folder structure. :wink:

Basically the only thing the Selector currently needs outside what be adds is the container information. It’s information about the current asset you’re working on so it would be great if it could be added to the environment data.

It is for building output data, yes. But possibly also retrieving additional data about the current asset. At best I want to have data available that allows me to format paths and have me skipping the need to actually parse any paths. Currently I still have to parse the current folder to retrieve the data that I want.

I guess the question is how would I implement something for be that ensures whenever an asset is entered additional custom data is added. For example if I want to retrieve data from a database upon entering? How could I set it up?

Next to the yaml files in the project we could have a be_get.py or something that contains a class Getter that defines how data is being retrieved. By default that file could do something like from be.api import DefaultGetter? And if someone wants to have a customized Getter they could implement it within that file or import it from there own library?

Would it be possible to use be also purely python based. Something like be.enter('thedeal', 'ben', 'modeling') ?

#102

Before we go any further, could we try keeping our feet on the ground and actually implement a plug-in that illustrates the problem?

A UUID for shots, a database getter for project initialisation and a Python API for be isn’t something we’ve encountered a need for in The Deal yet and I would like to see how and why it fits before struggling with a solution for it.

Try not to think of initialisation and publishing as the same thing. Publishing hasn’t changed, we still need Lucidity to build output paths. be is only for getting into the project environment in the first place, its techniques and solutions are separate, even though they both currently use formatted paths, which is a coincidence at this point.