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:
- An artist submits a job from any Client machine (through the QubeGUI, i=
n-application submission, command-line, python, etc)
- 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."
- The Supervisor identifies available Workers to process the job.
- The Supervisor sends the job package to the Worker(s).
- 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.
- 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).
- The artist or anyone else, can view the current status of a job through=
the QubeGUI, command-line, python, etc.
------=_Part_8784_1339639584.1711698931252--