12-29-2006, 01:24 AM
Is there a reason why he needs to render it with the standalone? Why not simply render with MR inside of Maya instead. It is considerably faster because your not having to write out all that data in the .mi format. It's a simple switch "render -r mr".
He really should look at the settings for the MR exporter. There is an option in there so MR doesn't write a file per frame. A few options that might make his life easier but both require maya though:
I don't think they realizes how much works a .ma to .mi converter is.
12-31-2006, 06:33 PM
There are alot of reasons for rendering with mentalray standalone instead of using mayatomr. The level of control is not only greater, but there are a number of features that aren't available with rendering via mayatomr, such as "multipass rendering" (not multipass rendering as it relates to "compositing", but rather to memory management, check the mentalray docs), and "on demand geometry".
Pursuit, what you could do is run a batch process on any given number of .ma or .mb files and using the mayatomr exporter you could export your own .mi files. This process could be automated and run on a render farm.
Think about how granular you want your mi files to be. Where can information be reused between different "shots". For instance are you simply going to write out a renderable scene for every frame of animation that contains everything? Or are you going to break it down into smaller chunks, and then manage that information via include statements. Remember that object definitions only need to be written out on a frame by frame basis if there is deformed animation. If you're animation is simply translated, the object def is written out for one frame, and the transform block is written out frame by frame. Then using include statements you manage how they're combined prior to rendering.
Take a look at the mi syntax and your current pipeline and how you can maximize your exporting to benefit your needs.
hope this helps
12-31-2006, 06:33 PM
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.