I have an issue to discuss that we’ve been fighting for quite a while.
The question is how do you ensure picking up the right assets if the same type of thing is published from multiple tasks?
Example: Layout makes basic camera (sometime final) and publishes to shot/layout/publish/cam_v01.abc
Animator work with the scene, but reanimates the camera and publishes to shot/anim/publish/cam_v01.abc
poor lighter then needs to go through publish of all other tasks to make sure he actually has the latest versions of things,. This of course mostly happens if you don’t have everything scripted (and I don’t think you can account for absolutely everything) and people need to reference thing by hand here and there.
So far we’ve been dealing with this by not having ‘task’ publish, but rather ‘shot’ publishes. So every shot has a publish folder where people publish from all tasks. Meaning in case I shown before We would have
of course it looks less clean, than having work and publish folder per task. however, with new people coming in all the time (freelancers) it seems to be easier for them to grasp. Task is where I work, publish is where I share. If they need something for the shot, they simply look at shot publish, not needing to know which task it comes from. On the other hand this folder can become a bit convoluted.
So the discussion really is. How do you deal with this? I’m inclined to just force artists to simply go through all publish in tasks folders if they need something.
If the issue is to solely find all latest versions within multiple tasks it might be best to set up a UI that can do that. Instead of creating your own referencing tool, loading tool and manager I’d opt for something that’s quicker to set up. A UI that solely lists and allows you to grab the filepath. They would just search cam for the given shot and show the published among other tasks.
The question here is how are you defining your paths and how will you be retrieving those. Do you have methods in place to query the existing published. If so, how does it work?
Looking at this specific camera issue from layout -> animators it might be a good idea to assume the only camera will only ever come from animation. Either it’s not modified and similar to what the animator loaded from layout or it’s the new updated camera.
We’re actually trying to tackle a similar issue of ‘layout conventions’ and how those should be accessed for its information/contents in Pyblish Magenta. It’s a core feature of any production pipeline to query file locations (and versions) through a set of queries. Of course these queries could also be done against a database (ftrack, shotgun or custom) but it’d still need to format into a path.
In your example, doesn’t Animation always come after Layout?
In that case, if there is a camera in Animation, shouldn’t this always be the latest one for that shot? Or is it possible for Layout to publish a newer version that animators have to keep up to date with?
Not guaranteed. For example we had shots, where we needed to start blocking out animation before the layout was done. Just on base grid with one or 2 characters. When layout finishes, character is moved into correct position and animation continues. Rarely but it happens. (maybe 10% of shots where done like that on latest show.)
Theoretically it could happen that layout would publish new camera after animation. This can vary a lot depending on directors requests. So I don’t want to rely on order of tasks to know what is newer. Camera could potentially even change in compositing, which might need to be taken back into light for some extra passes. The pipeline is rarely linear enough to assume order of tasks.
The only reason for thinking of putting all publishes on shot level is really a convenience in case where you manually go looking for something (which still happens a lot actually). you just pop to publish folder a see straight away what has been published.
Currently we work like this (still tweaking our ways )
Input for Layout is storyboard/animatic, character rigs, sets (usually just proxy versions for speed), props.
Layout artist, takes all these and prepares scene for animator. Imports all geometry, places correctly, imports sounds etc. Most importantly set’s up camera which should be as close to final as possible (animated, camera shake, etc). In this step we sometimes do some very basic animations mostly related to set. A lift moving up for example.
Publish from this step is .ma or .hip scene which ready to be animated, plus usually camera and proxy geo in it’s place, in case we need to some 3d precomps. This scene also serves as rough proxy (in terms of floor and object placements for set dressing)
In full CG scenes we rarely skip layout, mostly because our animators are often ex-2d animators and tend to struggle with anything even slightly technical.
Practically no sett dressing is done here apart from things that are essential for animators to see.
Layout artist if for us ideally a generalist junior to mid, with good cinematic eye because of the cameras. There tends to be quite a lot of very simple modelling involved.
Set dressing can then happen simultaneously with animation because it uses the same input scene and builds on top of it. If set is done or half done, animator can reference dressed scene towards the end to make sure there are no problems with contacts and such, but that doesn’t happen often.
To sum it up.
We almost never skip it, it’s mostly about general scene layout and camera. It allows animators to focus on purely animation.
i am using ftrack for our current project. could you please suggest me how to mange shot wise abc cache, anim curve and camera.with different different task like layout, blocking and animation.
for Example we have 5 character and props in one shot. point is how to track abc cache version for each assets.
Would it be possible to elaborate a little bit? Maybe provide an example scene too, with spheres for characters or the like. Just want to make sure we’re answering the real issue.
Here are some things I’m missing that would affect any recommendation.
How many artists are you?
What is the average duration of a project?
What are the components of your work; e.g. full-cg, a mixture of live-action and cg, mainly live-action?
What is the target quality of your output? E.g. feature film, tv, internet, ads?
When you say “track”, what information are you looking to keep track of?
Who else is this information for, e.g. coordinators, just artists, surrounding pipeline tools?
What software(s) are you running? Does the published data need to work across applications?
-we are working on cg feature film(90 minutes). Currently 150 artist working on it.
-we need to track the versions of animCurve, abcCache of different assets
-pipeline tools (like when we publish abcCache of a particular asset, then it should be reflected in our pipeline tool like lighting pipeline tool or any department down the line)
-maya, nuke, houdini
-yes
I am talking about “Scene data Publish” from Tasks: Layout, Blocking, Animation like abcCache, animCurve, camera, review. For example: we have a scene of 2 players playing Badminton.
Here, we have:
2 Badminton players,
2 Badminton rackets
1 ball
all above assets are referenced in maya.
Please suggest us a way to efficiently create a structure in FTrack, so as to Manage the: * “Tasks” (Layout, Blocking, Animation, Lighting,…), * “Assets” (Player1, Racket, Ball,…), * “Versions” (abcCache version, say for the Animation Task or any other Task)
Its quite a broad question, and it very much depends on your existing structure and how you want your pipeline to look like.
I can only suggest how we are doing because other facilities will tackle it in different ways.
Tasks
We only deal with a certain amount of types of tasks. We don’t have Layout and Blocking as task types, but distinguish by the name of the task. Layout and Blocking would just be animation typed tasks, that are named “layout” and “blocking”.
On the file system we only ever care about the name of the task. The reason for this, was because Ftrack doesn’t support same named tasks within the same shot (and episode/sequence/asset).
Assets
We have a fairly simple asset structure, where types of assets can be: Character, Prop, Environment, Setup and FX. Again this greatly depends on how you want your Ftrack to look like.
We currently don’t track which assets are in which shots/tasks. That is more a limitation of the pipeline, rather than a decision. We don’t have any dedicated importer so we can’t consistently track this kind of data.
Versions
We tag objects in the scene files for export. This means the name of the object becomes the name of the component in Ftrack. We only have Ftrack assets by their task name, so when export from a task called “layout” there will only be a single Ftrack asset for any caching called “layout”.
)