Displacement maps are crashing my renders during tesselation based on how many polygons I allow the displacement to create. Thing is - it's not due to a lack of memory.
I'm using MR to render some rocky cliffs. All the nooks and crannies are being put in using procedural displacement maps based on solid fractals. By the time I fill the (TV resolution) screen with this amount of displacement mapped geometry, the memory demands of the tesselation become quite high.
I have set the approximation editor values to limmit the creation of very small polys using a grid style L/D/A approach that is non-view dependant (to avoid polys "crawling" when the camera moves).
The most critical value is the Max Subisions setting. When it is 3 the render peaks at 700MB during tesselation on my machine with 1 gig of RAM. It renders fine but not enough detail in the cliffs. Crank up Max Subdivisions to 4 and the render gets to 900MB and crashes during tesselstion. Doesn't even try to use my 1 gig swap space.
So I stuck the same render on our brand new dual Xeon machine with 2 gigs of RAM. Still crashes out at 900MB used. Hmmm...
By the way 3 and 4 subdivisions are not magic numbers. The crashes seem to happen at any setting if the total number of polys created in the scene gets too high. I've tried using the "fine" tesellation method but have never even seen a single pixel of a render with this setting because the pre-calculation times seem to be 30mins plus! Not really production-friendly.
Help me - deadline approaching and lots of cliff scenes to render!
Thats bacause one process is limitted to some where around 1.4 gigs of memory. Also it might crash because it tries to allocate more than that and thereby not raising to that amount.
But i suggest you use the fine method its much more memory optimized. Not just so raytrace friendly!
laso try reducing your raytrace algorithm size! Not much of a mr fan myself so maybe someone has better input.
Hello, I'v had the same problems with displacement crashing at roughly 900MB of RAM (incidently for rocky cliffs too ). The ways around it I'v found was to use the "fine" displacement method, but in order to make it render in an acceptable amount of time, you HAVE to tweak the settings. Try making the length at 3.0 instead of 0.5. This will probably give a bad result, but will at least render. So from there reduce this number until you can get an acceptable result in a reasonable time. I would guess maybe something like 1 or 0.85 might be ok, but then again I haven't seen your scene.
Another thing you could do if possible, is to give different approximation settings for parts of your cliff that are farther away from the camera. Unfortunatly, you'll have to cut up your object for this since I don't think you can assign different approximation to components. Giving different approximation based on camera proximity is where I personally got the most milleage out of that "900MB".
Hope this all helps a little, and hopefully I'm not too wrong on all of this!
It seems that this is not only a displacement problem. I have done some tests with huge poly mesh and me thinks we have a poly count limit here. It goes up to half a milion polys and no more. Mayas render handles couple of milion polys with ease. From my perspective this is a bad memory handling and no workarounds should be needed for such a basic function, especially when some other renderers can pull a bilion count.
After much woes with large scenes (or at least scenes that were taking a "large" (roughly 600+MB) amount of memory), I'v tried to test the same scenes on windows 2000 instead of windows XP, to no avail, and finally tried my hand at linux, and to my surprise, everything seemed to worked fine! No more crashes on large displacement, scenes with lots of geometry or even scenes with large amount of textures in it. I'm not exactly sure why its the case, but at least I guess this may be a valid temporary solution.
Thank you all for your replies - this forum has taught me heaps about MR for Maya. I sent my scene to Alias and apparently they have recognised this as a serious bug and are currently working on a fix/workaround.
Very interested to hear about the non-displaced high-poly-count scene giving the same trouble. And with requards to Linux - would love to try that solution but can't swap OS's 2 days before the deadline.
Many thanks to all and feel free to add any other insights.
Just a thought, if you are using MR only for the sake of good displacement mapping...then why not just convert the displacement map to Polygons in the Modify Menu? THen just render in Maya's renderer. This can be done right?
have done a few tests with a nurbs surface that doesnot render because the MR renderer could not create face tesselation. So I used the approximation editor ... results: first the normal tesselation should be set in the maya attribute editor of the surface to a lower then the default value of 3/3 with 1.5/1.5 and the LDA settings in the approximationeditor of .5 /.085(= the alpha of the displacementTexture)/45 it renders now 2min30sec. and with .25/.085/45 3min15sec. the quality looks like rendered in Maya but there it needs hours to render...) with lower L ength than.25 it crashes but with a lowered tesselation of 1/1(with highest curvature quality) it was possible to reduce the Length value to .15 this gave me gigasharp displacement in 5min . ....decreasing of the L results in sharper and more complete displacement for higher render times increasing the tesselation forces the crashes because of exceed
). The ways around it I'v found was to use the "fine" displacement method, but in order to make it render in an acceptable amount of time, you HAVE to tweak the settings. Try making the length at 3.0 instead of 0.5. This will probably give a bad result, but will at least render. So from there reduce this number until you can get an acceptable result in a reasonable time. I would guess maybe something like 1 or 0.85 might be ok, but then again I haven't seen your scene.