I have raised this suggestion before but thought I’d share it again. Thinking about the future of Flame, it’s current strengths and capitalising on that.
Right now, in a VFX facility filled with seats, Nuke has practically monopolised the market. Hard for Flame to compete. Flame still seems to have a good foothold with Flame freelancers with their own system or in small boutique post facilities. If Autodesk had a rock solid and secure way of bringing multiple remote Flame Artists together to work together easily and seamlessly on a project, then it could be a real strength for Flame as a product and also attract new talent to the ecosystem (including Nuke Artists who are jaded from years working with big VFX studios). It would be highly attractive to smaller facilities offering VFX as well as a quick way to scale for larger facilities.
How would it work?
Flame would act as the central hub at the hosting facility. There would need to be some kind of project server at the host facility. There would also need to be some kind of user database (based on Autodesk ID) at the host facility. From the host Flame, you would create batches/batch groups/some new smart solution (I’ll call them batch from now on for simplicity) for each shot you wanted to farm out. You would then assign access to that batch to an Autodesk ID. I know the following can be created in the cloud, but I also know a load of places that lock the expertise and want to avoid the cost and hassle of cloud.
Flame would either have its own remote secure file transfer “Wire” solution or alternatively be able to hook into one such as Aspera/SohoNet/Signiant/LucidLink etc;
for remote artists to be able to log into and transfer what they need. This should appear transparent though to the remote Flame Artist, it happens in the background controlled by Flame.
A remote artist would be given a link that you would sign into using your Autodesk ID (and potentially some kind of 2FA solution) that would connect the remote Flame Artist to the hosted Flame server. The project settings would be dictated by the host server too so that everyone is working in the same way. The remote artist could only see the batches assigned to them and then you could ‘localise’ the media which would set off a background “wire” as per the above. Potentially, as a security feature, no media could be exported from a remote project connected in this way too and the data would remain encrypted on the ‘localised’ remote Flame Artists storage.
The artist would work locally on their assigned shots and all batch setups would regularly sync to the main project server from the locally hosted server. The remote artist could also have the option of either publishing their shot to the host storage server (which would securely transfer the render back to the host) or alternatively send a burn render to the host server which would be smart enough to point to the original media but render the shot at the host facility. The burn process would potentially be smart enough to grab any media that has been created by the remote artist that is needed to do the render. As the batch setups would be synced to the host project server, it would then be easy for the “hero” Flame Artist to tweak a shot with clients in attendance.
The host Flame project would automatically have these publishes or renders available to them. It could also utilise open clip for versioning.
An annexe to this idea would be to have some kind of Autodesk (or Logik) hosted marketplace for Flame freelancers to make them available for projects that may utilise this workflow. Kind of like an Airtasker for Flame Freelancers.
Essentially, Flame would be creating and capitalising on a remote Artist workflow. Flame excels as a one artist system as it is fast and versatile. If Autodesk also had a way of connecting studios with freelancers it would be attractive to those not using Flame already. It would also make Flame attractive to studios wanting to be agile and being able to scale quickly. Not so easy with other tools as there isn’t quite the same range of freelance talent available on short term contract with their own systems.
Shot and Artist management would likely still need some kind of 3rd party tool, but a simple ‘batch’ status could potentially be all that would be required.
I think the above covers the bigger picture. Once again, yes you can do this sort of thing in the cloud but there is expense, expertise and hassle needed to achieve this whilst I believe there could be a very simple way of doing this from a locally hosted Flame server. Simplicity of remote artist workflows and having a ready made database of remote Flame Artists could and would be a major selling point. And there is a strong possibility that it would attract new Artists too. It is as close as you could get to having artists based at your own facility but without the expense of the infrastructure to make it happen. Or the cost of putting in hardware for Freelancers to remote into that may not get used regularly enough to justify the expense. Or the hassle of setting up freelancers to remote in via Teradici. Or the ease for remote artists to just load up their Flame and work like they always have but connect to a remote database server (no complication of cloud). I think you must get the idea by now.
So here we go…. thoughts?!!