New Mental Ray shaders development

[Maximus]

After a lot of tests and tries here is last render i did with mila shaders
Render took around 8 hours, all the shaders in scene are mila.
It is lit with userIBL, FG and physical lights only.
Rendered on an i7 990x 6/12 cores, 24gb ram

Some datas:

Output 1600x900 - Unified Sampling min 1 - max 300 - quality 6 - cutoff treshold 0.01
Trace depth rays: reflection 4 - refraction 4 - combined 8
Filter gaussian 1.8
Final Gathering - 32 rays - 80 points - density 1 - 0 bounce - FG depth reflection 3, refraction 3, combined 6.

All the shaders in scene has the glossy sample set to 0, everything is driven by unified sampling settings.
There is still a lot of noise going on, to clean the transparent glossy glass in the vertical wall i would have to increase the unified or local sampling, roof could use more sampling, generally speaking there is still quite a lot of noise and its 8 hours render.

[rimg=200]http://img854.imageshack.us/img854/6326/jptest.jpg[/rimg]

Max

[Kzin]

nice test and rendertime is ok sofar.

for the glossi transmission, from my test you need local rays to clean the noise. in my archviz scene i have a very glossi windows and i need 128 local rays to clean this up. but mi is changing some things for that node, so perhaps it will be faster or render with less noise.

one big problem with your rendertime could be the ibl. i would not use user_ibl for interior when i have to render from the inside because you need alot of light samples to get smooth results. and lightsamples means shadow samples and this will increase the rendertime nearly linear from my experience. i would try to use portal lights, one big to fake the envlighting, so to replace the ibl and perhaps one or two more directly behind the windows. also try to use the user_ibl_rect with an hdr map applied, its much faster then using the user_ibl. sure, its only rectangular lights and you have to cut your hdr to correctly mapping it to the lights (or use the crop option in the image clip properties), but i would give it a try.

for fg trace depth, do you need that high reflect value? make it a difference if you set it to 1?

which arelight mode do you use in the glossi reflection nodes?
i think for your room top, try a value of 1 because most of the reflections are from the sky, so the ibl reflection could be enough.

i dont know which types of lights you are using for the headlights, but also here, try to use ibl_rect with hdrmaps applied. it renders alot faster then physical lights for example.

in general, if you have noiseproblems with 0 local samples in glossinode, then try to use 6 or 8 first. 8 mostly works, except you have brute force envsampling, this is a problem, but they looking for a solution already.

and last, your unified settings. try to render with min1/max125 and quality of 2 and compare with you current. if its like in my tests, you will not see a big difference but can saves some minutes.


and also in your image, there are nice reflectiondetails now, thanks to the new sampling of mila, all the fine highlights on the cups for example, like such details alot. ;)

[Maximus]

nice test and rendertime is ok sofar.

for the glossi transmission, from my test you need local rays to clean the noise. in my archviz scene i have a very glossi windows and i need 128 local rays to clean this up. but mi is changing some things for that node, so perhaps it will be faster or render with less noise.

one big problem with your rendertime could be the ibl. i would not use user_ibl for interior when i have to render from the inside because you need alot of light samples to get smooth results. and lightsamples means shadow samples and this will increase the rendertime nearly linear from my experience. i would try to use portal lights, one big to fake the envlighting, so to replace the ibl and perhaps one or two more directly behind the windows. also try to use the user_ibl_rect with an hdr map applied, its much faster then using the user_ibl. sure, its only rectangular lights and you have to cut your hdr to correctly mapping it to the lights (or use the crop option in the image clip properties), but i would give it a try.

for fg trace depth, do you need that high reflect value? make it a difference if you set it to 1?

which arelight mode do you use in the glossi reflection nodes?
i think for your room top, try a value of 1 because most of the reflections are from the sky, so the ibl reflection could be enough.

i dont know which types of lights you are using for the headlights, but also here, try to use ibl_rect with hdrmaps applied. it renders alot faster then physical lights for example.

