Hello everybody.
Quick question. Has anybody created a hook or an edit so that publishing an asset creates a Shotgun version of the publish?
Let’s say you are publishing a modeling task you could automatically generate a turn table and add that to the publish and use that turn table a Version so that it can be reviewed?
Cheers
Hi Jerome,
Toolkit natively allows playblasts to be published if you have created them in your scene, check out this post from @philip.scadding;
If you set up a playblast in your Maya scene, the publish collector should find it and allow you to upload as a version.
Hi @DavidMason
Yes as you where replying I was as well checking the upload_version.py in the multi-publisher that already handles this.
Sorry for the bother.
So @DavidMason
Adding a media into the multipublisher inside Maya does create the version but then if you want that media to be taking into account as well as a published file in the system I guess that you need to add that media into the template config file right?
Cheers
Hi Jerome,
You shouldn’t need to modify the config at all to collect the playblast, check out this gif;
Works for both Basic and Advanced Config.
Hi @DavidMason
Yes that seem to work but what I am most interested in is the final registered path for that mov
As the schema on our project is way different than the default config I was wondering then if I should modify something specific like the template.yml so that the playblast publish gets copied out into our publish folder and that is the publish registered in shotgun.
Hello guys
So to do what I really wanted to do it wasn’t that hard but it wasn’t obvious either. We wanted the following behavior mainly for the needs of a particular show so bare with me… I am only posting this because it might be interesting for others in the future.
I wanted to fully override how the publisher2 handles mov files inside Maya. I wanted to fully override the fact that you can drag & drop files on the publisher except MOV files but at the same time I wanted the dropped mov file to be linked to the Maya session when publishing…
Somthing like this:
If you drag & drop any other type of file, the publisher will reject it. Now the Mov file that gets published get renamed so it doesn’t necessarily need to have a work template on the template.yml.
Some details.
First created two new settings on the template.yml (on maya asset and shot context)
Secondly, fully remove the default inheritance of the publisher collector for Maya by a replica of the original one but that will accepts MOV files. I removed the default (single) {self}/publish_file.py because I am inheriting from it on the publish_movie.py file so leaving the independent one would want to publish twice the MOV file
Thirdly the movie_collector.py
Lastly the publish_movie.py validate function.
By the way, the reason why the movie publisher is still checking things of the Maya session is that I use the work template from that part to be able to rename the mov file in the publish. I could probably directly get the name of the Maya file from the publisher rather than imitating the Maya session python file logic.
Anyway this is probably not the most efficient way of doing something like this and again this was needed inside our project so I highly doubt it could be used by others. I just found interesting how flexible the publisher is and how customizable it can be. The only flaw is the fact that to implement something like this you need to edit so many different files so if this isn’t something you handle quite often it can be pretty confusing.
Cheers
Hey @Jerome_Drese, thanks a lot for sharing that here!
It looks like it should all work well. I hope you don’t mind me sharing a few suggestions on best practice.
I’m not sure I fully understand here. I would recommend leaving the {self}/collector.py and then overriding only the methods you need to change and not calling super in them, if you don’t want the base implementation of that particular method. I would have a hierarchy that looks like:
{self}/collector.py:{engine}/tk-multi-publish2/basic/collector.py:{config}/tk-multi-publish2/maya/movie_collector.py
You should still be able to override the base behaviour in the areas that you want.
Also, I noticed that you are not using the {config} key and are instead using the {engine} key, so I assume you have had to modify the engine its self in order to add your code. I would personally recommend using the {config}, as this key points to your .../config/hooks folder.
The {config} key is covered here (just scroll down a little bit.)
Both of these suggestions should mean that your code is separate from the standard code, and will make it easier for you to update the Publish app and Maya engine without you having to change anything.
Nice work though getting that up and running!
I will take your recommendation 
definitely. I will add back the default collector and cascade the inheritance and not call super. That will be definitelly cleaner. At some point I think I was trying that but because I wasn’t totally sure at some point how much code I wanted to change it made testing a little harder but now that I know what I need I will make those changes.
For the engine part I did not wanted to have this behavior on other enginges than tk-maya and on our pipeline setup I am already calling a customized verison of tk-maya (to add some in-house tools) but it is a valid point as doing upgrades demands two updates simultaneously (tk-maya and the shotgun pipeline config). I will try to move my code away from the tk-maya hooks for the publisher.
Thanks again for the help and keep the devkit youtube videos thingy. Was way more simple (for me at least) to get going with those.
Hey @Jerome_Drese
I would highly recommend watching this webinar to understand the Publisher API a bit more. 
It would only be used on your tk-maya engine, because you would only set the Maya publish settings to point at that hook. The rest of the engines would use their own settings. I’d also still opt to keep as much logic out of the engine itself so the changes are limited to only those that must be made in the engine.
I’m not sure what tools you’re adding but maybe they could become Toolkit apps?
@Ricardo_Musch that’s the video that helped me the most. Sorry if what I did isn’t the most proper way, this is why I am posting so that I can benefit from everyone’s advice
@philip.scadding for the tk-maya changes I am basically adding some tools inside startup.py by adding MAYA_MODULE_PATH vars and overriding Maya Splash screen by setting the XBMLANGPATH path then I am setting some Maya settings and project settings on the userSetup.py. Some of which query things from Shotgun with the shotgun python api (like project resolution and framerate or such) and some Maya Evaluation Manager and Timeline cache specific settings (Maya 2019) that helps having a more stable sessions.
By the way I will probably post later a new topic about an mGear Shotgun Maya integration. I asked this on linkedin to @bouchep but this place is better to handle such topics. Will try not to diverge much of the central topic but basically because mGear’s uses Maya modules on releases I am thinking of the best way to handle it as a Toolkit app.
Hey Jerome,
you may be better off setting variables from the “before_app_launch” hook in the tk-multi-launchapp instead of the engine.
In the before_app_launch hook you can query what toolkit engine is being started and then apply variables from there for specific applications.
You can read more about it in: How do I set environment variables before launching software?
Okay this is where I start overthinking it because for example I found easier when the logic of one application (engine) is all in the same place and not sparse. This is where the TK shines and fails (please don’t take this as a non constructive feedback). The flexibility of the Toolkit is quite amazing and I like that it isn’t forcing anything specific upon the users but rather empowering them. The main issue is how much sparse things can get. So the tk-multi-launchapp has the before_app_launch but does it have something that can be triggered after launch app inside the engine that is running? If not then this would mean that I still have to create an override of tk-maya (of course this is if I want to keep things inside the toolit because I could write a userSetup that is fully outside of the toolkit and available for artists…)
In theory the less sparse would be to be able to do it all from the Pipeline Config setup by using hooks for everything but I am not the best suited at this point to judge the bad cases that this could bring. What are your thoughts on this @Ricardo_Musch @philip.scadding
I actually agree with you here. I think the engine should also have before_launch_app and engine hooks.
And after_launch maybe
We also always welcome constructive back, so I appreciate you saying that!
I have a few things to say around this.
About engines containing logic that is specific to them, I agree. It wasn’t the approach we initially took, as you can see with the workfiles app we have the engine specific hook logic stored in the app itself. However for apps that are cross engine compatible, since the engine is the hosts the app, it does make more sense for the engine to provide its own hooks for the apps it supports. We have started adopting this approach for newer engines, such as the new 3dsmax engine or the Aftereffects engine.
However, with that said, there isn’t engine specific before_app_launch.py hook behaviour by default, so the engine wouldn’t contain that hook. It would only contain the hook it if needed to override it, as you say we’ve opted for a sparse layout to avoid duplication of code and settings.
There is a core hook called engine_init.py that will be called whenever the engine gets initialized. You can check if the engine.name is tk-maya and then perform Maya specific operations. However, this can potentially get called multiple times in one Maya session if stuff gets reloaded. So I would probably just add an env var once you’ve run it once which you can check for on subsequent runs to avoid running the code multiple times.
Hello David I tried to do this to upload as a version and I couldn’t is there any video or documentation to do this?
When I drag the playblast the onyly option that appears on the ui is Publish to Shotgrid
Hi @DanRaigorSC the video posted by David is showing the default configuration of the Publisher. He generates a playblast and then goes to Shotgrid → Publish.
The Publisher automatically “collects” the playblast movie and add it to the publication.
If this is not happening to you I suggest you to check your templates.yml and the schema folders. Also check if the rendered playblast file is being saved into the correct directory: movies or images.
Good luck!
