maya batch net rendering requests

[flamedevil]

oH YEAH !
Sorry i couldn't answer to you jdates but i 'm interested too by the subject .
I have 2 computers in my home and i really would install a network renderer to render more speedly and learn network render because it's very interesting .

You can read Maya docs., a little part talk about it .

[flamedevil]

Look at this :

http://www.vvertex.com

A software to manage rendering ...

[rollmops]

Check that!

This guy makes so good and user-friendly mel scripts that you have to pay for the new ones.
Don't worry the free version is efficient anyway.

http://dirk-bialluch.mayaring.com/mel/html/frameBooster.shtml:wip: :wip:

[enforcer2k]

Muster looks good, especially the bit about frame slicing, will give it a go :)

[enforcer2k]

Muster feature list
-------------------------------------------------


Muster Explorer
--------------------------------------------

This is the front-end to users. With Muster Explorer you can manage every aspect of Muster, either if it's installed on your local machine or on another server, even using Internet.

Submission of single frame jobs splitted on several cpus
Dynamic connection and disconnection of render clients
Unlimited clients and jobs
Controls all the Render Globals parameters directly into Muster
Tracks individual scene's packets and requeue them on connection drop
Individual frames packet can be monitored and requeued
Custom network ports support
Detailed log on Dispatcher activity
Send log via E-Mail for off-site monitoring
Delete/Reinit/Pause a queued job
Kill/Pause/Reinit and process priority(only NT) on a render client
Very detailed packet's resume with starting time, ending time, elapsed time and renderer name for very precise monitoring
Very detailed job's resume with starting time, ending time, progress, the name of the submitter, total clients working on
Custom scene name to allow users to send the same scene multiple times with different parameters and to keep track on it
Sorting features in jobs and cpu lists
Users can limit the number of workstations allowed to work on a single job
Integrated User Managing feature. Limit the rights to the users of your Domain or choose your trusted Administrator
Very detailed scene status resume with Fault detection and reporting
Unix substituitions path tool to enable cross-platform rendering




Muster Render Client Service and Manager
----------------------------------------

Muster render client is the module that must be loaded on every machine that has to be part of the render farm. It's an NT Service that can be configured using the Render Client Manager. In version 2.52 it supports Maya, Maya Cloth, Imgcvt, Lightwave, Softimage|XSI, Softimage|3D, Mental Ray, Mental Ray for Maya and Custom Jobs.

Dynamic connection and disconnection from Dispatcher Service
Process priority setting(only NT)
Save log of every individual packet
Time Scheduling
Take advantage on multi-processor machine settings the number of processors working on a job(only Maya) or starting multiple instances of it.




Muster Unix Render Client Modules
------------------------------------

BSD based executables for Mac OS X , Linux and Irix. Join your Unix machines on the Renderfarm. This service has the same features of the NT render client.

[ME3D]

Hey Jeffrey,
I agree with what you said. There arent many of us around willing to speak of net rendering. I think mostly due to the larger studios having "techs" doing this portion of the work where mid sized studios who can afford a farm cant afford an extra person just to take care of it. Thus here we come and we must READ. lol

To the point:
I chose Smedge after trying all the renderer i could get my hands on. Such as render max, Spider, and Lemon.

I use Maya>Smedge regularly, so what type of probs are you having in stability?

[Tob]

We've been using Smedge for quite some time now, and it works like a charm. The only feature that I miss is a more effective way to assign CPU's to individual jobs (pools will only take you so far...)

[jdates]

Oh bless you guys,

I'm using smedge and I'm in utter hell!

I've gotten our network setup like so:
we have a beefy RenderServer running 2 gigabit NIC's.
We have 40 Boxx RenderMachines all running with a gigabit Nic!
The entire farm is on it's own Switch off the main network.

Now I've talked with Robin (smedge writer) and he recommends starting a smedge server. Did that.

He also recommends having each client launch smedge from the same .exe as the server. Did that.

My problem is that my server smedge keeps dying, and that hoses the entire network. THe GUI locks up and I'm unable to add-remove jobs. Can't super-exit, cant anything! I have to reboot the farm.

With no command line exit commands for smedge it's a pain in the arse.

Questions:

How have you guys set up your smedge network!?
How are you controlling your clients?

Give me some tips and hints to stabilize this blasted smedge network. It's killing me!!

Jdates

[Tob]

jdates:

Our setup is simplicity itself. Never tried running it from a server; never feelt the need to.
Each renderstation in the farm has smedge in its startup folder. The farm has its own switch and internal network. When a station does its windows-thing and crashes, smedge simply relaunches after reboot and joins the crowd again.
The only dissadvantage with this is that you have to keep an eye on the CPUs from your workstation to see if anyone's missing and if that is the case reboot the renderstation in question. Since the package is rerouted to another CPU, there's no real harm done (and you get a nice bonus exercise running down to the farm when you have to reboot) :p
The big plus, of course, is that only one station goes down.

