Thank you for all your answers.



In fact, it's still and still the same problem of surfaces coincidence. 
Two boxes and four cylinders give too many cases to manage with epsilon 
translation in y.


And as BE says, this object is “too” simple :(
So I started working on a new geometry with no overlap.


<sdl>
// --- a quarter circle
#declare corner = difference {
  cylinder { <0, -H, 0>, <0, 0, 0>, R }
  plane { z,0 }
  plane { x, 0 }
  }


merge {
   // central box
   box { <-S+R, -H, -S+R>, <+S-R, 0, +S-R> }

   // left/right box
   box { <-S+R, -H, -S>, <S-R, 0, -S+R> }
   box { <-S+R, -H, S-R>, <S-R, 0, S> }

   // front/rear box
   box { <S, -H, -S+R>, <S-R, 0, S-R> }
   box { <-S, -H, -S+R>, <-S+R, 0, S-R> }

   // corners
   object { corner translate <+(S-R), 0, +(S-R)> }
   object { corner scale <-1,1,1> translate <-(S-R), 0, +(S-R)> }
   object { corner scale <1,1,-1> translate <+(S-R), 0, -(S-R)> }
   object { corner scale <-1,1,-1> translate <-(S-R), 0, -(S-R)> }

   }
</sdl>


Now everything seems fine.
I can restart my tests with SSS.



-- 
kurtz le pirate
compagnie de la banquise

Post a reply to this message

On 9/2/25 03:09, kurtz le pirate wrote:
> merge {
...
>    }
> 
> 
> Now everything seems fine.
> I can restart my tests with SSS.

FWIW. An option, which might be faster than your merge{}, would be to 
use a bezier_spline prism{}.

Bill P.

//---
#version 3.8;
global_settings { assumed_gamma 1 }
#declare Grey50 = srgb <0.5,0.5,0.5>;
background { Grey50 }
#declare Camera00 = camera {
     perspective
     location <3,3,-3.001>
     sky y
     angle 35
     right x*(image_width/image_height)
     look_at <0,0,0>
}
#declare White = srgb <1,1,1>;
#declare Light00 = light_source { <50,150,-250>, White }
#declare Red = srgb <1,0,0>;
#declare CylinderX = cylinder { -1.1*x, 1.1*x, 0.01 pigment { Red } }
#declare Green = srgb <0,1,0>;
#declare CylinderY = cylinder { -1.1*y, 1.1*y, 0.01 pigment { Green } }
#declare Blue = srgb <0,0,1>;
#declare CylinderZ = cylinder { -1.1*z, 1.1*z, 0.01 pigment { Blue } }
#declare Orange = srgb <1,0.50196,0>;

//---
#declare Bot    = 0.0;           // Base of prism linear sweep
#declare Top    = 0.2;           // Top of prism linear sweep
#declare Frac   = 0.2;           // portion of +-1.0 edges rounded
#declare Shft   = 1.0-Frac;      // Normalize to 1x1 range
#declare ShftUR = <+Shft,+Shft>; // Shift up and right
#declare ShftUL = <-Shft,+Shft>; // Shift up and left
#declare ShftLL = <-Shft,-Shft>; // Shift lower and left
#declare ShftLR = <+Shft,-Shft>; // Shift lower and right
#declare Prism00 = prism {
     bezier_spline
     linear_sweep
     Bot, Top, 32,
     <1,0>*Frac+ShftUR,<1,0.552285>*Frac+ShftUR,
     <0.552285,1>*Frac+ShftUR,<0,1>*Frac+ShftUR,

     <+Shft,1>,<+Shft+Shft/3,1>,<-Shft+Shft/3,1>,<-Shft,1>,

     <0,1>*Frac+ShftUL,<-0.552285,1>*Frac+ShftUL,
     <-1,0.552285>*Frac+ShftUL,<-1,0>*Frac+ShftUL,

     <-1,+Shft>,<-1,+Shft-Shft/3>,<-1,-Shft+Shft/3>,<-1,-Shft>,

     <-1,0>*Frac+ShftLL,<-1,-0.552285>*Frac+ShftLL,
     <-0.552285,-1>*Frac+ShftLL,<0,-1>*Frac+ShftLL,

     <-Shft,-1>,<-Shft+Shft/3,-1>,<+Shft-Shft/3,-1>,<+Shft,-1>,

     <0,-1>*Frac+ShftLR,<0.552285,-1>*Frac+ShftLR,
     <1,-0.552285>*Frac+ShftLR,<1,0>*Frac+ShftLR

     <+1,-Shft>,<+1,-Shft+Shft/3>,<+1,+Shft-Shft/3>,<+1,+Shft>

     pigment { Orange }
}
#declare PrismCylinder = prism {  // Bezier spline cylinder approx
     bezier_spline
     linear_sweep
     Bot, Top, 16,
     <1,0>,<1,0.552285>,<0.552285,1>,<0,1>
     <0,1>,<-0.552285,1>,<-1,0.552285>,<-1,0>
     <-1,0>,<-1,-0.552285>,<-0.552285,-1>,<0,-1>
     <0,-1>,<0.552285,-1>,<1,-0.552285>,<1,0>
     pigment { Orange }
}

//--- scene ---
     camera { Camera00 }
     light_source { Light00 }
     object { CylinderX }
     object { CylinderY }
     object { CylinderZ }
     object { Prism00 }
//  object { PrismCylinder }  // Bezier spline cylinder approx
//---

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

> FWIW. An option, which might be faster than your merge{}, would be to
> use a bezier_spline prism{}.

Dealing with chaos here, so I haven't thought this completely through...

But perhaps he could also use round box function / insert menu macro with
intersection, or my "rounded_box" (apparently unposted) variant with a very tiny
radius for the 2nd radius.

- BE

Post a reply to this message

On 9/3/25 14:23, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>> FWIW. An option, which might be faster than your merge{}, would be to
>> use a bezier_spline prism{}.
> 
> Dealing with chaos here, so I haven't thought this completely through...
> 
> But perhaps he could also use round box function / insert menu macro with
> intersection, or my "rounded_box" (apparently unposted) variant with a very tiny
> radius for the 2nd radius.
> 

Maybe... I thought too about the inbuilt f_rounded_box() function as an 
iso briefly, but to get the straight vertical sides I think we'd have to 
intersect with more or less the same corner shapes / box container being 
used in posted merge{}. Perhaps we could build up the isosurface with 
inbuilt, function similar shapes, matching what is in the merge. Whether 
that would faster than the merge{}, I don't know.

Bill P.

Post a reply to this message

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] 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