Software support

[mottosso]

Let's determine the precise software that will be supported; that will help determine the type of technical limitations we need to work within as well as which Python version to work with amongst other things.

Some suggestions:

• Autodesk Maya, versions 2008 and upwards.
• Autodesk Softimage, since Python was supported
• Autodesk Mudbox
• Foundry Nuke, since Python
• Foundry Mari
• SideFx Houdini
• Blender

Ideally, these would also see some form of support, possibly without integrations:

• Adobe Photoshop
• Adobe After Effects
• Adobe Premiere
• Pixologic Zbrush

For games, these may also be included:

• Unity
• Unreal Editor

Feel free to suggest more, along with why you think they should be included.

[ljkart]

Good enough to start!

[mottosso]

Down the line, we might also start considering whether or not to provide integrations for common tracking solutions.

• Shotgun
• FTrack
• Tactic
• Stalker

The integrations could take the form of a mere template module with pre-made handlers that could be filled in to register a published path or trigger events etc.

[madoodia]

3D Max modo

[mottosso]

Any particular reason you'd like these to be considered?

[madoodia]

so this two softwares used in some studios. just was a suggestion.

On Sun, Aug 3, 2014 at 2:49 PM, Marcus Ottosson notifications@github.com wrote:

Any particular reason you'd like these to be considered?

— Reply to this email directly or view it on GitHub https://github.com/abstractfactory/publish/issues/12#issuecomment-50986853 .

Bests, madoodia

[tokejepsen]

im not sure Shotgun and FTrack are worth looking into, as they have their own integrations so I would rather look towards the open-source community.

[ljkart]

i don't know about Ftrack, but shotgun has its own toolkit. Those who doesn't have publish toolkit then we can think about writing plugin for them which connects our publish, otherwise we can stick on open-source framework like stalker.

[mottosso]

I was considering those who use Shotgun, but aren't using their publishing tool. I'm not too sure about how many of those using Shotgun actually uses their publishing tool to be honest, do you have any insights on that?

[tokejepsen]

I know a fair few have adopted the Shotgun toolkit, which are mostly smaller companies that don't have time or resources to develop it in-house. The rest of their clientele I recon, have the resources and/or have already build their own version. Thats why I'm thinking that the people that are using Shotgun/Ftrack are already covered for publishing.

[mottosso]

Ah, in that case you're probably right about steering clear from those guys. FTrack however doesn't provide a publishing mechanism as far as I know.

[ljkart]

that's right, we use our proprietary publish tool, even the shotgun toolkit is available for us.

[tokejepsen]

Maybe Ftrack doesn't have a direct publishing app, but they have enough of a framework and development to make one easily. And their API is so easy that almost any TD can make one fairly quickly. Not saying that we should ignore Ftrack or Shotgun, but just not spend a lot of time catering for those trackers.

[mottosso]

Could it be that, generally speaking, smaller shops using Shotgun also use Pipeline Toolkit, whereas larger ones use their own tool?

That could be how we position ourselves in introductions and scope when presenting to smaller versus larger houses. I'd also like to stress though that Publish should be a completely stand-alone tool without dependencies.

# For example, this should work
$ pip install publish

[tokejepsen]

@mottosso, yeah that is how it seems to me. Basically I see Publish making open-sources asset management/tracking more attractive for smaller studios, as the integrations is there out-of-the-box. As a smaller studio you need to be up and running with minimal resources and time. Where the larger studios, can build whatever they want to suit into their pipeline.

[mottosso]

Maybe Ftrack doesn't have a direct publishing app, but they have enough of a framework and development to make one easily.

This doesn't make sense to me. What part of FTrack would make our development of Publish any easier?

Where the larger studios, can build whatever they want to suit into their pipeline.

They could, but time is money. If the option stands between using Publish today, or using their own software in 3 months of in-house development time, I think features and robustness is the only determining factor that matters.

[tokejepsen]

I meant Ftrack's API is easy enough for Ftrack's developers to make a publish app, when they get to that in their priority list. Wasn't saying that we use Ftrack for anything to do with Publish.

@mottosso, fair enough. I guess that is true for expanding studios, instead of existing ones.

[mottosso]

I meant Ftrack's API is easy enough for Ftrack's developers to make a publish app, when they get to that in their priority list. Wasn't saying that we use Ftrack for anything to do with Publish.

I'm still not sure I know what you're referring to. Which part of the API would have made developing something like Publish any easier?

[tokejepsen]

Ftrack's API have an abstraction layer before any host, so you are able to make a general publish app that needs minor tweaks per DCC or standalone.

[mottosso]

I'm considering whether the targets are currently too broad and whether or not its a better idea to make a kick-ass solution for Maya, and then worry about how we'll need to modify it to better suit other apps.

It'll make discussions far easier, development faster and once we've all got something to point at, it will become less academic and lean more towards practical suggestions.

Thoughts?

[madoodia]

I think now we continue to maya and manual working, mean sets using, now we are at the base level.

[tokejepsen]

Yeah, think we need to jump in and plan what data comes in and out, and get some coding. We can always refactor and reorganize

[mottosso]

I'd be happy for you to take the lead on that, @tokejepsen

[tokejepsen]

Cool, I'll have a look at breaking down the tasks.

[mottosso]

Let's keep the issue around for reference, but open up new issues or conversations about specifics once we get there.