Hash Fellow robcat2075 Posted June 7, 2012 Hash Fellow Posted June 7, 2012 While pursuing an AMReport Steffen found a way to optimize the Sub-Surface Scattering code. My first simple test gives promising results: that's almost 60% more frames per minute. This change is in v17 beta 5 available now! Quote
John Bigboote Posted June 8, 2012 Posted June 8, 2012 Yeah... thats BIG. Good news! I see in your test you are not using multi-pass. I seem to remember thinking there was some redundant calculating with SSS on every pass of MP, but you have shown it is more fundamental of an improvement. Me happy. Quote
Darkwing Posted June 8, 2012 Posted June 8, 2012 We'll see how it holds up on my system. I'm still a little miffed how my SSS time had to increase drastically when I upgraded OS's. Anyways, nuff of my whining Quote
Hash Fellow robcat2075 Posted June 11, 2012 Author Hash Fellow Posted June 11, 2012 Get out your old SSS projects and give them a test render and see if this change has created any side effects. So far, it looks the same to me, just faster! Quote
John Bigboote Posted June 11, 2012 Posted June 11, 2012 Yes, it is a certified improvement. You can now set the 'Relative Density of SSS Samples' higher than you could before(I think it topped out at 200 before) My test here is at 500... GREAT! Some might notice in my test that 'thin' objects in the geometry such as fingers, ears actually become BRIGHTER due to the SSS effect, not darker- I believe this is the way SSS should effect things, but may be wrong. In this test image, I have employed the use of a bulb light added BEHIND the figure... color set to bright yellow... intensity at 150... and set to ONLY effect the girl due to a light list. There is also FakeAO CPU being used. Even with the setting at 500 as I watch the render and see what A:M is working on, the SSS blips by very quickly. This is a MAJOR IMPROVEMENT! Quote
Fuchur Posted June 11, 2012 Posted June 11, 2012 Yes, it is a certified improvement. You can now set the 'Relative Density of SSS Samples' higher than you could before(I think it topped out at 200 before) My test here is at 500... GREAT! Some might notice in my test that 'thin' objects in the geometry such as fingers, ears actually become BRIGHTER due to the SSS effect, not darker- I believe this is the way SSS should effect things, but may be wrong. In this test image, I have employed the use of a bulb light added BEHIND the figure... color set to bright yellow... intensity at 150... and set to ONLY effect the girl due to a light list. There is also FakeAO CPU being used. Even with the setting at 500 as I watch the render and see what A:M is working on, the SSS blips by very quickly. This is a MAJOR IMPROVEMENT! ...and the coolest thing: SSS never really worked for me... I used the final-rendering-dialog and rendered SSS with it and the group was the last in the list and so on and still I got a black rendering... but that changed with this update . See you *Fuchur* Quote
NancyGormezano Posted June 11, 2012 Posted June 11, 2012 (edited) There is also FakeAO CPU being used. Hmmmm...I crash (17 beta5 32bit) every time I try my 16b project with SSS and FakeAoCpu (works in 16b). It will render all passes but then crashes. I do not think fakeAo plugin is working in 32bit? I am also noticing other crashes when I am trying to isolate problem. Started new chor, with simple lathe object, added fakeao, did onscreen render (Q) - crash boom bang. (doesn't crash in 16b) HOWEVER on the good side, before crashing, 17beta5 was running 23 seconds/pass versus 27 secs/pass for 16b Edited June 11, 2012 by NancyGormezano Quote
John Bigboote Posted June 11, 2012 Posted June 11, 2012 Hmmmm...I crash (17 beta5 32bit) every time I try my 16b project with SSS and FakeAoCpu (works in 16b). It will render all passes but then crashes. Hmmm-hmmm! I was getting a crash in 17/64/beta5 with FakeAO_GPU... I switched to CPU and is working fine. Have not tried V17beta5/32 bit yet... Quote
mtpeak2 Posted June 12, 2012 Posted June 12, 2012 Back to beta 4 for me, my tests crash on first pass while computing the SSS. Quote
Hash Fellow robcat2075 Posted June 12, 2012 Author Hash Fellow Posted June 12, 2012 Back to beta 4 for me, my tests crash on first pass while computing the SSS. Remember to send it to AMReports. Quote
John Bigboote Posted June 14, 2012 Posted June 14, 2012 Back to beta 4 for me, my tests crash on first pass while computing the SSS. Are you using Multipass when it crashes, or standard renderer. I am experiencing crashes mid-render with the standard renderer, switched back to MP... trying to gather if that solves it... or is SSS killing it. Quote
Hash Fellow robcat2075 Posted June 14, 2012 Author Hash Fellow Posted June 14, 2012 Initially, test your SSS without any FakeAO, just to test it on its own, to see if the changes are causing any problem. If one had a pressing immediate need, you could render your SSS scene to an EXR sequence and add the FakeAO in post (the more meticulous way to do it, anyway) Quote
mtpeak2 Posted June 15, 2012 Posted June 15, 2012 Back to beta 4 for me, my tests crash on first pass while computing the SSS. Are you using Multipass when it crashes, or standard renderer. I am experiencing crashes mid-render with the standard renderer, switched back to MP... trying to gather if that solves it... or is SSS killing it. Multipass, I never use the standard renderer. I haven't had any time for more testing, though it has to do with low extinction values. I've had models render with slightly high values. Quote
Hash Fellow robcat2075 Posted June 15, 2012 Author Hash Fellow Posted June 15, 2012 I haven't had any time for more testing, though it has to do with low extinction values. I've had models render with slightly high values. Steffen mentioned to me that lower extinction values require more memory. That might be a clue. Quote
Developer yoda64 Posted July 7, 2012 Developer Posted July 7, 2012 I'm I bit more on SSS now .... Appetizer for the next version, and a little bit explanation for the "Half extinction distances" problem - fixed all 0006189: SSS-Rendering will result in in black Surface in the final rendering, when using a material on the same group - changed all SubSurfaceScattering - SSS can now be used also in materials - for multipass rendering SSS is now computed only at the first pass (exception stereorendering) - fixed a crash ,if a patch is in more than one groups with SSS is set to on - fixed a memoryleak for multipass rendering - for choreographys a new menuentry "Calculate needed memory for SSS" is added this calculates and display's the memory, which will be needed for the SSS computation at rendertime and inform the user about this value or warn if too much memory will be needed for computation, it writes also additional information's about SSS to the logfile a case where SSS computation will need to much memory is as example, if You have small values for "Half extinction distances" (Red 0.1,Green 4,Blue 5) in conjugation with a high sample area (compute from surface which is covered by SSS) will need around 12 GigaByte for the SSS computation the "Relative density of SSS samples" has also a influence here (the sample projectfile for the values above are from the report #0006174) Two examples for the last point Correspondending log entry (master.log) ---Information about SubSurfaceScattering for ---Project : "wizard_21test" ---Choreography : "Choreography1" ---SSS Figure : "Shortcut to Wizard" Group : "skin" ---SSS maxphotons : 141801 area: 46321.9 samplesarea: 3.06122 ---SSS Memory needed : 6 MegaByte ---SSS Figure : "Shortcut to Wizard" Group : "mund" ---SSS maxphotons : 1874 area: 3611.37 samplesarea: 0.519031 ---SSS Memory needed : 158 KiloByte ---SSS Figure : "Shortcut to Wizard" Group : "nippel" ---SSS maxphotons : 220 area: 94.1347 samplesarea: 2.34375 ---SSS Memory needed : 80 KiloByte Correspondending log entry (master.log) ---Information about SubSurfaceScattering for ---Project : "SkinTest4_RedSetToZero_timing" ---Choreography : "Choreography1" ---SSS Figure : "TestShape1" ---SSS maxphotons : 272485504 area: 108994 samplesarea: 2500 ---SSS Memory needed : 12 GigaByte Where the second example is from the #0006174 Quote
Admin Rodney Posted July 8, 2012 Admin Posted July 8, 2012 Um... Wow. - SSS can now be used also in materials This one alone should be awesomelyawesome. If this means what I think it does then we should be able to collect few prime SSS settings for use/reuse. Thanks Steffen for digging deeper into SSS! One question regarding the SSS memory notification: If the computer doesn't have enough memory does A:M's render just skip SSS? I assume A:M won't render until the requirement is lowered? Quote
itsjustme Posted July 8, 2012 Posted July 8, 2012 Great stuff, Steffen! Thanks for your hard work. Quote
John Bigboote Posted July 8, 2012 Posted July 8, 2012 Awesome! More great improvements to the SSS feature! Can I take this moment to ask... when using SSS in multipass, would it make the render faster if pass 2,3,4etc just 'borrowed' the calculations from pass1 instead of a fresh recalculation every time? Now that you have it going so fast- I suppose it does not matter. GREAT WORK STEFFEN! Quote
Developer yoda64 Posted July 8, 2012 Developer Posted July 8, 2012 One question regarding the SSS memory notification: If the computer doesn't have enough memory does A:M's render just skip SSS? I assume A:M won't render until the requirement is lowered? SSS is not skipped in this case , but the rendering will get very slow, because in this case the OS must start swapping . Quote
Developer yoda64 Posted July 8, 2012 Developer Posted July 8, 2012 Can I take this moment to ask... when using SSS in multipass, would it make the render faster if pass 2,3,4etc just 'borrowed' the calculations from pass1 instead of a fresh recalculation every time? SSS is only calculated at the first pass now and than used in the other passes too, so yes the rendering is faster for multipass Quote
Hash Fellow robcat2075 Posted July 8, 2012 Author Hash Fellow Posted July 8, 2012 Can I take this moment to ask... when using SSS in multipass, would it make the render faster if pass 2,3,4etc just 'borrowed' the calculations from pass1 instead of a fresh recalculation every time? SSS is only calculated at the first pass now and than used in the other passes too, so yes the rendering is faster for multipass And somehow the result of the first pass is pasted onto the surface of the other passes, so motion blur still looks right? Quote
Developer yoda64 Posted July 8, 2012 Developer Posted July 8, 2012 Can I take this moment to ask... when using SSS in multipass, would it make the render faster if pass 2,3,4etc just 'borrowed' the calculations from pass1 instead of a fresh recalculation every time? SSS is only calculated at the first pass now and than used in the other passes too, so yes the rendering is faster for multipass And somehow the result of the first pass is pasted onto the surface of the other passes, so motion blur still looks right? motion blur not tested yet , Your task :-) maybe , I have disable this speed up , when motion blur is in use . Needs test . multipass render times Quote
Hash Fellow robcat2075 Posted July 8, 2012 Author Hash Fellow Posted July 8, 2012 I guess SSS "sampling" isn't like AO sampling and can't be distributed among passes and get normal looking result? Quote
Recommended Posts
Join the conversation
You are posting as a guest. 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.