grain on dome light and IBL?

[sharktacos]

I'm trying to set up image based lighting using the dome light and am getting very grainy results. This happens whether I have my HDR image in the dome light or not. What am I doing wrong? Thanks!

[aweidenhammer]

That's a difficult question to answer without some more info. Without knowing you, and without knowing your settings, the most obvious possible problem is how you are sampling. Try using adaptive DMC, setting your max subdivs to 30 or so, and your threshold between .01-.006

Also in the settings tab, make sure adaptive is on all the way.

It could be that there is a very narrow area where light is getting in (interior scene) which will make it much more noisy, and sampling will have to be increased.
Provide more info, and we can provide a better answer?

Andrew

[sharktacos]

LOL! Yes, that's fair. I narrowed it down to the render settings. Still need to figure out which part exactly, the that will need to wait til Tuesday (long weekend woohoo!)

One thing I noticed is that I was using some simple geometry (a shot glass) that took reeeeeeeally long to render. For what it's worth the model was exported from Modo (it's one of the free models that ships with it) and exported as an obj. I had other models (the test model from vray-materials.de) in the same scene with higher poly counts that rendered at least 2x faster. Anyone know what may be going on with that? It seemed to especially choke when the model was sub-Ded (the 3 key in Maya), but was slow even without.

[pechart]

It seemed to especially choke when the model was sub-Ded (the 3 key in Maya), but was slow even without.

That's because vray takes 256 subdivisions by default if "Render viewport subdivisions" is checked. Try lowering that value in the Render Settings to something more reasonable and just pump up the values on objects that really need that much subdivisions (i.e. for displacements).
And maybe there are reflections bouncing around inside the glas?

[sharktacos]

That's because vray takes 256 subdivisions by default

Yes, I think you are right that the trick would be to lower that 256 number.

reading the manual tho I'm wondering how this number correspond to Maya's numbering? I believe that the 256 does not mean 256 subdivisions, but 256 poly faces generated for every poly face. Maya defaults to 2 subdivisions, which leaves ambiguous how many poly faces that would make. In other words, settings vray from 256 to 2 would not be the same as setting Maya to 2. So what would be good number in Vray to better approximate Maya's settings? 4 maybe? or maybe 16?

[djx]

I think a better default for this number would be 8. (And I always use "view dependant" with edge length=4.) Obviously it depends on how dense the mesh was but I have never needed more than 16 to remove all signs of faceting.

But even with 256, I dont think that means every face is divided this many times. It tries to achieve the specified edge length, and keeps dividing upto a maximum of 256, but if it gets the desired edge length after 2 then it stops. (I'd still use 8 or 16 though)

[aweidenhammer]

When using the subD (3 key) feature in MayaVray, you will incur a hit in rendertime (after all it is converting and subdividing the model). Most often a big hit in rendertime is due to the dynamic memory limit being too low. The default is generally too low for any production scene. Depending on how much ram you have, you can crank this up. The problem is if there is not enogh dynamic ram allocated the subD feature will only be able to divide part of your object/s render, then subD more. Very slooow. You should just increase your dynamic ram (in settings) and it will be much faster.

That said, it is even faster (most of the time) to pre-smooth your mesh, and render the literal geo, instead of having vray do the subD. You shouldn't normally have to adjust the default 256subdivisions. an edge length of 4 would never let you go that far anyway.

Andrew

[pechart]

Thanks for that explanation!

[vlado]

Andrew is right; just wanted to add that we are reworking the render-time subdivisions right now - in our initial tests, render times are three to four times faster.

Best regards,
Vlado