Greetings,
I've recently setup indigo to run on a all linux render farm
(10 node dedicated cluster), and have run into a great deal
of trouble from a couple of features.
I prefer to run each node from the command line only, without
loading Xwindows (faster boot times and smaller memory
footprint) but even when indigo is run as a slave from the
command line it still creates a graphic window. It would be
great if in slave mode it only output to the console.
Second, if theres an error it uses a popup dialog box that
needs user input before program will terminate making
scripting difficult (console output of error with exit code would
make scripting MUCH easier).
And lastly, if master is not available slave will exit instead of
staying active and retrying, making the slave behave less
like a deamon. I managed to get indigo working by using a
full windows environment and monitoring output, killing the
app when theres an error and restarting automatically. Since
indigo has such great support for networking it would be
great if it had cleaner support for commandline environments
and scripting.
Considering the long render times and good networking
features I think renderfarms and linux could be common
with some users or studios. Anyway love this renderer and sorry for the
long post!!
Thanks for listening!
Render Farm Feature Requests
- WHiTeRaBBiT
- Posts: 10
- Joined: Sun Oct 29, 2006 8:27 pm
- Location: Georgia, USA
- Contact:
Render Farm Feature Requests
"For death awaits you all with nasty, big, pointy teeth."
Monty Python and the Holy Grail
Monty Python and the Holy Grail
- WHiTeRaBBiT
- Posts: 10
- Joined: Sun Oct 29, 2006 8:27 pm
- Location: Georgia, USA
- Contact:
WOW fast reponse!
Thanks for the advice.
How would that handle the dialog box output on error?
Would I still need to capture errors and manually kill the app?
I know diverting the output from all ten nodes is not an option
(they would all be complaining at once when the master stopped!
then when they are killed and restarted they will complain
again and so on...).
Not trying too be pushy but I think these changes would not be
too difficult to implement (just interface cosmetics) and would greatly
simplify indigos use in scripted environments and render farms.
Just think its worth considering.
Thanks again.
Thanks for the advice.
How would that handle the dialog box output on error?
Would I still need to capture errors and manually kill the app?
I know diverting the output from all ten nodes is not an option
(they would all be complaining at once when the master stopped!
then when they are killed and restarted they will complain
again and so on...).
Not trying too be pushy but I think these changes would not be
too difficult to implement (just interface cosmetics) and would greatly
simplify indigos use in scripted environments and render farms.
Just think its worth considering.
Thanks again.
"For death awaits you all with nasty, big, pointy teeth."
Monty Python and the Holy Grail
Monty Python and the Holy Grail
Hi WhiteRabbit,
Your requests are very reasonable and are a good idea
I could make a 'console' mode, which could be set either in the inifile or on the command line. In this mode, no windows would be created (so no text output window or graphical render display window), all messages would be sent to standard output as well as to the logfile, and i wouldn't pop any dialogs. Sound good?
Your requests are very reasonable and are a good idea
I could make a 'console' mode, which could be set either in the inifile or on the command line. In this mode, no windows would be created (so no text output window or graphical render display window), all messages would be sent to standard output as well as to the logfile, and i wouldn't pop any dialogs. Sound good?
- WHiTeRaBBiT
- Posts: 10
- Joined: Sun Oct 29, 2006 8:27 pm
- Location: Georgia, USA
- Contact:
!!!!That would be wonderfull!!!!
Also no critical error on no master or tcp/ip connection (maybe another ini option?) would allow slave to run in background
as a daemon. Because I'm running a cluster on rack with only
one shared monitor and keyboard I depend completely on
script automation to make it all work. Again just food for thought.
About how long do you think these features would be implimented?
I was considering re-engineering the farm but will wait if this
will happen in a future release. No pressure just curious!
Thanks again.
Also no critical error on no master or tcp/ip connection (maybe another ini option?) would allow slave to run in background
as a daemon. Because I'm running a cluster on rack with only
one shared monitor and keyboard I depend completely on
script automation to make it all work. Again just food for thought.
About how long do you think these features would be implimented?
I was considering re-engineering the farm but will wait if this
will happen in a future release. No pressure just curious!
Thanks again.
"For death awaits you all with nasty, big, pointy teeth."
Monty Python and the Holy Grail
Monty Python and the Holy Grail
The problem with making the slave a daemon is that each slave is basically a 'one-shot' process: it loads the scene, it connects to the master, and then renders. Currently there's no way that it can, say, be disconnected, then reconnect, render a different scene etc... Basically it's not designed to be a fully fledged daemon process.
You may have to script that daemon process yourself
having said that tho, it would be cool to have some kind of render slave daemon thingey in the main distribution, so that it becomes very easy to start network jobs.
As far as timespan for implementation of the console version goes...
Well it's pretty easy (cross-fingers), so I could do it sometime this week, after v0.6 is out
You may have to script that daemon process yourself
having said that tho, it would be cool to have some kind of render slave daemon thingey in the main distribution, so that it becomes very easy to start network jobs.
As far as timespan for implementation of the console version goes...
Well it's pretty easy (cross-fingers), so I could do it sometime this week, after v0.6 is out
- WHiTeRaBBiT
- Posts: 10
- Joined: Sun Oct 29, 2006 8:27 pm
- Location: Georgia, USA
- Contact:
That would be fine!
As long as the it errors cleanly back to console with error codes
or log its not a big deal to script in a loop.
Just want to say I'm very impressed with the quick response
and openness to ideas!
Love this renderer and think its got a BIG future!!!
Thanks for all the fish!
BTW in case anyone is wondering:
Running a 10 node cluster (2ghz 512meg each)
Master 3.4ghz hyperthread 4gig
Master and cluster on 2.6.18 linux kernels under Debian
was runnig windows->3dsmax->mentalray
currently experimenting with debian->blender->indigo
As long as the it errors cleanly back to console with error codes
or log its not a big deal to script in a loop.
Just want to say I'm very impressed with the quick response
and openness to ideas!
Love this renderer and think its got a BIG future!!!
Thanks for all the fish!
BTW in case anyone is wondering:
Running a 10 node cluster (2ghz 512meg each)
Master 3.4ghz hyperthread 4gig
Master and cluster on 2.6.18 linux kernels under Debian
was runnig windows->3dsmax->mentalray
currently experimenting with debian->blender->indigo
"For death awaits you all with nasty, big, pointy teeth."
Monty Python and the Holy Grail
Monty Python and the Holy Grail
Who is online
Users browsing this forum: No registered users and 26 guests

