For cached frame buffers, the temporary disk files are saved in 'tiled' .map format which is limited to a file size of 2GB. Therefore, a single frame buffer may not exceed this 2GB size limit.
For example, the resolution of a square 8-bit RGBA frame buffer is limited to about 23,000x23,000 pixels.
For example, the resolution of a square 8-bit RGBA frame buffer is limited to about 23,000x23,000 pixels.
is this fixed in maya 2011
Posted by: Joe marzi | 31/03/2010 at 08:09 AM
I just released a script to break a scene down into Matte Passes on a Material basis that avoids the buffer bug by not using any write to color buffers.
http://crispy4004.isgreat.org/#tutorials
Posted by: crispy4004 | 21/01/2010 at 12:12 AM
DeeX just recently released his Custom Shaders that give us Mental Ray users a fully functional, easy to use, pass system without the buffer bug.
http://forums.cgsociety.org/showthread.php?f=87&t=843425&page=1&pp=15
It is only lacking custom Pass support, but in time that will be there.
Posted by: crispy4004 | 17/01/2010 at 09:30 PM
btw can you shed some light on why this happens.. and is there any chance of the whole bug going away in the next variations
Posted by: Joe marzi | 15/01/2010 at 11:37 AM
thanks a lot ash... really looking forward for the solution.
Posted by: Joe marzi | 15/01/2010 at 08:34 AM
Sweet, thank you so much for looking into this Ash. Let Owen we all really appreciate it as well.
Posted by: crispy4004 | 14/01/2010 at 08:14 PM
OK, I think we have some sort of a workaround to drop the render time.
However it comes with a price. :/
The file was sent to me from crispy4004
No Buffer = 09 sec
With Buffer = 42 sec
Modified buffer = 24 sec
I’ll let my friend Owen provide us with the details in a separate blog entry
Thanks to Justin for his advice on this mater
Posted by: Ash Aiad | 14/01/2010 at 04:33 PM
Sorry about the images not loading, you can see my the examples here:
http://crispy4004.isgreat.org
My pass approach is modeled after Luma Pictures workflow, only with Mia Materials and recently linear workflow (which I'm sure they are using now as well).
Autodesk does have the workflow between Maya and Toxik pretty well documented. They had an online class several months ago that went through the demo scene with the astronaut, and there is are also videos online at the AREA.
The problem is they are filled with poor pass practices that cut corners at a sacrifice in quality and control. The real tragedy is the entire Maya Pass system is built to function under that workflow, making it very difficult to work in a more professional manner.
Posted by: crispy4004 | 13/01/2010 at 08:34 PM
the links u have posted arn't working here.. and yes I agree that alot of the passes dont make much sense... Autodesk or MR should publish a proper document or tutorials telling how they intend for all of these to be used.
btw; u can get facing ration with [object incidence camera/normal] pass ...It looks like a facing ratio thingy.
and I do miss the multi-matte pass so much in mr.
Posted by: Joe marzi | 13/01/2010 at 05:31 AM
Even if the bug is fixed, it's such a time sink that I am forced to do all my setup through "write_to_color_buffers" because of less than ideal outputs of certain passes (Indirect, Direct Lighting, and diffuse, I'm looking at you). I realy wish the Dev team had taken better note of the Mia_Material outputs, and Vray's passes prior to building the system. The current passes in the Render settings window give the compositor so little control that it begs the question, what is the point to using them in the first place?
I have several passes examples on my website that show what more ideal passes look like. For example:
http://crispy4004.isgreat.org/wp-content/uploads/2009/04/pass-breakdown3.png?rand=988248240
And the composited result:
http://crispy4004.isgreat.org/wp-content/uploads/2009/04/face.png
I hope the next Maya version has Mia material outputs, including Raw and level Passes, as selectable passes in the render settings window. That and a couple other passes like facing ratio, pointworld, and a Multi-Matte feature like Vray would be incredible. Kinda doubt it will happen, but I can dream.
Posted by: crispy4004 | 12/01/2010 at 11:03 PM
Deex's fast_buffer_output works that way, but what he is working on now is completely different. It is essentially Puppet's solution re-tooled to work directly with standard Mental Ray shaders.
Hopefully when released it will give us the work around for this nasty bug, EXR compression, and a far superior, streamlined workflow with Mental Ray.
Posted by: crispy400 | 12/01/2010 at 10:45 PM
deex is a script which uses the Puppet shaders at it's back end, once again in a large enough renderfarm, that is not an option.
but it's nice to have an alternative,
I hope Ash comes up with some sorts of solution... even if it is in the next version of maya. This small bug renders the whole system useles...
Posted by: joe marzi | 12/01/2010 at 04:07 PM
Unbelievable. I've been reading that using FG/GI with custom color passes can also crash a render. I can't believe there's no out of the box solution to this, it's driving me crazy.
Posted by: Kevin | 11/01/2010 at 11:43 PM
Looks like Deex was already 2 steps ahead of me.
http://forums.cgsociety.org/showthread.php?p=6292640#post6292640
Posted by: crispy400 | 11/01/2010 at 10:36 PM
looking forward to seeing that solution.
Posted by: red | 10/01/2010 at 09:41 AM
The puppet shader is the only practical public solution at the moment, but it only allows for 10 special passes, which is not nearly enough. It's especially a problem if you prefer the superior compositing control you get when using the Mia_Material outputs written to custom frame buffers (the RAW passes IMO are absolutely necessary). Those ten slots get filled up rather quickly.
I'm trying to work on a solution right now. Hoping I can get some EXR compression in there as well, another thing that is currently lacking in the Maya setup.
Posted by: crispy400 | 09/01/2010 at 07:59 PM
this a real painstaking problem.. A lot of the time working with buffers is the only option that we have ... is there a solution except for 3rd party plug-ins.
Posted by: Joe marzi | 09/01/2010 at 03:28 PM
I sent you an email with the example file I used for the picture.
Sorry, I don't have an example from production to send, but I may be able to get someone else from CGtalk who can.
Posted by: crispy4004 | 08/01/2010 at 07:10 PM
Can re-produce it with a file from 2 sec to 5 sec
But I still like a “production” file to pass to developers
Did you already sent us one ? I need to track it down please
Posted by: Ash Aiad | 08/01/2010 at 06:59 PM
Here is the most recent thread, out of many, at CGtalk that discusses the problem:
http://forums.cgsociety.org/showthread.php?f=87&t=685776&page=1&pp=15
Someone even had a 8 minute render turn into 50 minutes.
Posted by: crispy4004 | 08/01/2010 at 06:56 PM
Oops, forgot to mention you also need to create the custom_color pass.
I think the problem also only occurs with slightly more complex scenes. By that I mean you have more than a certain number of objects in the scene, but it doesn't take much.
Posted by: crispy4004 | 08/01/2010 at 06:28 PM
Sure, I'll be more than happy to send a sample file, I'll send it in the next 10 minutes or so.
Posted by: crispy4004 | 08/01/2010 at 06:11 PM
Ash Aiad, it's really easy to re-create.
Just create a "write_to_color_Buffer" node in the scene. As long as it exists, render times will fluctuate randomly, anywhere from 2 to 5 times longer than they should take. Here is a picture:
http://img189.imageshack.us/img189/6137/bugaq.jpg
Posted by: crispy4004 | 08/01/2010 at 06:09 PM
would you send me a sample file ?
[email protected]
Posted by: Ash Aiad | 08/01/2010 at 06:06 PM
I can, it's a bug. A very nasty one at that.
If you want to uses custom buffers effectively with Maya (without the random 5x render time increase), the only option unfortunately is to brush up on some C++ and Mental Ray shader writing and do all the buffer/file output coding from scratch.
That or pray the dev team fixes the issue. I really hope the fix, if it happens, takes place in a service pack. I don't think anyone should have to pay for an upgrade to get functionality out of a feature that was suppose to work 2 versions ago.
Posted by: crispy4004 | 08/01/2010 at 06:02 PM