kurtz le pirate <kur### [at] freefr> wrote:
> 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://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

I love POV-Ray's SSLT. Any time I saw strange things occur... It was always
because the model was not physically correct... It's very slow, it's
unforgiving, but it might be one of the best around !

Post a reply to this message