Hello,

The holidays are over. I've started a new project... which has me 
confused. I don't understand POV's behavior.


The attached image illustrates the issue well. Both objects are defined 
in the same way, but one is a union{} (magenta) and the other is a 
merge{} (cyan).

It's a very very simple object: two boxes and four cylinders.


So, why le merged object (in cyan) show a hole ?


<sdl>

#declare S = 11.00;
#declare R = 3.00;
#declare H = 0.50;

#declare corner = cylinder { <0, -H, 0>, <0, 0, 0>, R }

merge or union
   {
   box { <-S+R, -H, -S>, <+S-R, 0, +S> }
   box { <-S, -H, -S+R>, <+S, 0, +S-R> }

   object { corner translate <+(S-R), 0, +(S-R)> }
   object { corner translate <-(S-R), 0, +(S-R)> }
   object { corner translate <+(S-R), 0, -(S-R)> }
   object { corner translate <-(S-R), 0, -(S-R)> }
   }

</sdl>

For the rendering, I added a translate 15*y for the cyan object but the 
problem is not here.



If you have an idea...
Regards



ps : actually, I'm trying to understand how subsurface scattering works, 
and I've already noticed that this feature requires merge{} because 
union{} don't work, certainly due to surface coincidence.



-- 
kurtz le pirate
compagnie de la banquise

Post a reply to this message

Attachments:
Download 'bug.png' (39 KB)

Preview of image 'bug.png'

Le 2025-09-01 à 11:54, kurtz le pirate a écrit :
> 
> Hello,
> 
> The holidays are over. I've started a new project... which has me 
> confused. I don't understand POV's behavior.
> 
> 
> The attached image illustrates the issue well. Both objects are defined 
> in the same way, but one is a union{} (magenta) and the other is a 
> merge{} (cyan).
> 
> It's a very very simple object: two boxes and four cylinders.
> 
> 
> So, why le merged object (in cyan) show a hole ?
> 
> 
> <sdl>
> 
> #declare S = 11.00;
> #declare R = 3.00;
> #declare H = 0.50;
> 
> #declare corner = cylinder { <0, -H, 0>, <0, 0, 0>, R }
> 
> merge or union
>    {
>    box { <-S+R, -H, -S>, <+S-R, 0, +S> }
>    box { <-S, -H, -S+R>, <+S, 0, +S-R> }
> 
>    object { corner translate <+(S-R), 0, +(S-R)> }
>    object { corner translate <-(S-R), 0, +(S-R)> }
>    object { corner translate <+(S-R), 0, -(S-R)> }
>    object { corner translate <-(S-R), 0, -(S-R)> }
>    }
> 
> </sdl>
> 
> For the rendering, I added a translate 15*y for the cyan object but the 
> problem is not here.
> 
> 
> 
> If you have an idea...
> Regards
> 
> 
> 
> ps : actually, I'm trying to understand how subsurface scattering works, 
> and I've already noticed that this feature requires merge{} because 
> union{} don't work, certainly due to surface coincidence.
> 
> 
> 

The noise in the hole lead me to think that it may be a coincident 
surface issue.
The merge remove internal surfaces. When two surfaces are in the exact 
same location, you get all sort of glitches as the program can't tell 
witch one is inside and need to get removed.
Try moving one of the box up or down by a very small amount, like :
translate y*10^-7

Does that help ?

Post a reply to this message

kurtz le pirate <kur### [at] freefr> wrote:

> The attached image illustrates the issue well. Both objects are defined
> in the same way, but one is a union{} (magenta) and the other is a
> merge{} (cyan).
>
> It's a very very simple object: two boxes and four cylinders.

And that's the root of the problem:  it's TOO simple.

Remove the overlap of the two boxes by defining one central box, and adding FOUR
"leaves" or "wings" filling in the edges between the cylinder "corners".

Then I think it should work . . .

However, you may need to convert your corners from full cylinders to "pie
slices" by CSG - either home-rolled, or using Lohmueller's macro, which I
believe is in the drop-down insert menu as "segment of a cylinder"

-BE

(Perhaps do some other simple overlap tests to demonstrate what happens.)

Post a reply to this message

