Jump to content

Milan Kolar

  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by Milan Kolar

  1. Hi. 

    We'll try updating to this latest branch.  We've been using the previous one for python 3 for almost a year with only one problem, that we're running into now. It's compatible with either python3 or python 2, but doesn't work in mixed environment. So if we install it with pip3 and then try loading it to maya, it crashes on multilpe wrong imports. We'll investigate more closely and post here.

  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. 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

  5. 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.

  6. 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.

  7. 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

  8. 9 minutes ago, instinct-vfx said:

    I agree with connect integration though i am unsure if this is maybe too shop-dependent to be generally implemented. e.g. i would need this rather configurable and user selectable at different leves (e.g. opening max in 3 different shot contexts does not necessarily mean i need to track to the last one only. Might be opened for reference etc.)

    Very true actually. 

  9. 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.

  10. 5 hours ago, Mattias Lagergren said:

    I see your point but I wonder if the solution is to have a master checkbox, or if that just complicates it.

    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 :).



  11. 6 minutes ago, tokejepsen said:

    Could you outline what the Supervisor is currently doing? I'm a bit confused as to why the Supervisor gets notified of tech fixes.

    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'. 


    9 minutes ago, tokejepsen said:

    How come you aren't just republishing the old version?

    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.



  12. 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.

  13. 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. 

  14. 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?



    the address is: ftrackusers.slack.com

    Come join the party... (it's very, very lonely right now :) )

  • Create New...