Flame Multiple User Workflow and Sharing Projects_2017 and beyond

[Anonymous]

Greetings Flame Users and Moderators,

Is there someone in this community that can advise on best practice for a facility with multiple Flame Premium stations to share projects?  I am freelancing at a facility where there are 4 fully active stations on Linux.  There is no single location where jobs can be accessed and timelines shared, each station is a stand alone.  This same facility houses many Avid stations and the operators have been using a Unity style environment for many years, meaning the sharing workflow is fairly seamless, by comparison.

The Flame workflow at this facility, if not broken, definitely walking with a limp.

Thx,

Conner Keating

[fred.warren]

Hello Conner,

If all the Flame are on the same network you should be able to all log on the same project by selecting the same "Host Computer" at the Project Management screen when you launch Flame. Each computer will have its own Workspace (Desktop + Libraries) and you will be able to share clips through the Shared Libraries in the Media Panel.

Grant is showing the basics of this workflow here: https://www.youtube.com/watch?v=zM4FhdiGEIY

Please accept this as a solution if you feel it has answered your question.

fred

[Anonymous]

Thank you, Fred, for making this recommendation.  The information is useful and pertains to my inquiry.  However, I am looking for something well beyond sharing bits and pieces of a given job...I am looking for a way to share the entire job among multiple Flame stations.  In other words, a facility wide workflow that gives operators in multiple stations access to the entire job structure, i.e. graphics, audio, timelines, daily revisions to elements within the job. 

In order to use the information provided instructional link, would an operator then use the "Shared" area as a transfer to another Flame station by copying his entire project, libraries, folders, reels and all to shared?  Then the next operator on a different station that wishes to pick up the job from there has to load the entire job from Shared to his local library?  Also, how would one keep track of the latest version of the project among 5 or 6 Flame Premium stations to see who has the latest build or version of the project?

Any ideas or resources to get some assistance will be greatly appreciated.

Conner

[fred.warren · Accepted solution]

Yes, you need to go through the Shared Library if you want all the machines working in the same project. Another solution would be to create individual projects on all the machine and use wire (MediaHub > Projects instead of MediaHub > Files) to access the content.

fred

[Anonymous]

I would say you have answered my question and I will accept as a solution. 

May I ask you another related question to this workflow... if one were to operate out of the Shared environment only, all Flame stations...would you expect a decrease in performance vs. having the entire library local?

Many thanks Fred!

Conner

[-cicero]

Hi Fred

I've been looking into a solution to the same problem.  In our facility we have 4 x Linux systems running 2 x Flames and 2 x Flame Assists.  We regularly need to access a pre-existing project (which was created on Flame system A) on any one of the other three systems (B, C or D), while the original system A is in use on a different project.  We don’t want to migrate projects because we may need them back in the main suite A later.  We don't need to be accessing the same project on multiple systems simultaneously.

I found this old thread and re-watched Grant's old tutorial covering Shared Libraries, but this won't do it for us.  The only way I can see is to access the project which resides on Flame A, using Flame B (or C or D) and choosing Flame A as Host Computer on startup.  This seems to work but I have some queries before we use it in anger:

1     Is there a performance hit on either system, especially on system A, which hosts the project but is now busy and client-attended on another job?

2     If plugins (Sapphire, Neat Video) have been used originally on system A, but are not installed on system B, how will they behave?

3     If system B or C or D is a Flame Assist, it is obviously missing some of the full Flame toolset. Will it still interpret all pre-built FX stacks etc correctly?

4     Which system is actually creating any new renders, and to which storage do these render caches go?

5     Any other gotchas/pitfalls? Is this just a really bad idea? If it is a solution, not sure why it's not more publicised, given that this seems to be a fairly common issue in larger facilities.

6     Is it possible that a proper shared project solution with projects residing on a common server (like Baselight or Avid use) will be available in the future?

Many thanks!

[Grant.Kay]

Hi -cicero,

The shared libraries which I covered back in the the video is one solution for sharing projects.   But as you clearly pointed out, This does involve moving and replicating data in different projects on different workstations.   Considering your requirements, this may not be the solution for you.

Logging into the host computer (in your case, Machine A) keeps everything on the same workstation and within the same project.

It is a viable workflow but it is not a centralised projection solution.  There are multiple points of failure such as Machine A goes down ( like rebooting or crashing) and network failure which need to be considered.  Please bear this in mind as I answer your questions.

1     Is there a performance hit on either system, especially on system A, which hosts the project but is now busy and client-attended on another job?

The performance is actually affected in two ways.  Firstly, if Machine A is busy, there will be a "tug of war" for machine resources which may impact on performance.  Secondly, the performance is also determined by the network connection.  Depending on the network bandwidth as well as how busy the network becomes may cause a slow down.  

2     If plugins (Sapphire, Neat Video) have been used originally on system A, but are not installed on system B, how will they behave?

I do believe the plug-ins will come up as unavailable if not installed (results in a blank frame) or if they are installed but not licensed, you will get watermark.   As soon as you launch the project on Machine A again, the plug-ins will work.   My suggestion is to install the plug-ins on all the machines, even if not licensed, and you will at least be able to see a result with the watermark.

3     If system B or C or D is a Flame Assist, it is obviously missing some of the full Flame toolset. Will it still interpret all pre-built FX stacks etc correctly?

Yes, everything should interpret correctly and look the same.  The only difference is that some controls will be greyed on the Flame Assist but still it will still function as expected.   When returning to Machine A, everything will be editable again.

4     Which system is actually creating any new renders, and to which storage do these render caches go?

As far as I was aware, all the processing takes place on the machine you are using.   So the workflow would be to pull frames from Machine A, render on Machine B and the final frames are pushed back to the Machine A storage.    This is the reason why I mentioned that the network will/can get very congested.

5     Any other gotchas/pitfalls? Is this just a really bad idea? If it is a solution, not sure why it's not more publicised, given that this seems to be a fairly common issue in larger facilities.

I don't think this is a bad idea but it is not a permanent or perfect solution for centralised project management.    I would use it to make changes to a sequence or a composite and perform some updates.   This is good for jumping into a project and doing some work for a few hours or so.   This is not something I would recommend doing for an entire project.     Just remember to save often to avoid data loss if there are any points of failure.

The other fact to keep in mind, is that when you log into a project on another machine, it is possible for each machine to have its own workspace within the project.   This is chosen at the Flame start up screen after choosing the host computer and the project.  This enables people to work on a part of the project without fear of disrupting the original data.   The only danger is if the artist did not understand the concept of the workspace, they would sometimes think that their work was lost when it was just within a different workspace within the project.  There is nothing to stop you logging into the project's original workspace but I would ensure that any Flame artist using this workflow has a very clear understanding of how workspaces work within the Flame context.

6     Is it possible that a proper shared project solution with projects residing on a common server (like Baselight or Avid use) will be available in the future?

Please would you go to the Autodesk Flame Feedback Portal and log this as a feature request?   
https://feedback.autodesk.com/key/flame
This makes it visible to the DEV team and then it can be discussed within the team.

Please hit the Accept as Solution button if my post fully solves your issue or answers your question.

Regards

Grant

[-cicero]

Hi Grant

This is all really useful info.  Thanks for taking the time to explain it thoroughly.  It's pretty much what I thought was going on, but great to have it clarified.  I'll also log the feature request as you mention.

Thanks again