Jump to content
sebkaine

Suppress small Artefact in PBR render

Recommended Posts

yes sure

need to find different aproach anyway with 40 ray limit it takes an hour

Share this post


Link to post
Share on other sites

You could try the following hack to try and help bias the samples toward the shadows. Open the pbr.h file in houdini/vex/include and find the line bellow (should be line# 169):

 

lum = sqrt(lum);

 

Change it to:

 

lum = sqrt(sqrt(lum));

 

it seems to help the crunchy shadow artefacts better/more efficiently than reducing noise level. The above line is what sets color space from linear to gamma 2.2, so just doubling the gamma... 

 

I got a good/quick result with that hack plus the following settings:

 

- Min Rays 1

- Max Rays 10

- Noise Level 0.0025

 

- Enable Indirect Sample Limits - On

- Min Indirect 1

- Max Indirect 100

- Indirect Noise Level 0.005

 

I wouldn't worry too much about high max ray samples. As far as I can tell, if you set 100 and it takes 10 to reach the noise level then 10 is all it used.

 

This looks fixed by setting go the Noise Level lower and the Max Ray sSmples up. Please see screen shots.

 

Isn't such a low noise level setting effectively setting every pixel to 40 samples? 

post-1495-0-23134900-1426356294_thumb.jp

  • Like 1

Share this post


Link to post
Share on other sites
Guest tar

yes sure

need to find different aproach anyway with 40 ray limit it takes an hour

 

 

I'm starting to miss the point that with all these posts how can one not optimise the renders? What else should we do to help. 

 

Rendering is a mathematical statistics issue, perhaps biased with the way the eye see more noise in the darker areas; as a quirky fact, it's always very interesting to think that when you render you are enacting the methods devised used to calculate nuclear weapons.

 

http://en.wikipedia.org/wiki/Monte_Carlo_method

 

 


 

 

Isn't such a low noise level setting effectively setting every pixel to 40 samples? 

 

 

 

I'd have to check the sample stats- perhaps it is but that test was not to optimise the render speed but to get rid of the noise - the posting said 'I cannot get rid of the noise' IIRC.

Edited by tar

Share this post


Link to post
Share on other sites

its unfortunately not just "simple" mathematics

 

there is lots of things to consider

 

scale size,

number of lights in scene

texture memory

etc.

 

if not in the companies we wouldnt need lighters any more but a "smart" alghoritm to optimize settings for each scene and get images with the lowest noise out

 

the idea is to get balanced setup that could pass in a moving sequence not just still frame

or at least good guiding/starting points for new people to mantra or students begining to render

 

@Serg

what was render time on your scene? and comp specs?

Share this post


Link to post
Share on other sites
Guest tar

I'm not sure I follow - none of these scenes here address your points of scale size, number of lights, texture memory etc. ironically these scenes require one to understand and use the algorithms implemented by the developers.  This code has taken the complexity out of the lighters hand. 

 

If we want to address the more complex issues then please post some complex examples.

Share this post


Link to post
Share on other sites

At 1080p, the hack + settings produced this result in 21m21s. On a i7 4930K @ 4.3Ghz

post-1495-0-61354800-1426358844_thumb.jp

Share this post


Link to post
Share on other sites

But yeah, just set 40min rays to get rid of the crunchy shadows altogether.

It doesn't appear to be possible to get rid of it while using var aa efficiently.

 

looks like odforce is re-compressing and scaling jpg's?... trying png...

post-1495-0-56396800-1426359709_thumb.pn

Share this post


Link to post
Share on other sites

No variance AA. Decouple Indirect On

10 min rays on direct lighting

40 min rays on indirect lighting.

 

post-1495-0-55495900-1426368895_thumb.pn

Took 25m22s

Shadows are much better, some areas are over/under sampled compared to var aa render. But imo I think I got more than the 4 minute difference back... + no time spent fiddling noise levels... Decouple Indirect is great.

 

IMO the best balance of time/quality is to not rely too much on var aa, so:

Var aa back On

5min10max direct,

20min40max indirect

 

post-1495-0-77224500-1426368969_thumb.pn

The result took 18m28s. and its less noisy than the first 21m21s render with 1min100max.

I find more often than not that var aa is best for adding polish... 1 min rays at any meaningful noise level is hopeful... any time I try that I get chewed shadows, esp without the hack. 1 min is only the best approach if your perception of the noise matches what var aa is catching.

 

Perhaps a easier general strategy is to set decoupled min/max rays to ~40 until quality good, then use min rays to reduce quality until unbearable... :D

Share this post


Link to post
Share on other sites

very nice results Serg

I will certainly dial in those settings to see my render times

thanks

Share this post


Link to post
Share on other sites

Actually 1 min ray in the above instance looks ok in shadows, as long as the pbr.h hack is in place. Saves another 2 min for 16m20s.

 

Doing some more testing with the pbr.h hack. I think I'm convincing myself its always better than not, but more so when the scene has dark areas... Would be good to get a confirmation/second opinion.

 

I also upped the lights intensity by 2 stops, to see if a simple overall brightness increase increases render times It does. Looking at the indirect samples map (without the hack) it is obvious that most of the image becomes clamped to max samples. Without the hack and 2 stops less bright like before, its the opposite, a lot of the image is clamped to min samples.

 

So, at half res for speed and 2 stops up. 

With the hack (1min10max 0.0025 direct, 1m40max 0.005 indirect), it takes 5m11s.

To get ~comparable quality without the hack it has to have the noise level halved (1min10max 0.00125 direct, 1m40max 0.0025 indirect). It takes 5m34s.

 

Very interesting to look at the indirect_samples aov comparison. Some areas pop up in sample count that were previously dark, while large expanses that have less noise got less samples. In other words I'm getting more samples where its needed and less where it isnt.

Variance aa out of the box looks more like a remapped luminance map whereas with the hack it looks more variance related.

 

post-1495-0-05008800-1426423483_thumb.pn

Share this post


Link to post
Share on other sites

Interesting stuff about that "hack". Maybe RFE to SESI about that? Ie, instead of only being able to set it to Linear/Gamma2.2, you could specify it yourself with a float parameter. 1 = linear, 2.2 = gamma 2.2, etc.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×