Future Thinking: Flame as the hub of a remote Flame artist pipeline

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?!!


You would trust MegaCorp to do that for you?

1 Like

Hi Adam,

Wow, this looks like a lot of thought was put into this!

If you could spin up and license additional machines in your own ecosystem in a few minutes - how would this differ from a co-located dial-in or a cloud based solution?

I’m already experimenting. Will let you know.


In short, yes I would. More importantly though, I think Studios with strict security policies would be much more comfortable if Autodesk came up with a solution rather than a DIY solution that would need auditing.

1 Like

Are you talking self hosted VMs?

Here’s my thing, working on a locally hosted system is by far the best experience. All the freelancers I know already have their own systems and licenses, so there is no additional cost in what I am suggesting. Plus something built into Flame would be so much easier to put in place for a small studio or even I know of occasions where a few freelancers have pooled together on projects. There are so many Flame Artists out there who struggle to get Rocky Linux installed let alone set up something like what I am discussing.

I think what I am suggesting makes things easy (for the end user, not so much for the dev team) and flexible.

It’s definitely worth thinking through.

But solving the technology is only part of the problem. Especially on self-hosted Flames the security and ability to deal unexpected issues is a major risk. Same for the artists themselves. They will run the gambit in terms of business skills, diligence, etc. Nothing against them in any way, but I think that would make it a huge gamble for big clients to hire a loose network of freelancers with much less process rigidity in place. Of course if they’re out of options or want a big discount, don’t count them out.

That is separate from a number of freelancers collaborating regularly or ad-hoc to take on bigger projects that they can handle individually. Both from a workload / speed perspective, coverage in case something happens, etc. Putting infrastructure in place to help that is worth exploring. The target market here is somewhere in the middle.

Maybe you can have @randy weigh in, I believe he’s been thinking along those lines already.

1 Like

That’s why I suggested having an inbuilt tool where a remote artist cannot export anything from Flame on a connected project. And that the media lives in the local storage encrypted. This sort of setup is already supported and allowed on products such as Cinesync. If you had the same variables, I think it would satisfy the studios and streamers.

1 Like