you could get the available mental ray batch render flags with "render -r mr -help".
afaik there is no possibility to render subregions at this point. you will have to export your scene as .mi file and render it with the ray command (mr standalone). There you got options to render a specific tile. Check the "mental ray User Manual" in the docs and look for the parameter "-window x_lowint y_lowint x_highint y_highint". In the command line you should get all parameters with "ray -help" ... but there might appear error messages about not installed spm services. I never did a .mi rendering with the Maya distribution. In this case I can't help you much further I guess, if these errors appear for you too. Sorry, I got no time yet to get deeper into this. But try and let me know, how far you got with this.
Last time I said, "Sorry, I got no time yet to get deeper into this."
Let me say, this time I HAD to get deeper into this, because a week ago I had to render passes for 2 images at DIN A2 300dpi resolution - means around 7K - with much geometry and textures all around AND I was experiencing serious rendering problems. I'd like to post my experiences and solutions. Perhaps it might help someone somewhere sometime ... perhaps me again :)
Some facts in short about the environment:
- Maya5.0, Cut Number 200304040010
- Batchrendering with mental ray: version 188.8.131.52, 27 Feb 2003
- 2 images, same scene, different camera views
- 2 machines: DELL DUAL XEON 2.8, 2GB
The problem which got me most angry about was render logging. It simply left me alone with the aborted rendering which did fine for an hour or so without saying anything about why the rendering didn't went on. The only thing that indeed did appear, was a message window with "Microsoft Visual C++ Runtime Library" in title bar saying "Runtime Error! ..." Thank you for the message ... whoever
I knew, that the same scene did render at 4K. So, the problem was about system resources, I assumed - hard to believe, if you sit on this big workstation and spent time on rendering optimization again and again, so that rendering c o u l d n ' t experience memory issues at all.
// FINDING REASONS
I used two machines of slightly different kind to explore the problem.
1. ILLEGAL_PEOPLE___I thought of some certain object or texture that MR in some way didn't like and forced the renderer to crash. Someone would say, render into Render View and watch at which point rendering crashes and the mentioned msg win appears. You should know, in Maya GUI I got to the error just at the render initializiation point, to be honest I even hadn't to start the Rendering.
Please try this: Start maya, put some resolution like 9354 x 6614 into RendGlobs, open the Render View and make a Snapshot. For me, this would force maya to crash. I could reproduce this on other machines too with even lower resolutions.
2. GET_LOCAL___I thought of network problems, because the days before I noticed some traffic jams accessing the fileserver. I took the whole rendering locally, making it independent from network access. Nothing changes.
3. RENDER_SPACE___Although I was sure that I did BSP optimization well, I changed the values again that the render would take less memory (taking a longer time to render). No, try again ...
At this point I would like to quote something I found in the Maya5 docs under "release notes - mental ray for Maya rendering" a week later:
Windows crashes when you render scenes with high poly counts (e.g. 1,000,000)
Turn off Scanline Rendering in the Render Globals or reduce BSP Depth to something like 20 to allow the scene to render. Well, didn't work for me, but reminds me how important it is to read the release notes.
I got more angry, because I was left in the dark and I had to finish the job in the next 24hrs. Well, I think at this point I thought of getting with it to cgtalk, but I decided to do some more research.
4. REPAPER_TEXTURES__From the infos MR dropped into the shell by rendering the images I noticed that the crash (which was most happening at the same point of processing) was occurring just after reading some textures. Perhaps MR got into problems with some file format issues.
Without searching for some information about that, I converted all textures to the MayaIFF format by "imconvert.exe" which is included in the Maya distribution and of course changed the texture paths by the help of Crow Yeh's FileTextureManager (http://www.highend3d.com/maya/mel/?section=project#1012).
After that, I got a couple of reading errors by rendering with these - what a bad day. I never trusted this imconvert thing that much, I'd like to say. Trashy thing.
I did the conversion to MayaIFF again with one precious thing of software called Shake.
This is solution 1. The Rendering finished on my local machine without any errors. It took 5 hours.
But on the other machine that I did my render debugging on this one didn't work.
As I said I had to render 2 images and at the time my machine was rendering I couldn't predict whether rendering would finish or not. That's why I had to get this second machine to render this f***ing scene too.
5. GET_IN_CONTACT___I hacked the facts in my messenger and sent it to a friend. His name is Lutz Paelike. He is much more into these Maya R+D and programming things than me. Props to Lutz! He got me to solution 2 (point 7).
6. THE_REGIONAL_LEVEL___First he suggested to render regions. Yeah, this would be the "traditional" way. But it's not that simple as one might expect or one might knew it from Softimage.
Programmers left closed doors, means neither in GUI nor in BATCH any parameters seemed to be available. But there are. These are Attributes of the "mentalrayGlobals"-node and called "useRenderRegions", "topRegion", "bottomRegion", "leftRegion", "rightRegion". But they are not available in the GUI, so you've to set it by the ScriptEditor or by a (render-) script for the BATCH. They are correctly save within the scenefile, ... there called like ".top" and ".urr". BUT I suppose that these are not translated by Mayatomr, because MR simply didn't render any regions. If my assumption is right, the only way to render regions with MR in Maya 5.0 would lead to render mi-files. I did'nt want to do this because with Maya (unlike with Softimage) you run into setting some more environment paths and SPM license issues. I had no time for that kind of fun.
I don't know for sure: Do I need a MR Standalone License to render mi-files?
7. FINALLY___Lutz's second suggestions was about .map-files - a memory-mappable texture format. This is solution 2.
Memory mapping means that the texture is not loaded into memory, but is accessed directly from disk when a shader accesses it. ... This greatly improves memory... usage ... For more informations search the docs. There's more to know about it.
Well, I knew some about MR's .map-capabilities and I used .map-files before for HDR issues, but I wasn't aware of the big influence on render optimization, I could achieve by using them. But it's obvious.
I converted all textures to the .map format by "imf_copy.exe" which is included in the Maya distribution. You will find it in the "bin"-folder. This process got the second machine to render the scene (oh, a rhyme).
It took 4 hours to render and made a happy man outta me ... and more experienced :thumbsup:
I wish I had the time to clearly isolate the problem, because I didn't ... although the renderings finished, which of course is most important.
So, I smell some memory...file-format...reading...conversion-issues in the mist. I hope all these things I tried will do it next time. :)
If anyone got some questions about this, don't hesitate to drop it here.
Perhaps someone would like to know how to batchrender by script with MR in Maya 5.0., because you really don't get that much parameters for MR batch rendering, right? But you could set them all by a render script ...
... but I still have to do some work now.
01-19-2006, 07:00 AM
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.
vBulletin v3.0.5, Copyright ©2000-2014, Jelsoft Enterprises Ltd.