tokejepsen reacted to lorenzo.angeli in ftrack_studio rez packages
Hi all and Happy New Year !
With the experience built in the past years helping various offices setting up ftrack, I decided to wrap a rez repository where to collect all the needed bits and pieces to have ftrack_studio running as rez package.
The repository can be accessed here http://git.efestolab.uk/rez/rez-ftrack for now while in development.
(planning to move it later to bitbucket)
The long time plan is to make this repo able to support all the needed platform and systems supported by ftrack , but at the moment I'm focusing mostly on linux.
The installation is somehow tedious as the packages have to be installed in a certain order,
I'm looking into a more automated system though, but is really not a priority.
(check the readme to see the actual installation order)
In order to make the default application work off the shelf , a custom package called ftrack_hook_override is provided, and original hooks are disabled.
If you manage to install all, you can then run :
$ rez-env ftrack_studio
> $ ftrack_studio
At the moment I'm matching the dependencies for the latest (2.7.3) version, and all the connector plugins are loaded by default (this might change later , to allow more dynamic settings).
If you have any questions or issues please let me know !
At the moment you need to have already available the basic packages such as qt, pyside and python installed as rez-packages.
Please, bare in mind is currently in development, so things might be changing fast, and some packages might still be missing.
If you think you can help , please do !
Below the resolution package for ftrack_studio 2.7.3
requested packages: ftrack_studio ~platform==linux (implicit) ~arch==x86_64 (implicit) ~os==Fedora-27 (implicit) resolved packages: appdirs-1.4.0 /home/efestolab/packages/appdirs/1.4.0/platform-linux/arch-x86_64/python-2.7 (local) arch-x86_64 /home/efestolab/packages/arch/x86_64 (local) arrow-0.10.0 /home/efestolab/packages/arrow/0.10.0/platform-linux/arch-x86_64/python-2.7 (local) backports_ssl_match_hostname-220.127.116.11 /home/efestolab/packages/backports_ssl_match_hostname/18.104.22.168/platform-linux/arch-x86_64/python-2.7 (local) chardet-3.0.4 /home/efestolab/packages/chardet/3.0.4/platform-linux/arch-x86_64/python-2.7 (local) clique-1.5.0 /home/efestolab/packages/clique/1.5.0/platform-linux/arch-x86_64/python-2.7 (local) ftrack_connect-1.1.2 /home/efestolab/packages/ftrack_connect/1.1.2/platform-linux/arch-x86_64/python-2.7 (local) ftrack_connect_foundry-1.1.0 /home/efestolab/packages/ftrack_connect_foundry/1.1.0/platform-linux/arch-x86_64/python-2.7 (local) ftrack_connect_hieroplayer-1.2.0 /home/efestolab/packages/ftrack_connect_hieroplayer/1.2.0/platform-linux/arch-x86_64/python-2.7 (local) ftrack_connect_legacy_plugins-1.1.0 /home/efestolab/packages/ftrack_connect_legacy_plugins/1.1.0/platform-linux/arch-x86_64/python-2.7 (local) ftrack_connect_maya-1.1.1 /home/efestolab/packages/ftrack_connect_maya/1.1.1/platform-linux/arch-x86_64/python-2.7 (local) ftrack_connect_nuke-1.1.2 /home/efestolab/packages/ftrack_connect_nuke/1.1.2/platform-linux/arch-x86_64/python-2.7 (local) ftrack_connect_nuke_studio-1.1.1 /home/efestolab/packages/ftrack_connect_nuke_studio/1.1.1/platform-linux/arch-x86_64/python-2.7 (local) ftrack_connect_rv-3.7 /home/efestolab/packages/ftrack_connect_rv/3.7/platform-linux/arch-x86_64/python-2.7 (local) ftrack_hook_overrides-0.0.1 /home/efestolab/packages/ftrack_hook_overrides/0.0.1/platform-linux/arch-x86_64/python-2.7 (local) ftrack_location_compatibility-0.3.2 /home/efestolab/packages/ftrack_location_compatibility/0.3.2/platform-linux/arch-x86_64/python-2.7 (local) ftrack_python_api-1.3.3 /home/efestolab/packages/ftrack_python_api/1.3.3/platform-linux/arch-x86_64/python-2.7 (local) ftrack_python_legacy_api-3.6.2 /home/efestolab/packages/ftrack_python_legacy_api/3.6.2/platform-linux/arch-x86_64/python-2.7 (local) ftrack_studio-2.7.3 /home/efestolab/packages/ftrack_studio/2.7.3/platform-linux/arch-x86_64/python-2.7 (local) idna-2.6 /home/efestolab/packages/idna/2.6/platform-linux/arch-x86_64/python-2.7 (local) lucidity-1.5.0 /home/efestolab/packages/lucidity/1.5.0/platform-linux/arch-x86_64/python-2.7 (local) os-Fedora-27 /home/efestolab/packages/os/Fedora-27 (local) platform-linux /home/efestolab/packages/platform/linux (local) pyparsing-2.2.0 /home/efestolab/packages/pyparsing/2.2.0/platform-linux/arch-x86_64/python-2.7 (local) pyside-1.2.2 /mnt/zeus/storage/rez/packages/rez-base/pyside/1.2.2 python-2.7.14 /mnt/zeus/storage/rez/packages/rez-base/python/2.7.14/platform-linux/arch-x86_64/os-Fedora-27 python_certifi-2017.11.05 /home/efestolab/packages/python_certifi/2017.11.05/platform-linux/arch-x86_64/python-2.7 (local) python_dateutil-2.6.1 /home/efestolab/packages/python_dateutil/2.6.1/platform-linux/arch-x86_64/python-2.7 (local) qt-4.8.6 /mnt/zeus/storage/rez/packages/rez-base/qt/4.8.6 qtext-0.2.0 /home/efestolab/packages/qtext/0.2.0/platform-linux/arch-x86_64/python-2.7 (local) qtpy-0.3.4 /home/efestolab/packages/qtpy/0.3.4/platform-linux/arch-x86_64/python-2.7 (local) requests-2.18.4 /home/efestolab/packages/requests/2.18.4/platform-linux/arch-x86_64/python-2.7 (local) riffle-0.3.0 /home/efestolab/packages/riffle/0.3.0/platform-linux/arch-x86_64/python-2.7 (local) shiboken-1.2.2 /mnt/zeus/storage/rez/packages/rez-base/shiboken/1.2.2 six-1.11.0 /home/efestolab/packages/six/1.11.0/platform-linux/arch-x86_64/python-2.7 (local) urllib3-1.22 /home/efestolab/packages/urllib3/1.22/platform-linux/arch-x86_64/python-2.7 (local) websocket_client-0.46.0 /home/efestolab/packages/websocket_client/0.46.0/platform-linux/arch-x86_64/python-2.7 (local)
tokejepsen got a reaction from Remus Avram in Right-click selects as well.
If you have an entity selected in overview, then right-click > Actions on a different entity, you will get the actions for the selected entity and not the entity you right-click on.
Either the behaviour should be that right-click selects as well, or right-click > Actions will know which entity is right-clicked on.
tokejepsen got a reaction from Omry in Incoming links
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.
tokejepsen reacted to Mattias Lagergren in ftrack connect version 0.6.2
I've just opened up the legacy plugins repository and the ftrack-connect-package repository.
ftrack connect legacy plugins contains the hiero plugin
ftrack connect package is a repository that we use to build the downloadable ftrack Connect package.
tokejepsen got a reaction from Mattias Lagergren in Batch Create repository
I was wondering whether Ftrack could make a repository out of https://www.ftrack.com/portfolio/batch-create ?
I implemented it for a studio, but there was some fixes I had to do to make it work; https://github.com/tokejepsen/ftrack-hooks/commit/1db02a0f99b99f213ad0dabe0bf4d1903263e750, which I thought might be better committed back.
tokejepsen reacted to postmodern in Houdini plugin
I finished Base ftrack-connect-houdini plugin functions.
Now Houdini can work with Scene, Geometry, Camera Assets (Publish, Import, Management).
Feedback it please!
Release Notes: http://ftrack-connect-houdini.readthedocs.io/en/latest/release/release_notes.html
tokejepsen reacted to lorenzo.angeli in Change Location pick Order
HI, we have been writing something which does what you are after: http://docs.efestolab.uk/tools/proxy-location/index.html
here a small video which show how it works : http://share.efestolab.uk/pydio/data/public/d246fc
overall though, the idea is to have a location which wraps all the final locations you want to publish to , and have a set of rules, that will be checking (component, task etc...) to decide which location is the most suitable.
tokejepsen reacted to Martin Pengelly-Phillips in Find what you are searching for in new API.
+1 A dedicated section on introspection in the docs would be useful.
Some more explicit examples:
# List entity types available to session >>> print sorted(session.types.keys()) [u'Appointment', u'Asset', u'AssetBuild', u'AssetType', u'AssetVersion', u'AssetVersionLink', u'AssetVersionList', u'BacklogGroup', u'Component', u'ComponentLocation', u'ContainerComponent', u'Context', u'Conversation', u'CustomAttributeConfiguration', u'CustomAttributeType', u'CustomAttributeValue', u'Disk', u'EntitySetting', u'Episode', u'Event', u'Feed', u'FileComponent', u'Folder', u'Group', u'Information', u'Job', u'JobComponent', u'List', u'ListCategory', u'Location', u'Membership', u'Message', u'Metadata', u'Milestone', u'Note', u'NoteCategory', u'NoteComponent', u'ObjectType', u'Participant', u'Priority', u'Project', u'ProjectSchema', u'ProjectSchemaOverride', u'Queue', u'Recipient', u'Resource', u'ReviewSession', u'ReviewSessionInvitee', u'ReviewSessionObject', u'ReviewSessionObjectStatus', u'Schema', u'SchemaStatus', u'SchemaType', u'Scope', u'Sequence', u'SequenceComponent', u'Setting', u'Shot', u'State', u'Status', u'Task', u'TaskTypeSchema', u'Taskgroup', u'Timelog', u'Timer', u'Type', u'TypedContext', u'TypedContextLink', u'TypedContextList', u'User', u'WorkflowSchema'] # Retrieve the class that represents a particular type by key. >>> entity_type_cls = session.types.get("Shot") >>> print entity_type_cls <dynamic ftrack class 'Shot'> # Examine attributes available on that entity type. >>> print sorted(entity_type_cls.attributes.keys()) [u'_link', u'allocations', u'appointments', u'assets', u'assignments', u'bid', u'children', u'context_type', u'custom_attributes', u'description', u'end_date', u'id', u'incoming_links', u'link', u'lists', u'metadata', u'name', u'notes', u'object_type', u'object_type_id', u'outgoing_links', u'parent', u'parent_id', u'priority', u'priority_id', u'project', u'project_id', u'scopes', u'sort', u'start_date', u'status', u'status_id', u'thumbnail', u'thumbnail_id', u'timelogs', u'type', u'type_id'] # Examine a specific attribute by key. >>> status_attribute = entity_type_cls.attributes.get("status") >>> print status_attribute <ftrack_api.attribute.ReferenceAttribute(status) object at 73957712> # Check whether that attribute is mutable etc. >>> print status_attribute.mutable True
tokejepsen got a reaction from Mattias Lagergren in Right-click Cards for Actions
That would definitely work as well. Might even be better, as it would be visually new in the interface meaning the user would be able to easier discover the feature.
Currently our artists have to expand a side bar to launch tasks, which they do a lot, so if this could be reduce from 2 mouse clicks/moves to a single mouse click, they would be happier:)
tokejepsen got a reaction from Mike in Custom lucidity with Ftrack Connect
With the current issue of the environment variables appending; https://github.com/Bumpybox/pipeline/issues/7, I would advise not to run "[pipeline_repo]\environments\ftrack-connect.bat" more than once. To enter the ftrack-connect environment use this method instead for the time being;
1. Run "[pipeline_repo]\launch\prompt.bat"
2. Run "activate ftrack-connect"
3. Run "python -m ftrack_connect"