Does Mantra generate actual subdivided geometry when using the Render

[magneto]

Hi,

 

Does Mantra generate actual subdivided geometry when using the Render Polygons As Subdivision?

 

Because a simple tube object with some holes take over 10GB of memory. I thought Mantra was rendering by calculating the limit surface without generating any new geometry.

 

As explained here:

 

 

Not sure if it's possible but if it's generating the actual subdivided geometry, then what subdivision depth does it use and how does it calculate that?

 

 

Thanks

[pbarua]

Does Mantra generate actual subdivided geometry when using the Render Polygons As Subdivision?

 

 

I guess it does.

 

 

 

then what subdivision depth does it use and how does it calculate that?

 

 

Subdivision depth get used when you are manually using subdivision sop. This way mantra ignores render time subdivision (Render Polygons As Subdivision).

Edited December 26, 2014 by Pradeep Barua

[pbarua]

I suggest you to go through this:

https://www.sidefx.com/index.php?option=com_content&task=view&id=2332&Itemid=362

[fathom]

yes, mantra generates geometry for subd surfaces.  very few geometry types are not diced, if i recall correctly.  i think it's polygons and some of the simple primitives like spheres and tubes.  and if you put a displacement shader on them (even if it does nothing) they'll be diced as well.  (for mpoly, everything is diced, but also things get booted from ram a lot quicker, so maybe it evens out).

Edited December 27, 2014 by fathom

[paxsonsa]

I found using the Open SubDiv cut back on the memory a bit 

[amm]

With inevitable 'I hate to say that'. Made a few comparison with 3delight path tracing mode and true displacement, using the same, around 1mio poly mesh generated in Houdini. While 3delight seems to be much slower than Mantra when it comes to path tracing speed - it took just one to two gigs of memory, for the entire task. It seems 3delight people were able to overcome somehow, these common problems of Renderman type dicing, together with path tracing. But Mantra developers didn't.

I think I tried every possible combo in Mantra, kd tree, micro poly with PBR, so on. Some methods helped a bit, but still, nothing comparable to 3delight's sparing of memory.

Hope we will be happily surprised in next few days, otherwise, not so good future for entire Indie experience, I'm afraid.

Edited January 11, 2015 by amm

[fathom]

With inevitable 'I hate to say that'. Made a few comparison with 3delight path tracing mode and true displacement, using the same, around 1mio poly mesh generated in Houdini. While 3delight seems to be much slower than Mantra when it comes to path tracing speed - it took just one to two gigs of memory, for the entire task. It seems 3delight people were able to overcome somehow, these common problems of Renderman type dicing, together with path tracing. But Mantra developers didn't.

I think I tried every possible combo in Mantra, kd tree, micro poly with PBR, so on. Some methods helped a bit, but still, nothing comparable to 3delight's sparing of memory.

Hope we will be happily surprised in next few days, otherwise, not so good future for entire Indie experience, I'm afraid.

well, if it's really slow, maybe they're not really doing anything special and simply dicing and throwing out results to keep ram usage down.  in mantra, the unified cache settings are supposed to limit how much ram is utilized by dicing.  try dropping it down to something tiny.

Edited January 13, 2015 by fathom

[amm]

well, if it's really slow, maybe they're not really doing anything special and simply dicing and throwing out results to keep ram usage down.  in mantra, the unified cache settings are supposed to limit how much ram is utilized by dicing.  try dropping it down to something tiny.

yeah it seems exactly that, 'they're not really doing anything special'. Anyway I think I've located the problem, at least, my problem. It seems that Mantra 'dicer' simply does not like too much of triangles in rendertime subdivision. Made a simple experiment, exported my object to Softimage, did 'quadrangulate' there, imported back to Houdini, render pre-proceesing time and memory went back to something quite normal.

But, well, 3delight for Softimage ( that's in picture) dices the thing in second or two, with or without triangles. And by the way, where is 'quandrangulate' operator in Houdini .

Edited January 13, 2015 by amm

[pbd]

well, if it's really slow, maybe they're not really doing anything special and simply dicing and throwing out results to keep ram usage down.  in mantra, the unified cache settings are supposed to limit how much ram is utilized by dicing.  try dropping it down to something tiny.

 

In 3delight there is no dicing of subdivision surfaces when in path tracing (which is nowadays the new default rendering mode of 3delight). The only exception is when the subdivision surfaces are displaced, in such case they are diced. So it is completely normal that you get much faster results.

 

 

i. While 3delight seems to be much slower than Mantra when it comes to path tracing speed...

 

 

Could you elaborate in which set of conditions? I believe it is quite the opposite.

Edited January 20, 2015 by pbd

[amm]

In 3delight there is no dicing of subdivision surfaces when in path tracing (which is nowadays the new default rendering mode of 3delight). The only exception is when the subdivision surfaces are displaced, in such case they are diced. So it is completely normal that you get much faster results.

 

 

 

 

Could you elaborate in which set of conditions? I believe it is quite the opposite.

Exactly, comparison applies to 3delight plugin for Softimage. Found much easier in Mantra, to clean the noise to some reasonable level, using Mantra 'reflection ratio'. Perhaps because 3delight for SI does not expose the MIS 'weight' ( this is equivalent to Mantra reflection ratio, I'd believe), it seems there's some automatic adjustment, which somehow does not fit to my personal taste.

By the way, I think I feel the force of Renderman Jedi Master:)

[pbd]

First of all we should clarify on which type of noise you are trying to resolve.

It looks like you are speaking of indirect specular (reflections). Now I don't really know in 3dfs/xsi but in general 3delight does the same, if the BSDF is not so reflective or dark, it will send less rays just like mantra does. By highering min reflection ratio in you weight up the samples on all specular BSDFs (indiscriminately), in 3delight you don't have a global control, and you should higher the max samples on your shader (above the total pixel samples amount per pixel). It would be interesting to know also at which pixel samples values you were rendering. I usually render with DOF and motion blur and use high pixel samples values, 16x16 or even more (and it's still damn fast), in such case I don't have to higher samples locally because I already have enough subsamples within the pixel. Usually when DOF and motion blur quality is locked there is very little local sampling to touch. 

 

Anyway it's hard to compare in different packages/integrations. I personally love both 3Delight and Mantra, for me they are in a league on their own and the others are behind. I am just looking now at how to update 3delight integration in Houdini as we'd like to get the same result we get in Maya.

 

But it is my general belief that Mantra (and VEX) in Houdini will always be unbeatable and uncomparable as it is so well integrated in all contexts. This is one of the main reason of why Maya will always, ever and forever, suck lollipops: no shading language applicable to all contexts and in general a package done without rendering in mind, which is a disgrace since rendering being at the end of the pipe collects everything (garbage included) and can teach one a lot, for example about scene assembling. Certainly insisting on using mental ray won't help them

 

As per the Jedi stuff... pic.twitter.com/CQW49HYovA 

Edited January 24, 2015 by pbd