Author Topic: Maya Hardware 2.0 on Windows 7  (Read 3435 times)


  • Jr. Member
  • **
  • Posts: 3
Maya Hardware 2.0 on Windows 7
« on: October 05, 2012, 09:36:48 PM »
I'm attempting to render a scene out using mayaHardware2 on Windows.

I created a basic cmd file for testing which simply calls Render.exe with a path to the scene file. If I run this command file locally in a command prompt, the scene renders fine and files come out the other side.

I then create a cmdline job passing it the cmd file I ran previously and the scene no longer renders.

The message I get is:
ogsRender  -layer defaultRenderLayer  ;
Warning: Renderer returned an error while rendering 'defaultRenderLayer', please verify the output image.
INFO: execution successful.

The problem is, no files are written.

When I run it locally I get:

ogsRender  -layer defaultRenderLayer  ;
Initialized VP2.0 renderer {
  Version : Feature Level 4.
  Device : NVIDIA Quadro FX 5800
  Driver : nvoglv64.dll:
  API : OpenGL V.2
  Max texture size : 8192 * 8192.
  Max tex coords : 8
  Shader versions supported (Vertex: 4, Geometry: 4, Pixel 4).
  CPU Memory Limit: 15562.6 MB.
Rendering frame 1 : ........etc

I am guessing it has something to do with the proxy user getting control of the video card? Just wondering if there is something I am missing and/or if this is even possible.



  • Administrator
  • *****
  • Posts: 493
Re: Maya Hardware 2.0 on Windows 7
« Reply #1 on: October 08, 2012, 08:10:57 PM »
What's happening here is that the worker is running as a service, but is trying to access the screen-space (the user's desktop environment).

If no one's logged in, there's no screen-space.  If someone is logged in, OS-level security policies prevent the service from accessing a logged-in user's screen space.

Qube! has a way to handle this; you can run the worker as a user process started by a logged-in user, and not a service.  This way, the user process is already running in the user's screen space, so all jobs that run can access the screen space.

We refer to this as "Desktop User" mode.

Here are instructions to switch your worker from a service to Desktop User mode:

First, disable the worker service while logged in as an admin-equivalent with QubeGUI->Admin->Worker->Stop and Admin->Autostart Worker->Disable.  Verify that the Admin menu items have updated to show the worker as stopped and will not autostart.

Then log in as the user who will run the worker process, the existing proxy user will serve (qubeproxy's password is Pip3lin3P@$$wd).  Start the worker as the desktop user with QubeGUI->Admin->Worker->Start as the Desktop User.  Set it to auto-start when this user logs in with Admin->Autostart Worker->Enable Desktop Worker (on user login).  This should create a "DesktopWorker" shortcut in Start-Programs-><user>->Startup.

DW worker mode on Win7 also requires that all jobs have the "disable_windows_job_object" flag set, otherwise the proxy.exe process may crash when a job is started on the worker.  On the supervisor, add this flag to the "supervisor_job_flags" to enable this on a global scale.  The easiest way to do this is with QubeGUI->Admin->Configure.  Symptoms of a crashed proxy process is the worker is shown as running the job, but the job never actually gets marked as 'running'.