Author Topic: Issues with XSI 6.5 and Qube  (Read 10399 times)

Arvid

  • Jr. Member
  • **
  • Posts: 2
Issues with XSI 6.5 and Qube
« on: March 13, 2008, 04:57:03 PM »
Hello, I'm currently evaluating Qube for our facility, and I have a couple of questions.

- First of all, I had some problems getting the XSI jobtype to install. I'm guessing changes have been made to XSI in version 6.5 which breaks the current code. I found a problem in xsisubmit.js which may be the reason for it. Since render options have drastically changed since 6.x, some objects are renamed. Passes now inherit options from the main render settings instead of having one per pass, but changing line 62 to something like this seems to work:

   oPSet_new.ImageFramePadding = Application.GetValue("Passes.RenderOptions.FramePadding");

There were other problems, like the returned frame padding number doesn't mean the same thing anymore so the fields in the Qube dialog in XSI isn't always filled with the correct values from the scene. I changed line 62 manually on all nodes, and it's rendering now.

- The frames I got from my first successful render with the xsi jobtype returns a slightly scrambled sequence, the frame numbers isn't correct in some of the frames, which makes the animation jump back and forth when played back, any idea what causes that?

- I was trying to use Qube to install the jobtype through a command line job with the /passive switch, but since there's no UNC path support in CMD I couldn't do it, is there a way around that? I tried using pushd and even a mounted Z: drive but couldn't get it to work.

- I'm also wondering how you set up groups of computers and what the difference is between groups and clusters? I found the manuals somewhat confusing there, and couldn't locate the qbwrk.conf file anywhere, or where to create it.

- Lastly I would like to know how to use both CPUs of a node for one frame, often it's more efficient to render one frame per computer instead of per CPU, especially memory-wise, currently there are two xsibatch processes running simultaneously, doubling the memory usage.

Thank you,
Arvid
Stockholm Post Production
« Last Edit: March 13, 2008, 05:04:01 PM by Arvid »

jason.fowler

  • Guest
Re: Issues with XSI 6.5 and Qube
« Reply #1 on: March 14, 2008, 05:25:57 AM »
Hi Arvid,

- First of all, I had some problems getting the XSI jobtype to install. I'm guessing changes have been made to XSI in version 6.5 which breaks the current code. I found a problem in xsisubmit.js which may be the reason for it. Since render options have drastically changed since 6.x, some objects are renamed. Passes now inherit options from the main render settings instead of having one per pass, but changing line 62 to something like this seems to work:

   oPSet_new.ImageFramePadding = Application.GetValue("Passes.RenderOptions.FramePadding");

There were other problems, like the returned frame padding number doesn't mean the same thing anymore so the fields in the Qube dialog in XSI isn't always filled with the correct values from the scene. I changed line 62 manually on all nodes, and it's rendering now.

- The frames I got from my first successful render with the xsi jobtype returns a slightly scrambled sequence, the frame numbers isn't correct in some of the frames, which makes the animation jump back and forth when played back, any idea what causes that?

Sorry, the current XSI jobtype only supports up to XSI 5.x.  XSI 6.x support will be available with our next Qube! release, 5.3, planned for release this month.

- I was trying to use Qube to install the jobtype through a command line job with the /passive switch, but since there's no UNC path support in CMD I couldn't do it, is there a way around that? I tried using pushd and even a mounted Z: drive but couldn't get it to work.

Are you trying to install it via a Qube! job?  If so, you must make sure that the job's execution account (qubeproxy, by default) has access to mount and read from the Z: drive, and also that the execution account has admin privileges.

You can find more about proxy mode and the qubeproxy user in the Installation pdf, on page 71, in the "Post-Installation" section.

- I'm also wondering how you set up groups of computers and what the difference is between groups and clusters? I found the manuals somewhat confusing there, and couldn't locate the qbwrk.conf file anywhere, or where to create it.

You can set up groups by editing the qb.conf file of each individual host (can be done through the configuration GUI) or by using the qbwrk.conf file to assign groups en masse.  The qbwrk.conf file lives on the supervisor in the SYSTEMROOT directory (usually C:\WINDOWS), and the administration pdf should give examples of how to set up a qbwrk.conf file.  As far as groups vs. clusters go, groups are just a simple way to gather a number of hosts so you do not have to type in the name of each individual host at submission time.  A host can belong to multiple groups.  On the other hand, a host can belong to only one cluster, and each cluster is a pool of workers to which priority is given when executing a job.  If a job cannot run on any of the hosts in the cluster (e.g. they are all busy), it can bleed into other clusters, but it will have a lower priority.  More on groups and clusters can be found in the administration pdf.

Additionally, our Qube! Knowledge Base is an excellent source of information.  Info on groups, clusters, and the qbwrk.conf file can be found in this section:

http://support.pipelinefx.com/wiki/index.php/Qube_Knowledge_Base#Configuration


- Lastly I would like to know how to use both CPUs of a node for one frame, often it's more efficient to render one frame per computer instead of per CPU, especially memory-wise, currently there are two xsibatch processes running simultaneously, doubling the memory usage.

In order to control the number of concurrent instances of a program running on a host, you can either specify memory reservations at submission time or adjust the number of job slots a host has.  By default, Qube! says that each host has a number of job slots equal to the number of cpus detected.  By reducing the number of job slots, you will reduce the number of instances that can run concurrently.

Again, I would recommend looking at our Qube! Knowledge Base, specifically this section:

http://support.pipelinefx.com/wiki/index.php/Qube_Knowledge_Base#How_to_limit_the_number_of_renders_on_a_host


I hope this helps!

-Jason
PipelineFX

Arvid

  • Jr. Member
  • **
  • Posts: 2
Re: Issues with XSI 6.5 and Qube
« Reply #2 on: March 14, 2008, 06:16:08 PM »
Thank you, I'll check it out. I had assumed before we installed Qube that you could set up groups and scheduling inside the GUI. I saw something like that in your online demo, but that was beta.

I did find another problem, the rendered sequence I got was slightly scrambled, but that may have to do with the XSI support too, I suppose?