Leaderboard

Hey @Remus Avram Is this what you are looking for? https://forum.ftrack.com/topic/895-filter-by-component-name/

Hi, Is there a system to check in ftrack not only the latest versions but a "version to use" too? Not always the latest version is the version that has to be used (even if approved) This flag should be addable only on one version per department to be sure to have always only one version to use THX, Luigi

Hi, is there a possibility to add an extra filter option in ftrack under Report-->User Breakdown. ISSUE At the moment you can filter by: Month Project Option "Project" will filter ONLY the Artists assigned to the project and NOT the time their tracked ON the project (so we get tracked time from other projects too) It would be usefull to be able to filter only the tracked time of a specific project Thanks, Luigi

I see, thank you for elaborating. The best solution at the moment would probably still be an event listener that warns/revert changes. A custom attribute could be set and read on certain users to allow them to modify their timelogs regardless of that limit. I will update our feature request with details from the use-case you provided.

Hi Remus, this makes sense and there are a few requests for similar features. We have not made any decisions or progress on this matter yet. The best solution at the moment would be to listen to the timelog changes with an api listeners and warn/revert the change

I can see why linking asset builds to a shot might be helpful. Let's walk through how I imagine that to work out, and let me know if I'm misunderstanding something. You have an assetbuild called "characterA" where you have a "rigging" task. From the "rigging" task you publish a Maya scene with a rig in it. You then link the assetbuild "characterA" to shot "sh0010". An animator opens an "animation" task on shot "sh0010". Now the asset importer would list all the assets on the assetbuild "characterA", because it is linked to the shot, and the animator would need to choose which asset (assetversion) to import. In a more advanced pipeline you would be able to "build" the shot by importing all the assets needed. We work from the "animation" task launched, finding the assetbuild "characterA", and then we need to assume what assets we want to import. This workflow could definitely work, but it would be very prone to production mistakes. What asset should the animator import if there are different versions of the rig? This kind of information is usually something a supervisor or coordinator would know. The animator would probably ask, but that doesn't really get us to a very optimized workflow, because we could just skip the linking and the animator would just import the rig asset directly from the "characterA" assetbuild by asking. Another problem with this workflow is when it comes to exporting Nuke scripts from NukeStudio. Here we end up with a lot of assets (one per shot usually) which the compositor needs to filter through to get the Nuke script asset for their shot. The ideal workflow is that the supervisor or coordinator can link/setup a shot, and the users get all the assets needed for the shot. If we go down the case from above, but with the feature of being able to link assetversions to shots, here is how I imagine it going. You have an assetbuild called "characterA" where you have a "rigging" task. From the "rigging" task you publish a Maya scene with a rig in it to an asset called "rig" with a version of 1, hence referred to as "rig_v1", with a "main" component. We now link "rig_v1" to shot "sh0010". An animator opens an "animation" task on shot "sh0010". Now the asset importer would list all the assetversions linked to the shot. In this case we only have the assetversion "rig_v1". The animator imports "rig_v1" without the need to ask anyone in the production about which assets should be used in the shot. This scales up nicely because the decision about which assets to use in the scene has already been made for the animator, so you could essentially have a "Import all linked assetversions" button. Linking assetversions to shots/tasks also works well when exporting Nuke scripts from NukeStudio because the compositor does not need to filter through all the other export assets but only gets the list of linked assetversions in importer, or the pipeline can easily make that assumption when hitting a "Setup script" button. There are some areas where this workflow falls a bit short; components and updating. If a studio utilizes different components than for example "main", it'll be difficult to assume what to import if there is a "Import All Linked Assetversions". This can however be overcome by just bringing all components or the studio making its own "Import All Linked Assetversions". When publishing a new assetversion, the already linked shots/tasks would have the old assetversions still linked. You would easily traverse the dependency graph and update the links, or leave it and let the asset management part of ftrack-connect handle updating. You would only really need to import all the linked assetversions once, but in the "Import All Linked Assetversions" there could also be a follow up "Scan for newer versions". Phew! That was quite a post I hope it makes sense, or at least some of it.

It would be good to be able to do X amount of users without specifying the exact users. For example we know we will need 5 FX people on project X between dates Y and Z. This could be used to estimate license usage and renderfarm load earlier in the process than when there actually is decided who is going to work on it.

This feature is already planned - I do not have any dates yet but it is on our priorities list. I've heard this one from some customers - sounds like a usable idea. As a workaround it would be possible to use the API/action to accomplish this.

Hi, If you are able to launch RV with the integration from ftrack Connect, but not via the review menu, that seems to indicate that either the legacy Python API or credentials has not been made available to the integration. See the getting started instructions here. No versions found seems to indicate that there are no versions published linked to the selected task. Can you try opening the Asset version directly, to verify if that works?

As a reference, here is the original design/research I did for ftrack v3. Not all ideas/features got implemented. /F timelogging-for-v3.pdf