zoki Posted March 14, 2015 Share Posted March 14, 2015 yes sure need to find different aproach anyway with 40 ray limit it takes an hour Quote Link to comment Share on other sites More sharing options...
Serg Posted March 14, 2015 Share Posted March 14, 2015 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? 1 Quote Link to comment Share on other sites More sharing options...
Guest tar Posted March 14, 2015 Share Posted March 14, 2015 (edited) 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 March 14, 2015 by tar Quote Link to comment Share on other sites More sharing options...
zoki Posted March 14, 2015 Share Posted March 14, 2015 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? Quote Link to comment Share on other sites More sharing options...
Guest tar Posted March 14, 2015 Share Posted March 14, 2015 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. Quote Link to comment Share on other sites More sharing options...
Serg Posted March 14, 2015 Share Posted March 14, 2015 At 1080p, the hack + settings produced this result in 21m21s. On a i7 4930K @ 4.3Ghz Quote Link to comment Share on other sites More sharing options...
Serg Posted March 14, 2015 Share Posted March 14, 2015 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... Quote Link to comment Share on other sites More sharing options...
Serg Posted March 14, 2015 Share Posted March 14, 2015 No variance AA. Decouple Indirect On 10 min rays on direct lighting 40 min rays on indirect lighting. 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 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... Quote Link to comment Share on other sites More sharing options...
zoki Posted March 15, 2015 Share Posted March 15, 2015 very nice results Serg I will certainly dial in those settings to see my render times thanks Quote Link to comment Share on other sites More sharing options...
Serg Posted March 15, 2015 Share Posted March 15, 2015 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. Quote Link to comment Share on other sites More sharing options...
Skybar Posted March 15, 2015 Share Posted March 15, 2015 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. Quote Link to comment Share on other sites More sharing options...
sebkaine Posted March 15, 2015 Author Share Posted March 15, 2015 great stuff Serg , thanks for all the tricks ! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.