Skipping Frame *** Deselected By Render, A Huge Waste Of Time

[timefly]

Hello Highend

We're currently producing a feature, using maya and mentalray standalone. To keep the sanity of our renderwranglers, and to keep the logistics of rendering reasonable, we've been exporting and rendering .mi files with multiple frames in them. However, with heavy scenes, the time it takes to skip through the frames that mentalray should NOT render is far too big. For instance if we have a sequence of 119 frames, to get to render frame 119, mentalray needs to skip through the first 118 frames..which can take up to 1 hour and 20 minutes. Effectively giving us a frame time for frame 119 of 1 hour and 25, since the rendering itself happens within 5 minutes or so...which is needless to say an extremely huge waste of cpu time.

Is there something we can do, something we missed in the commandline options?? Short of exporting and rendering single frame .mi's, which could turn into a bit of a logistics headache.

Thanks in advance

Christian Nerving

Lighting TD & Supervisor

A-Film

[joojaa]

Hmm... and this is helping your render wranglers sanity exactly how? Anyway its because the scenes aren't written there as is but rather by change form frame to frame and yes that means each and every change needs to be evaluated. Its a bit like editing a hugely compressed animation of frames.

Whats wrong with directories of files which is as much in logistical sense as the files. Besides haven't you ever heard of zipping files.

Anyway you can work this a bit like ribfies are handled in big production houses compressed into cvs files which then are purged out for each frame. this makes for a great compression but allows you to extract each file separately.

BUt all this said my experience with mr stand alone is 2 years old by now since i've lately just warngled occasional ribfiles.

[timefly]

We already have some very nice workflows for the environments, allowing us to preexport as mi files and just include at rendertime. But the scenes in question are character passes with up to 11 deforming hires. characters in them...so either way the files will be big...zipping could be an idea for the hdspace issue, buying tranquilizers for the wranglers i suppose, for the logistics part..(or simply clean out after the job is done..aka deleting the single mi's)..my main concern really is if our farmmanagement software (read: smedge 3 at present) will handle the 1000's of jobs to allow for single frame .mi's, hence the desire for a way of doing it from the multiframe .mi files, effectively keeping the joblist down.

Cheers

C

[joojaa]

OK the cvs approach will come in handy here since it squeezes the needed mem douwn (se all you need is save the change, but unlike multiframe mi dont do aincremental change but teke the aboslute value)

Anyway for smedge its no problem, i fi remeber correctly smedge can eb extended so for smedge to call a batch script instead of a single single mi render is as easy. So now a 10000 mi frame zipped / cvsed render looks like one.

So instead of calling mental you call yourscript

and yourscript is in oseufdofrom like this,

do
Extract wanted frame,
render
loop

Also you may find the way somewhere in between se having 5 frames per mi no prob.

But your renderwrangler should be more than equipped to do this. Imean thets what he gets paid for.