Page 1 of 7 123 ... LastLast
Results 1 to 15 of 102

Thread: Why is the "Adaptive Sampling" pass so slow?

  1. #1
    Super Member Snosrap's Avatar
    Join Date
    Aug 2004
    Location
    Ohio, USA
    Posts
    4,923

    Why is the "Adaptive Sampling" pass so slow?

    I've been a long time FPrime user and with LW10 I'm transitioning back to LW's renderer with the new LCW. I have found the AA settings I like to use between .01 and .05 depending on what I'm working on. Why is "Adaptive Sampling" so slow? You would think that sampling pixels and making comparisons would be much faster than raytracing light sources. So what's the low down with the Adaptive Sampling and AA algorithims in LW?

  2. #2
    Recycled User vfxwizard's Avatar
    Join Date
    Nov 2006
    Location
    Near, far, wherever clipping planes are
    Posts
    177
    Adaptive Sampling takes a little to get used to, and is not optimized for linear workflow.

    However, in a nutshell, during AS passes there's a lot of raytracing going on. Actually, it doubles (iirc) the number of samples for each pass.

    So if you start with 9 antialias samples (9 rays), each pixel that exceeds the threshold (marked white) will cause 18 rays to be fired, and so on for each AS pass.

    In addition to this, some kind of surfaces require more rays:
    - those lit by light with a quality parameter (quality^2 rays)
    - those with reflection or refraction blurring (samples should equal number of rays here)
    - nodes with a sampling value

    I avoided mentioning radiosity, as the amount of rays fired depends on the mode: interpolated or non interpolated; with or without bounces... [In short: don't lower radiosity rays when using interpolated modes.]

    As for number of rays and multipliers, I am writing this straight from memory, so I may have got some numbers wrong. But doesn't really matter. What matters is that the more AS passess are made, the lower should be the quality (# of samples) for surfaces, lights, etc.

    This works because at each evaluation more rays are fired and averaged, thus giving the same result as an higher number of samples. [Don't use values too low - as a general rule don't go below 2 for reflections/lights and below 9 for non-interpolated radiosity.]

    However the right approach is very scene dependent. Sometimes AS is much faster than brute force, sometimes the reverse is true.

    Last but not least, the way contrast detection is computed means that in linear workflow you need to use very low values for threshold, wasting a lot of samples. You may find some threads here about Lightwolf's free color corrector for an approximate solution to this issue that will give AS a speed boost when using linear workflow.


    There would be a lot more to say, but this should already provide a reasonable speed increase. Hope it helps!
    "I'm no wizard, this is a brand."
    AD Lightwave and After Effects play nicely together: details in the bizarre, hijacked and fun thread about AE Link.

  3. #3
    Big fan of coffee raw-m's Avatar
    Join Date
    Jul 2003
    Location
    London
    Posts
    2,328
    Nice writeup! I would pay good money for someone to make a video tutorial about this. As much as I read articles about the Camera Properties and no matter how articulate I find it hard to apply these rules to my scenes. Even though the settings are very scene dependent I think to see a pro chipping away at some test renders and see what values they are tweaking would be invaluable!

    Anyone?

  4. #4
    Super Member Snosrap's Avatar
    Join Date
    Aug 2004
    Location
    Ohio, USA
    Posts
    4,923
    Thanks for the informative reply! "is not optimized for linear workflow." That I don't understand.

  5. #5
    Recycled User vfxwizard's Avatar
    Join Date
    Nov 2006
    Location
    Near, far, wherever clipping planes are
    Posts
    177
    @Snosrap My pleasure! as for "not optimized for linear workflow" there's a long standing issue with adaptive sampling that was pointed out since its introduction.

    Contrast detection is performed with an absolute value (the threshold) on the linear values. This is the right thing to do, but when using a linear workflow (only) rendering could be much faster by checking contrast in the gamma corrected image instead of the actual render.

    This issue arises because in a gamma corrected rendering you have very low values in the image. Those values are then remapped into brigher pixels for display.

    But this means that to catch that dark fine grain you need to lower the threshold, thus firing more rays than necessary even in the brighter areas of the image. It's not wrong, but neither is as fast as it could - hence the "not optimized" definition (which is an understatement, as the speedup can be huge).


    There are some workarounds -the most common is to apply Lightwolf's "db&w Simple Colour Corrector" (free plugin) as a pixel filter with a gamma of 2.2 so that LW is forced to detect contrast in the display space. Then, an inverse gamma of .4545 is applied as an image filter.

    This approach works in practice, but is less than ideal for antialiasing. There are several threads that deal with this issue, but you can skip them and just try the above setup - chances are your renders will be faster (higher threshold = less rays) and you won't even notice the minor artifacts produced by the forced color space conversions.

    The best solution would be to have this as an option inside LW's renderer. Hopefully in the future...


    @raw-m Thanks! I prefer written tutorials, but this in fact is something where a video would work much better. Actually, doing some LW tutorials was in my new years' propositions... Too bad it's May already.
    "I'm no wizard, this is a brand."
    AD Lightwave and After Effects play nicely together: details in the bizarre, hijacked and fun thread about AE Link.

  6. #6
    NewTek Developer jameswillmott's Avatar
    Join Date
    Dec 2004
    Location
    Gold Coast
    Posts
    3,171
    It should be noted that adaptive antialiasing seems to use a 'creeping' algorithm, so it explores the neighbourhood where it encounters a high contrast of pixels. Good for small details, the sampler will travel along the high contrast edges, it's pretty neat to watch and clever when you think about what it's doing.
    LightWave3D training, assets, news and discussion at www.liberty3d.com
    My opinions are my own and do not represent the opinions of any other entity, Liberty3D is not officially endorsed by NewTek.

  7. #7
    Professional enemy shill clagman's Avatar
    Join Date
    May 2007
    Location
    Huntsville, Alabama
    Posts
    1,162
    Adaptive AA is a clever method, it just needs a bit of refinement is all. Currently I use it to do all the heavy lifting in my scenes (yes with db&w pixel filter applied being the lesser of two evils).
    Seeing the glass as half empty is being an optimist when the glass is full of urine

  8. #8
    Recycled User vfxwizard's Avatar
    Join Date
    Nov 2006
    Location
    Near, far, wherever clipping planes are
    Posts
    177
    Quote Originally Posted by jameswillmott View Post
    It should be noted that adaptive antialiasing seems to use a 'creeping' algorithm
    Nice idea, I never thought about this -to me has always looked like a 3x3 kernel.

    I will test this out with a pattern and a darkening gradient. If it's creeping it should match even below the threshold. Thanks for the tip!
    "I'm no wizard, this is a brand."
    AD Lightwave and After Effects play nicely together: details in the bizarre, hijacked and fun thread about AE Link.

  9. #9
    Super Member Snosrap's Avatar
    Join Date
    Aug 2004
    Location
    Ohio, USA
    Posts
    4,923
    Thanks again for the explanation. I had forgotten about all the multiple settings using LW's renderer. However I'm liking the look more than FPrime's. Thanks again, it looks I have a lot to learn.

  10. #10
    Agreed with what vfxwizard has said (very interesting!), just a detail might need a bit more of clarification, I think:

    Quote Originally Posted by vfxwizard View Post
    Contrast detection is performed with an absolute value (the threshold) on the linear values. This is the right thing to do, but when using a linear workflow (only) rendering could be much faster by checking contrast in the gamma corrected image instead of the actual render.
    The right thing to do is perform the antialiasing (AA) operation in linear values, but what is not the right thing to do (and this has been overlooked by some outstanding render engines) is to consider the contrast threshold in linear space. Contrast threshold should be calculated in non-linear space, I think.

    For being efficient, the idea of minimizing the aliasing artifacts according to a threshold implies our visual perception. That is to say, we need apply more AA samples on linear values, where our visual perception is more sensitive. Since we are going to visualize in gamma-encoded space, we can expect that the sampling according to a contrast threshold behaves perceptually better in non-linear space. Moreover, this gamma/log correction should not be fixed, but rather should be selected by the user according to the output color space.

    Then, the AA sampling should be performed on linear values, but the contrast threshold used for applying this sampling should be calculated in non-linear space.

    It's because of these two considerations that a simple gamma correction at pixel filter level is a half solution. Let's see this situation with a very simple example and how we can solve it:

    This ball has been illuminated with an area light (quality=3) and rendered with Adaptive Sampling (AS) at 0.02.


    It has been gamma corrected after render at image filter level. We can see that even when AS has a very low value, we can still notice the shading noise in the dark areas.


    AA in borders however are nice and clean. This is because AA values have been generated in linear space. But since the contrast threshold has been calculated also in linear space, the sampling is not perceptually uniform for our vision. In simple words: AA = correct / Threshold = incorrect.

    For gamma-correcting the contrast threshold we need to apply this correction at pixel filter level. We can use the useful Mike Wolf's Simple ColourCorrector pixel filter or we can apply the correction in the so useful DP Image Filter Node Editor by using our favorite color correction node (SG_CCNode, db&w Colour Space node, db&w Simple Colour Corrector node, Aurora's Color Correction node, etc, etc, etc). The first option is simple and faster, the second option is slower but more flexible and powerful.

    Let's go with the first option in this case:


    We have now a nice and more smooth shading (even in the dark areas) and we are using the same AS level!

    However, since the AA has been performed on non-linear values, AA is deficient in borders because it has been calculated with the wrong values:


    A valid way to minimize this problem by keeping the simplicity of the setup is to increase the oversample. However it won't solve all the problems and we'll still have some issues in the AA of reflective borders and details, but it may be a viable solution in many cases. In simple words: AA = incorrect / Threshold = correct.

    A way to calculate the contrast threshold in non-linear space but perform the AA on linear values is by using the DP Image Filter Node Editor with any of our favorite color correction nodes and the DP GlobalBuffers.

    Idea is to apply a gamma correction from the Final Color buffer so that the renderer takes into account this new contrast ratio when calculating the sampling threshold. AA for all internal buffers will be affected by this new contrast threshold, but if there's no gamma correction pre-applied directly to these buffers, AA values will be linear for them at render time.


    This means that we are able to use the Final Color buffer to affect the contrast threshold at render time (we don't save this results, it's just for gamma correcting the AA sampling) and at the same time we store in a DP GlobalBuffer the same Final Color buffer in linear way (without any gamma correction applied). Then we can save this linear result with the DP Get GlobalBuffer node.

    In simple words: AA = correct / Threshold = correct.


    This last option is slower but provides more correct results in AA values. Consider gamma-correcting the threshold for linear workflow with any of the ways discussed here is indeed able to provide better results with the same AS values, which gets translated in faster render times as vfxwizard has already explained.

    Let's see a small example with very reflective surfaces (where AA flickering is usually problematic). In this mini-sequence AA has been applied in linear space and later the final result has been gamma-encoded at image filter level:


    Contrast Threshold is 0.02 and we still experience a lot of flickering in our CG element. The worst thing is that even if we decrease more the contrast threshold value, we'll see no difference because contrast ratios are too high to determinate the subtle differences in dark areas.

    In this mini-sequence, same AA levels has been applied according to a contrast threshold in non-linear space at pixel filter level:


    There's no flickering and even (when was unnecessary) if we diminish the threshold value, we'll indeed see a noticeable improvement. Perhaps Lightwave can use a similar solution natively



    Gerardo

  11. #11
    Wooow....
    I gues this one will be definetly be grabbed.

    Thanks again for an explanation Gerardo, for the content and presentation.

    Cheers

  12. #12
    Recycled User vfxwizard's Avatar
    Join Date
    Nov 2006
    Location
    Near, far, wherever clipping planes are
    Posts
    177
    Uber post Gerardo, thanks!

    I did try the same setup you describe, but scrapped it because it produced significant brightness shifts. Have you ever noticed something like that? (I will look for my test scenes with the brightness shift.)

    However if you suggest something I know it has to be good, so I tried again today and lo and behold, it works! So thank you.


    BTW, adding a limiter node before the gamma allows to clamp values, thus catering for another feature request of mine: low dynamic range contrast detection (without clamping the render as LDR does). This shaves off some more rays when trying to antialias extra bright surfaces next to standard ones.

    Would you mind sending a link to your post to the developers as a feature request? I have been asking for these options in LW since 9.x - your post is a great demonstration of the usefulness of having this in LW. And seeing is believing.

    Quote Originally Posted by gerardstrada View Post
    what is not the right thing to do (and this has been overlooked by some outstanding render engines) is to consider the contrast threshold in linear space. Contrast threshold should be calculated in non-linear space, I think.
    Geek talk alert. I strongly agree with you.

    From an engineer's perspective, the whole purpose of linear workflow is to decouple rendering and presentation. So performing contrast detection in linear space produces a render that is not biased towards any display. I can relate with this, the geek in me gives a nod of approval.

    Yet, adaptive sampling is already an user-defined, arbitrary, bias. Everything below the threshold is not deemed important, so if I choose a threshold that renders clean @gamma 1.8 then display the image @2.2 I still have to face a perceptually-biased image.

    So what's the point of sticking to linear? Allowing for non-linear contrast detection can only bring practical benefits as you have clearly shown.
    Last edited by vfxwizard; 05-20-2011 at 04:09 AM.
    "I'm no wizard, this is a brand."
    AD Lightwave and After Effects play nicely together: details in the bizarre, hijacked and fun thread about AE Link.

  13. #13
    Recycled User vfxwizard's Avatar
    Join Date
    Nov 2006
    Location
    Near, far, wherever clipping planes are
    Posts
    177
    Gotcha! The culprit was real lens camera's irradiance falloff. Setting it to zero there are no brightness shifts and everything works like a charm.

    Thanks again Gerardo!
    "I'm no wizard, this is a brand."
    AD Lightwave and After Effects play nicely together: details in the bizarre, hijacked and fun thread about AE Link.

  14. #14
    Quote Originally Posted by probiner View Post
    I gues this one will be definetly be grabbed.
    Pedro, hope it helps!

    Quote Originally Posted by vfxwizard View Post
    BTW, adding a limiter node before the gamma allows to clamp values, thus catering for another feature request of mine: low dynamic range contrast detection (without clamping the render as LDR does). This shaves off some more rays when trying to antialias extra bright surfaces next to standard ones.
    Don't want to get off-topic but this is an excellent idea, vfxwizard!

    It really improves the AA when the lighting contrast ratios are high. When the lighting contrast ratios are very very high, I've been trying another way. This is an experimental way to overcome aliasing results in scenarios with very high dynamic range (HDR) without loosing HDR data. Method is non-destructive, which means we are able to re-expose or tonemap our results without losing pixel data and keeping always a smooth antialiasing at any exposure level, no matter how high may be the contrast ratio between adjacent pixel values. As your feature request, I guess this concept might be implemented natively in Lightwave, too. I've shared this in a CGTalk forum, but I'll share it here as well in case might be interesting or improved. Idea is pretty obvious as we'll see if we take a look to the situation:

    For antialiasing operations in lighting conditions with high contrast ratios, pixels with very high values (superbright pixels) can be averaged with pixels with very low values (very dark or totally black pixels). If AA is applied in FP space, the averaged pixels will be still too bright for displays and we'll get aliasing. i.e. contrast ratio of this simple scene is about 133000:1


    And we can see flickering due to aliasing in very bright areas.


    If we under-expose a lot the image, we'll see antialiasing is there, it's just that those areas are still too bright
    .


    Traditional ways to solve this problem is to pre-limit the dynamic range (not necessarily at 0-1 range, just a compromise between medium dynamic range and good AA results) or to pre-tonemap at render time (again, not necessarily loosing all dynamic range). Both are very viable options and work very well for many cases.

    But these solutions have their downsides as well. Tonemapping operators preserve details but depending on the type of operator, not always preserve the intended contrast (though it could be re-adjusted in post) and for CG integrations it might not be totally scene-referred. Limiting the dynamic range is destructive for pixel data (is more or less what happens in a medium/low dynamic range camera sensor) but it's what probably provides the best AA results.

    So what if we need to keep full dynamic range in very high contrast ratios scenarios and still get a smooth antialiasing?

    In such case, idea was to use the full dynamic range (DR) result - which has the HDR values and looks aliased - but we use also the areas of the limited range AA - which looks right but has LDR values. What we do is to isolate the good AA results (limited range) so that it replace the bad AA results from the full DR version. We can re-expose or tonemap the HDR version and always use the good AA results.

    To do so, we need the DP_Pixel Filter Node Editor to store a full DR version and a limited range version - both generated at render time - this is important because results are not the same if we limit the dynamic range after render:


    Later in post (this can be done in any compositing package, but for explicative purposes I'm using DP_Image Filter Node Editor within Lightwave), we isolate the difference between the good AA results and the bad AA results by subtracting the LDR result from a limited range version of the HDR result. This difference is what is left over for getting the correct antialiasing areas.


    So we just need to subtract this from the HDR result. But before this operation, we limit its dynamic range too. Any re-exposure or tonemapping operation in FP domain can be done before this substraction. So we are able to adjust the exposure level of the HDR result (where aliasing is still a problem due to very bright pixels) by using the good AA antialiasing.


    In cases where some of the original aliased pixels are already antialiased (due to some tonemapping operation or under-exposure adjustments), we can use the luma of the tonemapped/underexposed version to drive the strength of the antialiasing correction.


    This provides a better AA according to the tonemapped areas


    Though ranges between 0-1 provide better AA, the final limited range is up to us. This technique can be automated in a node and applied to any buffer that presents AA problems due to superhigh contrast ratios (commonly the reflection shading buffer).


    Other cases may be solved more easily with the solutions discussed before.



    Gerardo

  15. #15
    Super Member COBRASoft's Avatar
    Join Date
    Dec 2005
    Location
    Oudenburg, BEL
    Posts
    3,178
    Oh my!

    NT, integrate this somehow natively please !

Page 1 of 7 123 ... LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •