Building in real situacion

tarikb · Post by **tarikb** » Thu Jun 06, 2013 5:12 am

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

Zom-B · Post by **Zom-B** » Thu Jun 06, 2013 5:30 am

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!

tarikb · Post by **tarikb** » Fri Jun 07, 2013 10:38 am

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

Post by **Oscar J** » Fri Jun 07, 2013 11:29 am

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).

Headroom · Post by **Headroom** » Fri Jun 07, 2013 12:25 pm

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.

Zom-B · Post by **Zom-B** » Fri Jun 07, 2013 8:04 pm

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!!)

Mor4us · Post by **Mor4us** » Fri Jun 07, 2013 10:09 pm

That girl looks like she was 2,5m tall

tarikb · Post by **tarikb** » Sat Jun 08, 2013 1:38 pm

Thank you all.

Zom-B · Post by **Zom-B** » Mon Jun 10, 2013 9:22 am

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 :/

Pibuz · Post by **Pibuz** » Tue Jun 11, 2013 2:55 am

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

tarikb · Post by **tarikb** » Thu Jun 27, 2013 1:03 pm

Thank to u all, it really helps

Here is finale render.

Post by **Oscar J** » Thu Jun 27, 2013 6:19 pm

Pretty nice!

Bosseye · Post by **Bosseye** » Sat Jun 29, 2013 1:07 am

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.