Le 2025-09-01 à 13:12, Bald Eagle a écrit :
> kurtz le pirate <kur### [at] freefr> wrote:
> 
>> The attached image illustrates the issue well. Both objects are defined
>> in the same way, but one is a union{} (magenta) and the other is a
>> merge{} (cyan).
>>
>> It's a very very simple object: two boxes and four cylinders.
> 
> And that's the root of the problem:  it's TOO simple.
> 
> Remove the overlap of the two boxes by defining one central box, and adding FOUR
> "leaves" or "wings" filling in the edges between the cylinder "corners".
> 
> Then I think it should work . . .
> 
> However, you may need to convert your corners from full cylinders to "pie
> slices" by CSG - either home-rolled, or using Lohmueller's macro, which I
> believe is in the drop-down insert menu as "segment of a cylinder"
> 
> -BE
> 
> (Perhaps do some other simple overlap tests to demonstrate what happens.)

For the overlap test, just make one of the boxes a different colour in 
the union case. That will show the coincident surfaces.

union
   {
   box { <-S+R, -H, -S>, <+S-R, 0, +S> pigment{rgb<0,1,0>}}
   box { <-S, -H, -S+R>, <+S, 0, +S-R> pigment{rgb<1,0,0>}}

   object { corner translate <+(S-R), 0, +(S-R)> pigment{rgb<0,0,1>}}
   object { corner translate <-(S-R), 0, +(S-R)> pigment{rgb<0,0,1>}}
   object { corner translate <+(S-R), 0, -(S-R)> pigment{rgb<0,0,1>}}
   object { corner translate <-(S-R), 0, -(S-R)> pigment{rgb<0,0,1>}}
   }

This will make all coincident surfaces obvious.

Post a reply to this message

On 2025-09-01 12:23 (-4), Alain Martel wrote:
> Le 2025-09-01 à 11:54, kurtz le pirate a écrit :
>>
>> #declare corner = cylinder { <0, -H, 0>, <0, 0, 0>, R }
>>
>> merge or union
>>    {
>>    box { <-S+R, -H, -S>, <+S-R, 0, +S> }
>>    box { <-S, -H, -S+R>, <+S, 0, +S-R> }
>>
>>    object { corner translate <+(S-R), 0, +(S-R)> }
>>    object { corner translate <-(S-R), 0, +(S-R)> }
>>    object { corner translate <+(S-R), 0, -(S-R)> }
>>    object { corner translate <-(S-R), 0, -(S-R)> }
>>    }
> 
> The noise in the hole lead me to think that it may be a coincident
> surface issue.
> The merge remove internal surfaces. When two surfaces are in the exact
> same location, you get all sort of glitches as the program can't tell
> witch one is inside and need to get removed.
> Try moving one of the box up or down by a very small amount, like :
> translate y*10^-7
> 
> Does that help ?

In fact, both boxes will need to be moved (one up, and one down),
because they also share coincident surfaces with the four cylinders.

P.S.  There is a typo: y*10^-7 should be y*10e-7.

Post a reply to this message

On 2025-09-01 13:12 (-4), Bald Eagle wrote:
> kurtz le pirate <kur### [at] freefr> wrote:
> 
>> The attached image illustrates the issue well. Both objects are defined
>> in the same way, but one is a union{} (magenta) and the other is a
>> merge{} (cyan).
>>
>> It's a very very simple object: two boxes and four cylinders.
> 
> And that's the root of the problem:  it's TOO simple.
> 
> Remove the overlap of the two boxes by defining one central box, and adding FOUR
> "leaves" or "wings" filling in the edges between the cylinder "corners".
> 
> Then I think it should work . . .
> 
> However, you may need to convert your corners from full cylinders to "pie
> slices" by CSG - either home-rolled, or using Lohmueller's macro, which I
> believe is in the drop-down insert menu as "segment of a cylinder"

I'm not sure this will solve the problem; it may just result in a
different set of coincident surfaces.

If you want to see what I went through to build this shape without
coincident surfaces, take a look at macro RE__box_axis() in this file:
  https://github.com/CousinRicky/POV-RoundEdge/blob/main/roundedge.inc

Post a reply to this message

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