iwootten Posted June 9, 2017 Report Posted June 9, 2017 Hi there, We use ftrack-connect-maya in order to manage our publishes. We're also using a 'master' scene file workflow to assist with layout of entire sequences. This file gets busy with a large number of rigs. When the time comes to move on to individual shots, we have a script that creates individual shot scene files from the master layout, based on sets of rigs. Part of this copies ftrackdata nodes from the original master file to the shot in order to reduce the load time of the maya scene for the shot task and remove unnecessary connections for the scene. Is there an impact of copying subsets of the ftracknodes in this way? Is there a better way to support this workflow?
lorenzo.angeli Posted June 13, 2017 Report Posted June 13, 2017 Hi Ian, I just tested what I think is the workflow you are using: 1) create a scene with a bunch of assets imported as reference thorugh import asset. 2) select few assets and export the selection (ftrack nodes included) 3) create a new scene and import the exported file 4) update assets. 5) publish the scene. Using this workflow I can't see many issues. Now on better workflows.... if you don't want to get you hand dirty with scripting I think you have a good one, otherwise you could go down this like: Create a custom layout asset which keeps the asset and their world location as metadata (no phisical file on disk). something like: [{'name': 'something', 'assetId': XXXXXXXXXX, pos:[XXX, YYY, ZZZ], version: XX}] Then with a custom import you could be able to select which one you want to import in a new scene (this could be loading the latest approved version of the given assetid or the set one), and position it on XX, YY, ZZ in your scene. the benefit of this approach is that you'd end up with a layout file which could be shared between applications (maya, nuke, max , houdini etc..), and allow you import it directly with the right version rather to have to update once imported. Hope it helps. L.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.