Milan Kolar

Members
  • Content Count

    79
  • Joined

  • Last visited

  • Days Won

    13

Everything posted by Milan Kolar

  1. Have a look here. https://github.com/kredencz/ftrack-event-plugins-kredenc/blob/master/thumbnail_updates.py We're listening to events on `assetversion` where action is `encoded`, then grab a thumb and push it to the parent. Using Toke Jepsen's event server script, we're running a lot of these little event listeners.
  2. I've noticed that there isn't specific trello card for being able to play clip without their handles. We're running into this every day in internal review, to the point, that the online review is becoming very hard to use on longer projects (tv shows), where the continuity of movement between shots is important. We have to do all sequence review in nuke studio to see shots in context correctly.
  3. We've been craving something like this for long time now actually so I'm glad it's been brought up. Currently we make multiple components and supervisor just uses the version to quickly jump to the folder where they're stored using action. Having multiple reviewables per version would be amazing. Especially for modelling as Thirtydevil mentioned, but also for lookdev (multiple lighting setups)
  4. @pritchardhobe you should get an invite
  5. Very interesting idea. Even though we've never really longed for something like it, I'm sure we'd start using it right away and it would be clearer for the client. Right now we're also sending multiple review sessions if they concern different things (for example one session for fx approvals and one for animation). With this feature we could be sending dailies (which we'd love) that would be organised inside for clarity. My approach would be more of a 'playlist' style, where we could set multiple playlist withing the review that could contain the same version if need be. Client could then choose a playlist inside the review, or show all versions. If 'show all' could be disabled, then it would work exactly as Alberto's request, but having the extra option for other cases. Just writing this down I can think of plethora options to use it. Mockup different cut versions with scrambled shots or different shot versions (that would of course need the sequence play in client review ) and so on.. Long story short: I love the idea
  6. Hey. This should help you. We've been using it for over a year now. https://github.com/tokejepsen/ftrack-event-server edit: forgot to attach the link
  7. Agreed 100%. We rarely use the dates on the tasks, so we always put some proxy dates just to be able to link tasks together.
  8. YES. I'm pretty sure there is thread here somewhere where we discussed exactly these points. We use manual editing on time log a lot and we pretty much gave up on checking the actual times now and just keeping track of durations. It would be nice to be able to rely on start and end time though. We could quickly tell what were overtimes and such.
  9. So maya 2017 is out just in time for us to start testing it on some new production. However as you might have noticed. PySide is no longer available to make way for Qt5 and PySide2 bindings. That of course means that ftrack-connect is currently incompatible with maya 2017. Do you have an estimate about when it might be? I realize it's not quite a switch of a button change, so maybe have a look at https://github.com/mottosso/Qt.py to stay backwards compatible as much as possible.
  10. We just use a simple replace on all the keys to make sure, there are no unwanted characters in anything. key = key.replace(" ", '_').replace('\'', '')
  11. @FranZ Hey. I've sent the invite now. You can either send me a private message here with the emails or I can make you an admin if you wanna invite people yourself. Either works.
  12. It does return only 1 value, however it's wrapped in a `QueryResult` object which is technically a list. `.one()` ensures that there was actually only one result of the query and returns it, otherwise it fails. Say you just ask for a shot named `sh010`, there's a big chance you'll have the same shot name in another project so the query would have multiple results, hence raising and error when asking for just one. Have a look at the API reference here Query API ref
  13. To add to list these are some thing more in a bug than a feature category. Adding time logs by just typing a duration in the main field and pressing save, should use current time as end time, rather than start. Editing time logs should allow changing the stop time as well as start time, currently the only way to change timelog is changing duration. Something to deal with the occasional super long day (as instinct-vfx mentioned) would be great. Maybe a notification that pops up every hour after certain time that prompts user to confirm he's still working, if he doesn't it turns off the logger, because he's most likely gone home. Ideally though this could all be integrated with connect. Auto start timers on launching app for task, and stopping when artist closes it.
  14. It does complicate it a bit. The thing is, that we actually find the information and all approved versions quite useful. It's good to see what has been approved throughout the life of an asset. Anyways I've added the master checkbox now and it's working quite well. Might rethink it later on though :).
  15. Apart from working on own shots and assets, he watches versions that get published (filtering to 'pending review' status) so he can review them. That's why we use the 'file' status on things that shouldn't reach him. I just feel that versions view is cluttered with lots of 'files'. You mean republish v012 as v016 for instance?(related to my example above) Firstly because of disk space, We're always fighting for that (could be solved with hard/symlinks possibly), another reason is the fact that it's and extra action that seems a bit unnecessary if we already have a version with that content. Doing all this with statuses works, it's just inconvenient. Plus it's also a case of having to change statuses on multiple asset versions. Example: Animator publishes a shot. He creates assets of types 'cache', 'camera', and 'animation' (the last one would have the review quicktime and the scene components). When shot get's approved, all of these need to have status updated. It can be done with event server, but it's not particularly pleasant.
  16. Not sure how else to calls this, but basically I'd like to start a discussion about assets/version/published (whatever you wanna call it), that are not subject to review. We have a lot of things that are 'pure data publishes' and reviewing them doesn't make much sense, or it's done between artists themselves. Take a model for example, we go through approval process in terms of looks but after that, there might be another 10 versions of back and forth between modeler and rigger to get it technically correct. Supervisor doesn't want to be dealing with minor tech fixes (and often really doesn't need to), but new versions of this model keep popping up for him. The same is true for tracked cameras, rig tweaks that animators request, work scenes etc... The point is that the way I see it, there are 2 types of assets, 'reviewables' and 'data'. Right now the way we deal with this is setting a version status to 'file' which indicates, that its just there to be used, not reviewed. However that is far from ideal for plethora of reasons. I'm wondering if anyone else has these problems, or if we're just thinking about it differently than everyone else. Another aspect to this is marking which version is 'current'. As we all know, it often happens, that a version 15 get's approved and 3 days later someone decides that v012 was actually better. One way to save this info is of course 'un-approving' v015 and approving v012 again, so everyone knows what is currently considered the best for production. In practice this is difficult to keep on top of and very often we end up with 5 approved versions and it's tricky to figure out which is 'THE' approved version. It would be lovely to have an option of an exclusive checkbox style attribute on asset version, that simply states the master version to use. That way we could keep statuses for review purposes (nice to know at the end, that we approved 15 version of something ) and have this attribute to inform everyone about the latest and greatest. I do realise that this is slightly convoluted post, but let's be honest. Versions and published files is a convoluted topic by definition so let's try and untangle it a bit. Any workflow suggestions are welcome and will certainly help others too.
  17. Yes. So that client can see the shots in context of the 'edit'. We're currently having to export videos compiled of multiple shots, which is very easy for the client to comment on, but we then have to transfer the feedback manually to it's respective shots. There's another aspect of this, which applies to the internal review tools too and that is handles. It would be amazing to be able to take handles on shots into consideration and cut them of when reviewing multiple shots in sequence., we would be essentially then able to reproduce the edit in the web browser and it would make reviewing infinitely easier.
  18. Depends on what API are you using. The first link is for the old API, while the second one applied to the new one. At this point I'd probably just start with the new one and only got to the old if you run into something it can't do.
  19. I've set it up so that anyone with @ftrack.com email address can log in without an invite, in case developers want to peek in here and there.
  20. Soo. I went ahead and created an Ftrack Slack User Group. However there's this small problem I haven't realized till now. Slack is not very good with public access, so every person needs to get an invite (or be within a specific domain, which is even worse). There is this lovely service called slackin, but that of course needs to run on something. Right now I'm ok with just sending out invites like crazy if anyone asks here to get it going. Theoretically as it grows this won't be an issue, because any member can send an invite. It'll just be a bit of a hassle at the beginning. Maybe ftrack guys would be interested in hosting this tiny slackin service, to make it easier? Anyways the address is: ftrackusers.slack.com Come join the party... (it's very, very lonely right now )
  21. Your best bet is probably task templates. They are additive, so if you make templates with just one task, you can have good control over adding them to multiple entities then.
  22. 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 )