On 05/09/2025 22:15, William F Pokorny wrote:

> Thank you - especially for taking the time to add the extra switch. :-)

ho, yes. more easy than add/remove lines comments

> 
> Disclaimer. I'm no expert with the SSLT feature / code.

Me neither. I just wanted to explore this feature.


> 
> 0) The far side artefacts are always there for both the merge{} and the 
> prism{} no matter the things tried.
> 
> 1) I used only six digits of the coefficient value calculation, so the 
> first thing I tried was using the full double calculated value of 
> 0.5522847498307936 (a value accurate to maybe only about 7 or 8 
> significant digits in any case). No difference.
> 
> 2) I tried yuqk versions with all the solver improvements over-Ray 
> releases(a). The artefact becomes slightly larger with the better solvers.
> 
> (a) - Found too that yuqk change(s) after Nov 2021 (when yuqk was still 
> called povr) and all recent yuqk named versions, results in an infinite 
> parser hang any time global_settings{} uses subsurface{} and the scene 
> invokes ANY object - whether or not it is using SSLT... :-(
> 
> 3) I tried a limited number of different camera positions and the 
> prism{} specific artefact was always there.
> 
> 4) The far side artefacts can be reduced in size by reducing the 
> translucency via either the 'mm_per_unit' value or the per object 
> 'translucency' value. But, to my eye, the visual result is then not much 
> worth the cost of SSLT.

 From what I've read, undersampling can result in visual noise.



> As our documentation makes clear, the experimental SSLT feature is 
> there, but it's never been a polished implementation. For yuqk, it is a 
> feature I might delete.
> 
> For the next yuqk release - unless I find the time to debug and fix the 
> yuqk SSLT parser hang - I'll make the feature illegal to use with a 
> message like "The SSLT feature is currently broken in the yuqk fork."

Yes. it's a reasonable choice.
Good implementation seems very hard to do.




I've read several articles on this subject and it seems really
complicated. Very few rendering engines handle this capability correctly.

Some links :
— <https://en.wikipedia.org/wiki/Subsurface_scattering>
— 
<https://advances.realtimerendering.com/s2018/Efficient%20screen%20space%20subsurface%20scattering%20Siggraph%202018.pdf>
— 
<https://www.iryoku.com/separable-sss/downloads/Separable-Subsurface-Scattering.pdf>
— 
<https://agraphicsguynotes.com/posts/practical_tips_for_implementing_subsurface_scattering_in_a_ray_tracer/>
— ...






-- 
kurtz le pirate
compagnie de la banquise

Post a reply to this message