Hugh Macdonald wrote:
> My thinking here would be that Rush would require some kind of wrapper
> around the application to convert the application's progress reports
> into something that makes more sense to Rush. Pretty much in the same
> way that Alfred does it.
I'm not sure what alfred does, but my approach would probably
be to implement the log parsing in irush.
Possibly irush would need to call the submit script in order
to convert the log output into percentage info that irush
can show, so that the parsing logic can be modified in the
submit script, should it change from version-to-version of
the renderer.
Thing is, managing the realtime logs of potentially tens or
hundreds of files in progress, and piping their data through
such a parser is not trivial technically across all platforms
at the workstation.
It can be done, but there's a lot of bending over backwards
to accumulate this info, and it would add a bit of traffic
to the machine doing the accumulation.
The other route would be to have the remote rush daemons
parse the logs for just the processors they're working on,
and make that data available the daemon protocol back to irush,
so that irush can 'poll' for the info.
The latter is probably the best approach, but would involve
irush having to contact each machine busy rendering to get
the accumulated percentage info. Might be possible, but kinda
ugly, because currently rush daemons don't look at the log data,
it just redirects it to the server, leaving the daemon available
to do scheduling and manage other tasks.
> You could, potentially, write wrapper scripts for the more common
> renderers that Rush supports, and if users wanted to get progress
> information for others, I'm sure they'd be capable of writing a small
> wrapper script.
If sufficiently motivated, you can certainly use the info from
'rush -lf' to write a dedicated app to monitor the logs of busy
frames and show the percent completion data.
Such a dedicated app shouldn't be too bad under unix using the
tail command.. a bit harder under windows because there is no
tail command in windows (unless you have the SFU or cygwin stuff).
You can do pipes in WIN32, but it's a bit more complicated..
I believe Active Perl for windows gives you access to that API.
> Your example of Mental Ray, again, would fall into the same camp as
> Shake - the wrapper script could (I don't know MR, so I don't know how
> easy this would be) know how many passes are coming out, and so turn
> each 0-100% progress into a subset of the whole progress
Determining the number of passes is the issue.. this means
diving into the scene files to determine this.. not somewhere
I want to go, as the scene files are often in proprietary
binary format, and are very hard to parse even if ascii.
And with the constant changes in the renderers, it would
be very hard to track.
But again, all this is a long way around just looking at the
elapsed times in the 'Frames' report, which are *realtime information*.
The Elapsed time for each frame changes while the frame is rendering.
--
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)
|