Not the fanciest of solutions, but it works.

[jdates]

Tob,

When you submit jobs to the farm, do you set network projects? Or local projects?

I've found it's much more stable and happier if I create an empty directory on each slave, and default Smedge's project there. Then just render to the network drive.

So you hadn't had any stability issues or anything?

How are you controlling your windows machines remotly?
How are you controlling smedge remotely... Or do you?
Have you any nuggets of knowledge for me as I embark on this, my windows :thumbsdow smedge farm.

Jus curious.:shrug:

Jdates:thumbsdow

[kfc]

guys. i'm very interested in testing network rendering features in maya too.
well.... i've been trying a couple of external software/plugin from highend3d. most of the need to pay. not long ago i've heard from a technician that we can do network renderings in a unix without using any plugins. maya on unix already has a "dispatcher" installed and we can assign jobs thru it anytime to every machines in the network. however, we've 8 units of O2 (old SGI) here and no one in my college actually know how to use this features. i'm going to test this out with the help on an external technician. i'll report anything that i can find out from this.
:)

anyway, i'm still not sure whether we can include NT based maya in to the network rendering farm with dispatcher of unix.

[Tob]

We use local projects. Here's what we do:
Each work station has a unique project drive that is mounted as a network drive on all the other computers (as D,E.F,G, etc etc) as well as on all the stations in farm. That way, if the scene path is, say: H/project/scenes/Ramloose.mb, you can still render it from what ever station you're workin on.
We also use a dedicated drive for all textures.

The only stability issues is with Windows; we're seriously thinking of switching to Linux (though, I must say that the Xserve looks mighty cool... :) )

No remote control. As soon as a CPU is shown as missing we reboot the station manually.
We "control" smedge from each local smedge window, if by control you meen tossing packages at it... :p Not quite sure what you mean...

Hope this helps

kfc: We tried the IRIX dispatcher a couple 'a years ago, but as far as I can remember we never got serious with it (my UNIX skills were almost nonexisting)
I'm sure You could get an evaluation license for a month or so from any of the softwares you've been looking at. That's how we decided on Smedge.

[jdates]

>The only stability issues is with Windows; we're seriously >thinking of switching to Linux (though, I must say that the >Xserve looks mighty cool... )

I'm not familiar with Xserve, but we are seriously looking into Linux. We're setting up a Linux server, and turning a couple of the slaves over to Linux to do a case study on performance.
We'll see. My hope is that all the stability issues go away.


>No remote control. As soon as a CPU is shown as missing we >reboot the station manually.
>We "control" smedge from each local smedge window, if by >control you meen tossing packages at it... Not quite sure what >you mean...

We have several remote control features. We have a "Remote Task Manager" that allows me to log into a slave, and check any process, network load, or anything you can normally do with a Windows task Manager.
Another step of control is a Remote Desktop Controller. Currently, I've used VNC, Epop, and Terminal Services. All with about the same amount of luck.

Finally, we've written some batch scripts that allow us to do things like "reboot farm" or "kill smedge" and we can either do this globally, or per individual machine.

Rebooting the machine I guess is a clean easy solution...
with the batch scripts it just a simple command prompt.

I guess I just hate the windows instability.
I run into two main issues that I haven't been able to reconcile.

1) Without a dedicated smedge server, Smedge often gets confused and assigns multiple servers to host the farm. So what happens is that you get only some machines showing up on some Host lists... Mainly a division of your render slaves that is undesired.

2) With a dedicated smedge server, I run into a wierd thing that if for some reason (more often than not), the slave who is acting as a server goes down, the entire farm is hosed.

Why the heck is my smedge even crashing!? That's what I want to know and have been unable to track it down.


>kfc: We tried the IRIX dispatcher a couple 'a years ago, but as >far as I can remember we never got serious with it (my UNIX >skills were almost nonexisting)
>I'm sure You could get an evaluation license for a month or so >from any of the softwares you've been looking at. That's how >we decided on Smedge.

Yeah, I've been reading up on this. I haven't found anyone who has used it as of late. I'm curious.. will it run on Linux with the Linux version of Maya!?

Eh, rendering is for the birds.
Jdates

:D

[alexx]

a worrd about muster:

we used it in version 1.0 and 2.0 on a 18 dual machines renderfarm, that got all the local computers in the night as well, bringing it up to about 40-60 computers rendering.

muster has/had a lot of stability issues in the past.
since version 2.0 the handling improved a lot and since 2.5 it got really nice i would say.
the latest version is 2.52, which i was not really able testing, but it has some nice bug fixes.

additionally muster is one of the rare tools, that accepts command line parameters (so you can write your own scripts in maya to call it e.g.) which is very nice.

i think muster is definitely worth a closer look. especially since it is quite cheap compared to other solutions like spider..

cheers

alexx

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.