in general, if you have noiseproblems with 0 local samples in glossinode, then try to use 6 or 8 first. 8 mostly works, except you have brute force envsampling, this is a problem, but they looking for a solution already.

and last, your unified settings. try to render with min1/max125 and quality of 2 and compare with you current. if its like in my tests, you will not see a big difference but can saves some minutes.


and also in your image, there are nice reflectiondetails now, thanks to the new sampling of mila, all the fine highlights on the cups for example, like such details alot. ;)

Going to swap to user_Rect and see how it goes, i'm using the default area highlight -1 mode on glossy reflection node.
Gonna try to swap userIbl with portal i'll do another render, thanks Kzin

edit: btw i had to swap the mila glass with the architectural because for some reason the clear glass with mila have some noise in transparency even with 0 glossy, which i have no idea why, maybe they are still fixing it. For glass i use 2 layers, top layer specular reflection, bottom layer specular transmission, blended with ior mode. It produces noise and its twice times slower than mia material to render.

[Kzin]

some more carpaint tests.
and yes, i have 3 nan little nan errors in 2 renderings. hope to get a solution for this while shader beta.

[rimg=600]http://s7.directupload.net/images/130206/8fp984qg.png[/rimg]
[rimg=600]http://s7.directupload.net/images/130206/vrfrnl6l.png[/rimg]
[rimg=600]http://s14.directupload.net/images/130206/yeidjg4k.png[/rimg]

Moderator edit: edited image links with rimg= tags (see next page)
If you want it changed back: I saved the original post - HB

[Hirazi Blue]

Look, I understand the need to render huge images! Displaying them 1:1 in this thread, however, results in a ridiculously image heavy thread, which has crashed my own browser twice so far. Please start using the rimg= tags!

[Kzin]

Look, I understand the need to render huge images! Displaying them 1:1 in this thread, however, results in a ridiculously image heavy thread, which has crashed my own browser twice so far. Please start using the rimg= tags!

sorry, did not see your edit. i changed the links for my last post, you have to click now on them to see full res.

[Hirazi Blue]

Thanks. That might, however be a bit too small.
I was thinking more about this

Code: Select all

[rimg=600]http://s7.directupload.net/images/130206/8fp984qg.png[/rimg]

Which takes the actual address of the image (the URL directly pointing to the png) between rimg tags, resizes it to width=600 and results in the following:
[rimg=600]http://s7.directupload.net/images/130206/8fp984qg.png[/rimg]

I went ahead and edited your last post accordingly, look at the edit to see what I did...
If you want it changed back, let me know, I copied the original URLs ;)

[Kzin]

I went ahead and edited your last post accordingly, look at the edit to see what I did...

thx, will use it for my next posts from now.

[cheeseburger]

Hi Kzin,
How did you do your grass ? It looks good

[Kzin]

Hi Kzin,
How did you do your grass ? It looks good

it does not look that good if you go closer, but thx. ;)

simple planes with some bending on it. duplicated and changed to get some variations. 1 used 2 groups, one longer and one smaller to fill the inbetween and give it more depth and volume near the ground. and then scattered with the scatter compound which can be found in the inet. shading is done with 1 diffuselayer, 1 scattering node and 2 reflection nodes for glossi reflections.

[etmthree]

Hi --

I'm at a bit of a loss. Been playing for a couple of days with MILA shaders in Softimage, and mostly really loving them.

However -- I'm unable to use the max_dist option in either specular or glossy transmission. If any positive value is entered in the ppg for max_dist, I get a hard crash immediately upon rendering. In fact, if shaderball is visible in the rendertree, I get a hard crash as soon as the value is entered.

I'm using SI 2013 SP1 in Windows XP 64 SP2.

Behavior occurs with Layering Library v3.10.3.16 and v3.10.3.17. I don't have any earlier version to check.

Anybody else have this issue?

Thanks!

[etmthree]

Default Basic MILAshaderperformance by light source comparison

So, leaving aside my problems with transmission shaders, here's my first structured test. This was rendered on an early-2008 MacPro (dual 4-core Xeon e5462 procs at 2.8 GHz), so the rendertimes are pretty high. I set up this scene to compare the performance and appearance of simple MILA shaders under a variety of visible area lights. The global scene settings included:

