Jump to content

Milan Kolar

Members
  • Content Count

    81
  • Joined

  • Last visited

  • Days Won

    14

Posts posted by Milan Kolar

  1. Another useful hook with this. Start timer automatically with app launch. Now we need to figure out how to stop it automatically and there will be some happy producers walking around here.

    import logging
    import ftrack
    import ftrack_api
    
    logger = logging.getLogger()
    
    def start_time_on_launch(event):
        '''Modify the application environment and start timer for the task.'''
        data = event['data']
    
        username = event['source']['user']['username']
    
        session = ftrack_api.Session()
        # Get user from username
        user = session.query('User where username is "{}"'.format(username)).one()
        # Try getting taskid from event selection
        try:
            taskid = data['context']['selection'][0]['entityId']
        except:
            logger.info('Unable to determine task. Timer not starting')
    
        if taskid:
            task = session.query('Task where id is {}'.format(taskid)).one()
            logger.info('Starting timer for task: ' + task['name'])
            user.start_timer(task, force=True)
    
    
    def register(registry, **kw):
        '''Register location plugin.'''
    
        # Validate that registry is the correct ftrack.Registry. If not,
        # assume that register is being called with another purpose or from a
        # new or incompatible API and return without doing anything.
        if registry is not ftrack.EVENT_HANDLERS:
            # Exit to avoid registering this plugin again.
            return
    
        ftrack.EVENT_HUB.subscribe(
            'topic=ftrack.connect.application.launch',
            start_time_on_launch
        )
    

     

  2. So I had some time to play with this a little bit and came up with compact and quite efficient way of dealing with environments using launching events. Technically all that is needed is one hook that listens to the launching events and appends environments from simple .json config files based on app identifiers.

    The hook looks for .json files in 'FTRACK_APP_ENVIRONMENTS' and tries to find 2 configs. One that is version independent i.e. 'maya.json' and one that is version dependent i.e. 'maya_2016.json', then it adds both into the environment. Config file names mus match the app identifier or the first part of the identifier when split by '_'.

    You can then have a hierarchical environment config files, where maya.json loads regardless of maya version you launch, and maya_2016.json gets added on top of the environment when you launch Maya 2016 from ftrack.

    'FTRACK_APP_ENVIRONMENTS' folder can then look like this for instance:

    • maya.json
    • maya_2015.json
    • maya_2016.json
    • maya_2016.5.json
    • nuke.json
    • nuke_9.0v8.json
    • houdini.json
    • houdini_15.json
    • etc....

     

    This is the core part of the hook (full hook attached):

    def modify_application_launch(event):
        '''Modify the application environment and start timer for the task.'''
        data = event['data']
    
        context = data['context']
        app = data['application']
        environment = data['options']['env']
    
        env_path = os.environ.get('FTRACK_APP_ENVIRONMENTS')
    
        env_files = []
    
        # determine config file for version independent environment
        app_name = app['identifier'].split('_')[0]
        app_file_name = '{}.json'.format(app_name)
        env_files.append(os.path.join(env_path, app_file_name))
    
        # determine config file for version dependent environment
        variant_file_name = '{}.json'.format(app['identifier'])
        env_files.append(os.path.join(env_path, variant_file_name))
    
        env_add = []
    
        # loop through config files
        for env_file in env_files:
            try:
                env_add = load_env(env_file)
            except:
                env_add = None
    
            # Add each path in config file to the environment
            if env_add:
                for variable in env_add:
                    for path in env_add[variable]:
                        ftrack_connect.application.appendPath(
                            str(path),
                            str(variable),
                            environment
                        )

     

    This is what the config file look like then:

    {
        "MAYA_PLUG_IN_PATH": [
            "K:\\.core\\dev\\maya\\plug-ins"
        ], 
        "MAYA_AUTOSAVE_FOLDER": [
            "C:\\mayatemp\\autosave"
        ], 
        "MAYA_SCRIPT_PATH": [
            "K:\\.core\\dev\\maya\\scripts", 
            "K:\\.core\\dev\\maya\\shelves", 
            "K:\\.core\\repos\\maya\\scripts", 
            "K:\\.core\\repos\\maya\\prefs\\shelves"
        ]
    }

     

    Now quite frankly, I think that a simple hook like this (probably a bit more robust version) should be a part of the default connect installation. Straight away people would have 3 options of modifying the app launches. 

    1. Only need to modify environment: Add your json formatted environment file to 'FTRACK_APP_ENVIRONMENTS' and name it 'app_identifier.json' (e.g.: maya_2016.json)
    2. Write your own hook that catches launching events and modify the launch that way.
    3. Change the launcher hook in connect and modify to your heart's content

     

    One way or another, our enviro setups just went from lot's of python file, to a simple json file per app without the need to tinker with default hooks. Thumbs up.

    modify_app_launch.py

  3. This is getting very close to a simple a straightforward system. I have however ran into some issues.

    The most prominent right now is the fact that I have no way of finding out what task/entity was the source of this launching event. It's not included in the event data and because it seems that this event precedes the ftrack addition of env variables the environment is missing the 'FTRACK_TASKID' key too.  It's important to be able to tell what originated the launch event because the enviro usually changes based on what project or task we're launching (different plugins for example.

     

    EDIT:

    Ah. One of those where you completely skip on part of docs and then realise it's of course all there. If anyone else enjoys skipping important parts of docs, then here's how you get it.

    event['data']['context']['selection'][0]['entityId']

    So considering I found it...Nice work guys.

  4. 18 hours ago, Tony said:

    Any way to link the two?

    That would be lovely addition. Currently we practically don't use the planning because people feel that it's a bit of a double work. Even such simple thing as task inheriting start and end dates from their phase in planning upon creation would help. 

  5. On 22/12/2015 at 8:50 AM, Mattias Lagergren said:

    Would this work for you?

     

    It looked promising, but I'm afraid it doesn't work. The customised action runs first, however, stopping the event propagation kills off all the other actions, so you end up with only this one in the list. Not stopping the event, of course doubles up the action in the UI and runs it twice.

  6. Isn't that what the included task attribute 'worked hours' or 'worked days' (depending on your settings I believe) does? I believe it just calls {self.worked} in an attribute.

     

    EDIT: sorry I just re-read your question and realised you're asking for a sum of tasks on the shot... Very good question. I can't find anything about accessing children attributes on in the docs. It would however be most useful.

  7. For a quick start it would help if any plugins on custom paths, that have the same name as the default ones, would override the defaults. Right now I have to delete the ones I'm tweaking from the connect's resource/hook, so it doesn't appear twice in the actions. I don't want to be tweaking them there directly purely because I want to keep any custom code separate.

     

    Simplifying this workflow is absolutely essential at this point. Having to extract all of the application launchers from connect and tweaking each of them just to add a few environment variable across the board is a bit of an overkill. 

  8. I believe that's a number of comments. However it doesn't seem to always correspond. Many shots that we have with 3-4 comments only show number 2, some even 1. But in general it should mean, there are comments on the task

  9. This!!!

     

    Something along these lines would be really great. I've been toying with the idea of creating a separate project for exactly this purpose, but it would be a bit clumsy to find things quickly. Preview playback while hovering over the thumbnail, would pretty much solve this right away.

  10. Hey guys. 

     

    One thing I'm dealing with right now and it appears I'm stuck. We have 2 shows using the same schema. However midway through production one of them started changing a bit in terms of requirements from client, director etc. So I need to tweak the schema for this one a bit. Different statuses, plus some other config differences. The question is. Is it possible to change the schema after the project is created? I didn't find a way, just as well as I didn't find a way to duplicate schema. That would be super helpful too considering how annoying it is to keep creating new ones all the time.

     

    Thanks

     

    EDIT:

     

    I forgot to add, that my aim is to separate these two shows, because we don't want the changes made on show2 reflected into show1

  11. For quite some time now, It's become clear to us that we need a bit more detailed task templates for shots. In particular we'd like to be able to have more than one task of the same type on the shot and ability to give the task custom names in the templates.

     

    This is especially important on episodic projects, which have tons of shots and due to production speed often split shot into smaller chunks done by different people. For instance we might have someone do the main animation and someone else do background characters at the same time, hence two animation tasks which need to be named accordingly (fg anim, bg anim), or we have 3 types of effects on the shot: smoke, cloth, rocket jets. We have 3 FX tasks with different names. These repeat themselves again and again and currently we can't have them set up automatically with task templates.

     

    Ideally we'd the templates to work in a manner, where you can set up all the info for each task. Priority, status, comment etc. That way they could be used effectively by coordinator.

     

    Cheers

     

    Milan

  12. As a very first step I'll just say what we are doing now, to make it a bit easier to manage. Instead of treating actions as a standalone piece of script we only ever run them as connect hooks. So we have a directory with all our actions in it and this directory is set in the `FTRACK_EVENT_PLUGIN_PATH`. That way every machine running connect has access to all the actions straight away.

     

    There is a small difference when writing action for this workflow as it has to include register function for it to be picked up by connect. Here is the boilerplate code that let's you run action as standalone or as connect hook.

    https://bitbucket.org/snippets/milankolar/gE577

     

     

    My point is. I everyone wrote actions in a way that runs as ftrack hook out of the box, then it's a simple matter of dropping them into studio wide `hooks` directory. 

     

    Another thing is, that writing action themselves should probably be simplified if possible.

  13. Your particular problem might be due to many things. If you post some more info, maybe someone might be able to help you here, but certainly get in touch with thinkbox support. They are responsible for deadline-ftrack integration. 

     

    To be honest I had the same experience with their submitter from houdini (didn't work at all) and nuke version works, but it's practically unusable in production. I had to spend some time working on a almost ftrack deadline integration, rewriting the submitter and heavily tweaking their event plugin to be able to use it at all. 

  14. After using it with multiple clients now I have some more comments.

     

    1. comments section should be expanded by default when they open the session. You'd be surprised how many people never find it, hence don't read comments of others, or don't realize they can comment. Even though we always send an e-mail explaining that it's all there. They need to see it all right away.

     

    2. Description of version. We'd like to be able to write a basic description to versions that appear somewhere very visible. For instance "Matte paint and snowing final". The point it, that now we have to write it separately on each shot as comment in client review, which is tedious, and again is not visible unless you expand the comments section. We should be able to add this comment in bulk when preparing review. 

     

    client_review_ui.jpg

     

    3. In relation to number two. We'd like to see also spreadsheet view in review prep. This should show current state of review. List of people and whether they approved shot or not already. Now we have to keep generating reports to see this info. We'd like to open client review in ftrack and see all the important info in glance. Something like this.

     

    client_review_spreadsheet.PNG

     

     

    4. Option to sort versions by hierarchy when preparing it. Every time we have version arranged back to front and have to rearange by hand, qhich is a pain with 20+ shots to review.

     

    5. Customize the text of the invite email. We always have to send separate mail to give some detail. Or at least option to get the personalised links, so we could copy them to normal e-mail. 

     

    And lastly as I've seen mentioned somewhere already. Bigger company branding. Some way to put logo on the welcome page and more readable logo in the corner of the review page, ideally with option to put company name as text next to it.

     

    Cheers

     

    Milan

×
×
  • Create New...