Very - Qube! has been used in production continuously since 1999. While we continue to extend the capabilities of the system, stability is our primary concern. Also Qube! is backed by a MySQL database that provides the scalablity, reliability and the recoverability of an enterprise database.

Qube! is extremely flexible – it has APIs (Application Programming Interfaces) in Perl, Python, and C++; you can create your own clients for submitting or monitoring jobs, create custom Job Types, or create reusable templates for linking job dependencies. In addition, the queuing algorithm itself is modular, and can be replaced with your own custom algorithm. All of our clients and Job Types are built with the same APIs – no other system provides that level of power and flexibility.

Qube! has been used in production environments of up to 2000 machines, and tested using tens of thousands of ‘virtual’ machines, using a single Supervisor node. Some of the world's largest render farms  in prodcution today are running Qube! on thousands of CPU cores.

 Simply put, Qube! can run any program that you can run on your computer. We also provide custom integration (which we call a "job type") interfaces that allow artists to submit jobs directly from within their applications. See the "Job Types" page for a complete and updated list.

A Job Type uses the Qube! API to link a job submission frontend interface with a backend execution module. Because the Job Type uses the API, we are able to create submission interfaces to run natively within a variety of applications. Likewise, our execution modules are tightly coupled with the application, often down to the frame level, making them extremely efficient and flexible.

 Rendering a single frame or image across more than one server to decrease the render time for large, high-resolution images is known as "satellite rendering." When rendering with Maya Unlimited and mental ray for Maya Satellite, the Qube! Maya JobType allows you to dispatch a single frame to as many as 8 additional networked cpus. This workflow can decrease render time required of a large image significantly. When rendering with 3ds Max DBR, a single frame can also be rendered across up to 8 networked CPUs.

Updated platform support is HERE.

Our Job Types combine the Qube! APIs with the leading animation software to produce the tightest integration in the industry. This high level of integration gives artists the most natural interface for submitting jobs, and gives engineering the most efficient execution environment for running jobs. Qube!'s SimpleCMD interface also allows quick and easy integration with any application that can execute a command line.

Absolutely. Windows, Linmux and OSX are fully supported. Every component of the system can communicate with every other component, regardless of the OS it's running on. You can have any combination of Windows, Linux and OSX for the Supervisor and Workers.

Any machine can be added to the farm; you're free to install the Worker software on any machine in your facility since our licenses are floating. High-performance desktop workstations can be locked out of the farm while artists are working on them during weekdays, but can be made available during evenings and weekends.

You have three options available to take advantage of Qube!'s powerful callback system for dependency. You can use the Job Grapher tool in the Qubic interface, link submitted jobs with the command line tool qbsub, or create your own dependency callbacks with the Qube! API. The numeric priority system in Qube! supports any priority between 1 and 9999, where 1 is the highest possible priority.

It depends on the number of Workers and other clients you'll be running. The Supervisor is quite efficient, though generally speaking, increasing the RAM in a machine will improve performance more than a faster CPU. A single Supervisor will be sufficient for over a thousand clients. A typical Supervisor servicing 500 multi-core Workers might be a dual-CPU quad core machine with 16GB of RAM and striped local disk for the database. Contact support@pipelinefx.com for more information.

Yes, but this is not recommended. While the Supervisor itself does not put a heavy load on the machine, a job being run by the Worker may do so, and that load may compromise the performance of the Supervisor.

Yes, the Supervisor is designed with a plug-in architecture to allow you to insert your own queuing algorithm. While the Supervisor’s queuing algorithm is designed for maximum throughput and efficiency, and can be tuned according to several different criteria, it’s possible to insert an alternative (e.g. a simple FIFO, non-prioritized priority, or a sophisticated algorithm based on studio-specific meta data or other criteria). See the Development documentation, or contact support@pipelinefx.com for more information.

Jobs may be preempted as a matter of course, according to their priority. If there are no available machines, a waiting job may preempt a job of lower priority. The system can be configured to preempt jobs immediately, or after completing the current piece of work (e.g. frame). Some types of jobs (e.g. long dynamic simulations) can be flagged as "non-preemptable," in which case the Supervisor will select a different job to preempt. A job can also be preempted – that is, made to release the host it’s running on – manually, using the "qbpreempt" command, or the Qube! GUI, or via the API. Refer to the documentation, or contact support@pipelinefx.com for more information.

Before dispatching a job that requires a licensed application, Qube! can query the application's license server (e.g. FlexLM) to ensure a license is available. (Other systems either dispatch the job regardless – in which case, if no license is available, the job will fail - and, if resubmitted, will go to the end of the queue – or they require you to "wrap" desktop invocations of the application, to keep their system informed of licenses used on the desktop, which is error-prone and inaccurate). You can also reserve a fixed number of application license for desktop use, so a full farm doesn't mean artists are sitting idle at their desktops.

Killing jobs is easy – through the command line tool (qbkill), the Qube! GUI, or the API. Users can only kill (or preempt) their own jobs. Qube! administrators can control any job in the system.

The Supervisor is backed up by a journalled MySQL database. When the machine comes back up, it will automatically restore the latest recorded configuration, and query the Workers for updates that occurred while it was down.

If the Worker goes down, any subjobs running on that machine are automatically marked as unfinished and reassigned to other machines.

Qube! supports a patent-pending system of "permeable clusters," whereby machines can be assigned in a hierarchy to particular departments or productions. Jobs submitted to those groups or productions will have preferential access to those machines, but if jobs assigned to a different cluster are waiting, they will take advantage of any free machines in other clusters. In this way, maximum utilization of resources is achieved, while ensuring preferential access (and a guaranteed minimum number of machines) to each department or production. In addition, these clusters can be dynamically reconfigured without restarting the Supervisor or Workers.

No.  The Qube! GUI is free for all users, but every operation in the GUI is alternately available in the command line tools, or the API.

Qube! is licensed per host on standard servers and desktops with up to 8 CPU cores. Qube! is licensed per CPU sockets on Intel® Itanium® 2-based machines regardless of the number of CPU cores.  Each Supervisor, generally one per studio, requires a license and a dedicated host.  These licenses are always floating – not locked to any particular node and not locked to any OS – so you can direct work to any machine in the farm, without dedicating a license to that machine.

A good rule of thumb is to buy one license for each machine that you want to do work. If you want to extend the peak capacity of your farm (to include desktops, for example), you can quickly rent or buy more licenses.

Yes you can and you can do so online here.

PipelineFX offers an extensive online support forum, email and phone support, documentation, examples, and tutorials. Under support, all major and minor releases of the software are included.

PipelineFX offers in-person training on-site or at our facility in Honolulu, Hawaii. We can also provide training via conference call and web demo session. Contact sales@pipelinefx.com for more information.

Yes. PipelineFX offers consulting on-site or at our facility in Honolulu, Hawaii. Our consultants are extremely experienced pipeline render engineers who have delivered films, games and TV shows as a part of world-class studios. Contact sales@pipelinefx.com for more information.

Request a demo here.

The Supervisor (one per site) is $600 with $120 per year for support (which includes all software updates plus technical support).

The Workers (one per host doing rendering) is $300 with $60 per year for support.

Support is REQUIRED for the first year and must be purchased on the intial order.

All prices are in U.S. dollars.

Supervisor, Worker and Client requirements are HERE.

Yes. We hold QCA (Qube! Certified Administrator) certification classes monthly. The classes are held in Hawaii and various major cities around the world. QCA classes cover installation, configuration, troubleshooting and best practices for render management. Private classes can also be purchased for your company with a minimum of 3 participants.  Contact sales@pipelinefx.com to check the current training schedule and find a class near you.