Light Relative Scale = 1
Light importance Sampling On
Multiple importance Sampling On
FG Exact Mode 128 rays -- a second series was done with FG Multiframe Mode 444 rays, 222 points, presample filtering 5.
Unified Sampling 12, 144, 1, 0


I used only the light shaders that seemed to support proper inverse-square distance attenuation: soft_light, soft_light with a geometry emitter, mib_physical_light, user_ibl_rect, mib_portal_light, and geometry with an emissive MILA material applied.
I set up each light (identical size, shape and position) to produce a good "white" on the white sphere, which in turn is "white" by the numbers in the MILA shader properties, not by the shaderball! I chose this approach because there's no apparent standard intensity for the various light shader types.

I was surprised at the wide range of intensity settings needed to do this -- the physical light is at 2000 units (achieved by adding it on top of itself through a color_basic node in the rendertree, as it is limited to a 0-1000 range), the soft_light is at 500, the user_ibl_rect light is at 2.8, the portal light is at 6.3, the geo light is at 500, and the emissive geo MILA emission intensity is set to 3.

The results are fairly consistent, with similar render times for all lights -- the exception being the user_ibl_rect version, which rendered 3 times more slowly than the others with FG in "exact" mode, but virtually as quick as the others with FG in "multiframe" mode. I was mildly surprised to see the non-light version looking good at all. I was even more surprised to observe the large amount of noise present in the user_ibl_rect render, given the high sample settings and the long render times.

Based on performance alone, the clear winner is the non-light version with interpolated Final Gathering, but the mottling artifacts visible at the edges of shadows, as well as general inaccuracy, make it unlikely to be satisfactory for animation. The most "natural" look to my eyes comes from the user_ibl_rect source, but the noise and render time make it unsatisfactory. The best compromise seems to be the physical light shader.

I do think that this points up the need for some properly-documented and sensibly named UNITS for light sources. It would be nice to be able to double-check images against ground truth in the real world, and to do that properly, it would be much easier if our units were similar to the ones used by photographers (or, less-usefully to most of us, lighting engineers).

Images below:

[rimg=600]http://s7.directupload.net/images/130221/36guo3md.png[/rimg]

Moderator edit: to succesfully use the img tags, or the rimg tags I used here, point to the image directly, not the html address... - HB

[Maximus]

Could you share the scene please?

[Kzin]

yep, pls share the scene, rendertime with ibl_rect is way to long, especially compared to exact fg with 128 rays. brute force fg is not usable for any realworld production scene, its slower then vrays brute force. so i guess there is something wrong. it looks like brute force fg is performing good, but try this in a more complex scene, rendertime will explode, especially with 128 rays.

from my test scene, rendering a big room with 44 ibl_rect area lights and 2 bounce fg with alot of glossis is done in about 3 hours on my machine, so there must something wrong. can you show you hdr you used for ibl_rect?
also, exclude the softlight from your tests and only use the native mr lights.
for the physlight intensity, use the blackbody shader as colorinput, color temperatur set to 6500 for white, you can insert alot higher values here without the 1000 limit.

again, the tests i did showing that ibl_rect is 2 to 3 times faster then physical light because of the light IS.
but cant really say something to the test without to take a look on your scene to see whats going on.

[Kzin]

I do think that this points up the need for some properly-documented and sensibly named UNITS for light sources. It would be nice to be able to double-check images against ground truth in the real world, and to do that properly, it would be much easier if our units were similar to the ones used by photographers (or, less-usefully to most of us, lighting engineers).

1 si unit is 10cm, so 10 units are 1 meter, thats the global value. all lights should use the correct falloff with exponent of 2. dont use the photographic lens shader and all is fine with scaling of lights. keep also your scene in realistic units then you dont have problems.
if you use the mia_photometric light shader then you should set the cd/m1^2 to 10000 and units to meter scale to 10.

[etmthree]

Could you share the scene please?

Not much there; hope you can share some insights.