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