 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 03/09/2025 19:24, William F Pokorny wrote:
>
> FWIW. An option, which might be faster than your merge{}, would be to
> use a bezier_spline prism{}.
>
> ...
> ...
Thanks Bill for your bezier_spline prism suggestion.
But it seems that there are also issues related to surface overlap, or
the artifacts come only from the use of subsurface scattering ?
(still experimental, i know)
--
kurtz le pirate
compagnie de la banquise
Post a reply to this message
Attachments:
Download 'sss02.png' (48 KB)
Preview of image 'sss02.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/4/25 10:51, kurtz le pirate wrote:
> Thanks Bill for your bezier_spline prism suggestion.
> But it seems that there are also issues related to surface overlap, or
> the artifacts come only from the use of subsurface scattering ?
> (still experimental, i know)
Thanks for posting your SSS result.
The far edge from the camera looks like artefacts I've seen the SSS
feature. My play with it (years ago) struggled where camera rays
traveled short distances within a shape.
The artefact in the lower right is new to me - a different look.
What version of POV-Ray are you using?
Did you see similar results with your merge{} of shapes?
I'd like to play with your scene (to the degree I can on my little
machine), if you're willing to post it.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 05/09/2025 00:31, William F Pokorny wrote:
> On 9/4/25 10:51, kurtz le pirate wrote:
>> Thanks Bill for your bezier_spline prism suggestion.
>> But it seems that there are also issues related to surface overlap, or
>> the artifacts come only from the use of subsurface scattering ?
>> (still experimental, i know)
>
> Thanks for posting your SSS result.
>
> The far edge from the camera looks like artefacts I've seen the SSS
> feature. My play with it (years ago) struggled where camera rays
> traveled short distances within a shape.
>
> The artefact in the lower right is new to me - a different look.
>
> What version of POV-Ray are you using?
>
> Did you see similar results with your merge{} of shapes?
>
> I'd like to play with your scene (to the degree I can on my little
> machine), if you're willing to post it.
With my merged shape, i have no artifact in the lower right.
My code is attached. Play wit it !
You can see differences with useWFPObject = true or false
--
kurtz le pirate
compagnie de la banquise
Post a reply to this message
Attachments:
Download 'sss_pub.tar.gz' (3 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/5/25 04:31, kurtz le pirate wrote:
> With my merged shape, i have no artifact in the lower right.
>
> My code is attached. Play wit it !
>
> You can see differences with useWFPObject = true or false
Thank you - especially for taking the time to add the extra switch. :-)
I believe the short of it is that the corner rounding with the bezier
spline is a approximation of what the equivalent cylinder radius is.
Meaning there is tiny, but real, relative, discontinuity where the
straight segments join the rounded ones. The SSLT feature doesn't like
it in a way similar to how it doesn't like other 'tight' features /
paths through the object.
---
More detail.
Disclaimer. I'm no expert with the SSLT feature / code.
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.
5) Played a little with adding a normal{} block as a way to mitigate the
artefacts, but it didn't seem to change the SSLT result at all. Might be
the perturbed normals are ignored by SSLT; Anyone know for sure?
---
FWIW.
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."
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
kurtz le pirate <kur### [at] free fr> 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
|
|
| |
| |
|
|
|
|
| |
|
|
