Message-ID: <1103933140.8785.1711698931252.JavaMail.confluence@host3.pipelinefx.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_8784_1339639584.1711698931252" ------=_Part_8784_1339639584.1711698931252 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html Can you give an overview of Qube's architecture from a workf= low standpoint?

Can you give an overview of Qube's architecture from a workflow= standpoint?

Yes, here is a sample workflow that showcases Qube's main compon= ents:

  1. An artist submits a job from any Client machine (through the QubeGUI, i= n-application submission, command-line, python, etc)

  2. This creates a package of information (strings, numbers, etc), that is = sent to the Supervisor and stored in the database.  That package is ca= lled a "job."

  3. The Supervisor identifies available Workers to process the job.
  4. The Supervisor sends the job package to the Worker(s).

  5. The Worker service then launches the respective backend (script or exec= utable) that reads the job package and launches the appropriate command lin= e or executable for the rendering.

  6. The application (e.g. Maya) then reads in the scene (stored in a centra= l location) and then renders the resulting frames to a central location (li= ke a NAS or other file server). 

  7. The artist or anyone else, can view the current status of a job through= the QubeGUI, command-line, python, etc.
------=_Part_8784_1339639584.1711698931252--