I’d highly recommend ensuring the parent workfile path is stored in the publishedFile entity for debugging purposes. The default behavior is to take the workfile’s version, but it should be fairly easy to replace that with a function that finds the next available publishedFile’s version number. I imagine you can do this with a custom collector or publish_file publisher2 hook. Ok, and I see your intention of grouping all task publishes per step. This logic works for me and I’m not understanding the utility of your desired workflow. If you publish from a v2 workfile, sg will save the file, ensuring it is up to date and it then copies this file and renames it based on your publish template, before finally save-as version up. Are you not duplicating functionality here?Īs for work file versioning. How does it differ from your asset entity? What fields does it have? Also, you talk about about publish items without once mentioning “publishedFiles”. When I published a new file, it replaced v001 with the current scene, and saved it as v002 as well… When I published again, it replaced v002 with the new scene, and saved it also as v003…Ĭoult it be because of my settings in tk-multi-publish2.yml, cause I haven’t touched any of the hooks yet. (plus, it overwrites the latest version and creates a new one…) Location: I’m not really publishing session geometry at the moment). tk-multi-publish2/basic/publish_session_geometry.py" Here is the relevant sections of my templates.yml What do you think the best approach would be to achieve this? If you think this is conceptually wrong, I’d be happy to hear your thoughts though! That’s the way I’d like to set up our pipeline. So basically when I publish, I want the publisher to save my scene as a working file, and also to export a number of items from the scene as PublishedItems - each one following its own versioning. That’s why I want to keep track of these PublishedItems separately. And it would be very hard to find the latest version of a PublishedItem if I had to search through all the tasks folders in which that item could be. Therefore if the version number were inherited from the working file, it would be inconsistent. The reason behind this choice, is that often the same asset is worked on in several tasks. To represent this, I created the PublishedItem entity. Published files are indeed connected with a task (in which they are generated by it), but in fact they represent the evolution of an asset (asset in a generic sense, not a shotgun asset). Working files represent the evolution of a task. Yes I do want to have publishes which are versioned separately from working files. How should I go about this? Do I have to change UI, hooks and core modules of tk-multi-publish2 ? Maybe I’m misunderstanding what the publisher is supposed to do, but I really wasn’t expecting it to save any files using the maya_asset_work path.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |