Indigo Renderer Forum

Work in progress.. I have problem with lights, it takes longer to render.. This foto renders for 20h, and it's not clear.. I use glass acelerator, and cuda whit my grafic card.. I need sugestions how to seth scene control, and lights, i have put lights Emision scale 5 000 000 l/m2, and 6000 tempeture, blackbody, s1.. And how to set scene in setup, enviroment ( should i set "add sun" ) ??? MSCR 3000 ??? SUPERSAMPLE FACTOR 3 (should i change that to speed up render)... Any other sugestions are welcome..

Thanks

It seems you use very small emitter inside your building!
Pure PT has some very hard time finding them, even with GPU support and Glass Acel. on!

I see a few options to help you here:

1) exchange the light inside the house to BIG planes with less emittance!

2) Give (PT)BiDir a try

3) Use region rendering to focus your new rendering on the problem areas only, and merge in PS or gimp later!

I use path tracing, becouse CUDA aceleration.. This is the diference whit and whitouth lights, i use network rendering, but it doesn't show it remains 380k/s, but on my network render info, it say that just from another pc indigo gets aceleratet 380k/s

As Zom-B said, try using BiDir or even one of the MLT options. Don't stare yourself blind on the samples per second numbers - you could have the scene converge must faster and with lower SPP using one of the other rendering methods (in scenes like this).

It has been discussed many, many times over the last few years here on the forum that the SPP number cannot be compared between different render modes.

Path tracing is a brute-force approach and the relative simplicity is the very reason that enables this algorithm to run on GPUs. It samples a lot but does not differentiate between a good to area to sample or bad areas to sample.

The more sophisticated algorithms try to determine what areas need better sampling. As such their samples are lower in number but better in quality.

If it has to be PT then ZomBs advice to make the light sources as big as possible is still the best advise. Also, make shire you use very simple glass. Some of the glasses in the MatDB use rather sophisticated Indigo features such as Cauchy B and tabulated absorption spectra ( or whatever that was called ) and can take a lot longer to render than just a 4mm thick, transparent volume with an IOR assigned to it.

Headroom wrote:Also, make shire you use very simple glass. Some of the glasses in the MatDB use rather sophisticated Indigo features such as Cauchy B and tabulated absorption spectra ( or whatever that was called ) and can take a lot longer to render than just a 4mm thick, transparent volume with an IOR assigned to it.

yes, something very important!

Your glass has some quite blurry reflections... why is that so?!
Use a simple specular material with IOR of 1.52 (facade glass may have different IORs but anyway) and set the color to uniform with a value of 0. Don't use glossy transparent material with high exponent!!

Also take care that your wall material for the inner house has not to high RGB values (max of 204) since otherwise the light gets bounced until forever and causes slowdowns + noise (and is unrealistic, since full 255 RGB is a full reflector!!)

That girl looks like she was 2,5m tall

Thank you all.

seems like the lady is still gigantic, same as the guy hiding behind the tree

What I just noticed i that your wood textures for the facade are scaled way to big!

I also have to admit that the very strong contrast tonemapping is too much for my taste...

The first floor still looks very noisy :/

I think Takrib is running into an old and known Indigo behaviour, which comes out when dealing with different kind of lightsources, such as sun/sky or majorly EXR used simultaneously with emitters: given the fact that Indigo dedicates more computing power to brighter lightources, the small indoor emitters won't clear. You (takrib) won't have to act only on their POWER (the "scale" parameter in SkIndigo) but also on their "intrinsic brightness", which can be controlled by the "base emission" parameter. After a long time of sperimentation and the essential hints from ZomB, turns out tha it is useful to switch to the "uniform" type and set a value of 10.000.000 for the environment emitters to get a somehow correct scale to work with small emitters, which can usually stay on common values and "blackbody" type.

EDIT: follow discussion at page 6
http://www.indigorenderer.com/forum/vie ... 69#p121769

Thank to u all, it really helps Here is finale render.

Pretty nice!

Pibuz wrote:I think Takrib is running into an old and known Indigo behaviour, which comes out when dealing with different kind of lightsources, such as sun/sky or majorly EXR used simultaneously with emitters: given the fact that Indigo dedicates more computing power to brighter lightources, the small indoor emitters won't clear. You (takrib) won't have to act only on their POWER (the "scale" parameter in SkIndigo) but also on their "intrinsic brightness", which can be controlled by the "base emission" parameter. After a long time of sperimentation and the essential hints from ZomB, turns out tha it is useful to switch to the "uniform" type and set a value of 10.000.000 for the environment emitters to get a somehow correct scale to work with small emitters, which can usually stay on common values and "blackbody" type.

EDIT: follow discussion at page 6
http://www.indigorenderer.com/forum/vie ... 69#p121769

Just in support of this, here is a quick illustration/experiment of the point about emitter power and processing time:
Light 1 on the left has a lumen (lm) value of 500,000
Light 2 on the right has a lm value of 2500 so only half a % of light 1.
The render is left to run for a minute or so and then then the gain of light 1 is dropped to 0.005 (ie half % of the original 500,000) essentially resulting in the same lm value as Light 2. Its pretty clear which light has been given the rendering priority in Indigo.