PDA

View Full Version : Some questions about mental ray integration

eem
07-30-2009, 06:26 AM
Hello softimagers. I come from the maya section and have been wrestling with the current implementation of proxies in maya and am curious if XSI is having these same issues.

The issue with maya is. Maya currently has assemblies integrated as proxies. The problem with this is, the assemblies use considerably more ram and take more than twice as long to render than instanced geometry or mip_binaryproxy. So I am using mip_binaryproxy in maya, but the problem with that is, mip_binaryproxy breaks BSP2 in maya and causes all kinds of weird things to happen like instances dissapearing.

Now does XSI use assemblies for it's proxy system and does it have the same issue that the maya assembly proxies have with increased ram and rendertime? (I hear it does, but would just like to make sure) And if so, can you use mip_binaryproxy in XSI and how well does it work? Does it break BSP2?

Then the other question is, does XSI support the frame buffer cached mode in mental ray?

Also, another question. I know XSI has the gigacore thing and I've used this before and it seemed to work pretty well. As I understand this, XSI can use your HD as essentially virtual ram so that you can load a ton of polys into the viewport, right? But does this feature then go over to mental ray as well? Does the mental ray backbone run off the gigacore and allow you to basically fill up mental ray renders with way more geometry than your ram can take and then just let the gigacore swap polys to HD and back?
PiotrekM
07-30-2009, 07:02 AM
mentalray core is same in all softwares I think..

Yes, assemblies takes more ram than they should. Which renders them to be useless for mass instancing of objects.

I dont know what binaryproxy is, but with just regular instances you can render eg bilion of trees.

what is frame buffer cached mode ?
mr in xsi has diffrent integration than in maya or max. It shares memory with MR, so it doesnt need to preload geometry for itself and stuff like that.
eem
07-30-2009, 07:45 AM
mip_binaryproxy is a hidden unsupported node in maya thats included in the last version of mental ray and it acts how you would expect a proxy to act. It has the same memory consumption and CPU usage as instanced geometry. Except, it loads the object from a .mi file on disk. Why autodesk did not use this implementation of proxies... no one knows.

famebuffer cached mode is a mode that you can enable on maya 2009 which lets chunks of the framebuffer be unloaded from ram and written to disk so you can render larger images. Although. To be honest. I haven't actually got this to work very well.

And you say MR and XSI share the same memory? Well this is kinda what I mean when I say, doesn't the gigacore memory management in XSI also run inside of MR? Cause I once used XSI to render something in mental ray that was very poly intensive, that would crash maya and 3ds, but XSI did it. So I was wondering if this is because the gigacore thing also runs in the XSI MR integration.
ThE_JacO
07-30-2009, 09:12 AM
The gigapolygon core is another deal, the main point of the integration is that in XSI the scene data is basically MRay compatible, so when you render it MRay uses the already stored data right away. In other applications it's first "duplicated" into an MRay friendly memory image and handed over, similarly to generating an .mi in memory and then handing it over.
Recently some better handling was implemented (mostly recycling) and things got better in Maya, but to my knowledge it's still far away from XSI's integration.
It's entirely possible that rendering directly to MRay from maya gui or maya batch will consume considerably more memory than doing the same from within XSI.

Both though tend to be not as efficient as rendering an .mi file directly, for which you need separate MRStandalone licenses though.
CGTalk Moderation
07-30-2009, 09:12 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.