Hi,


In the attached image (this is a view from below).

In the center, the object built from the union of a cylinder and a mesh.

On the right, the same object “cut” at the base by a plane
difference {
  object { Screw }
  plane { y,0 }
  }



And then, as you can see, something “weird” happens.

If I make the difference with a box, it's the same thing.
And, if instead of “cutting” at the bottom, I cut at the top, the same 
thing happens. It can't be a problem of surface coincidence. The values 
are quite different, in fact.


Do you have any ideas for solving this issue ?



nb: the vertical black line with the balls is simply  gauge to check the 
screw pitch and has nothing to do with the problem.

-- 
kurtz le pirate
compagnie de la banquise

Post a reply to this message

Attachments:
Download 'issue.jpg' (61 KB)

Preview of image 'issue.jpg'

Le 23/02/2025 à 11:17, kurtz le pirate a écrit :
> 
> Hi,
> 
> 
> In the attached image (this is a view from below).
> 
> In the center, the object built from the union of a cylinder and a mesh.
> 
> On the right, the same object “cut” at the base by a plane
> difference {
>   object { Screw }
>   plane { y,0 }
>   }
> 
> 
> 
> And then, as you can see, something “weird” happens.
> 
> If I make the difference with a box, it's the same thing.
> And, if instead of “cutting” at the bottom, I cut at the top, the same 
> thing happens. It can't be a problem of surface coincidence. The values 
> are quite different, in fact.
> 
> 
> Do you have any ideas for solving this issue ?
> 
> 
> 
> nb: the vertical black line with the balls is simply  gauge to check the 
> screw pitch and has nothing to do with the problem.
> 
Bonjour/Hello
When you try to make a difference or merge CSG operation with isosurface 
objects, you should use the "max trace 'intersections number'" (to write 
in the isosurface statement at the end ideally) keyword so POVRay 
doesn't stop at the first collision between rays and the isosurface 
object. So far, I don't know if you used the max_trace keyword because 
we don't have all the code.

Post a reply to this message

On 2/23/25 05:17, kurtz le pirate wrote:
> Do you have any ideas for solving this issue ?

What version of POV-Ray are you using? There were v3.8 development 
versions over time with difference issues.

If not a problematic version of POV-Ray, I'd bet next on something with 
the mesh, but...?

I tried a simple cylinder scene and things look OK test one each of the 
v3.7 and v3.8 compiles I have in hand.

//...
#declare Cyl00 = cylinder {
     <0,-0.1,0>, <0,1,0>, 0.2
     pigment { rgb <0.3,0.5,0.6> }
     finish { emission 0.2 }
}

difference {
   object { Cyl00 translate <-0.7,0,0> }
   plane { y,0 }
   cutaway_textures
}

object { Cyl00 }
//...

Bill P.

Post a reply to this message

Attachments:
Download 'tmp38.png' (28 KB)

Preview of image 'tmp38.png'

On 23/02/2025 11:44, antoine wrote:

> Bonjour/Hello
> When you try to make a difference or merge CSG operation with isosurface 
> objects, you should use the "max trace 'intersections number'" (to write 
> in the isosurface statement at the end ideally) keyword so POVRay 
> doesn't stop at the first collision between rays and the isosurface 
> object. So far, I don't know if you used the max_trace keyword because 
> we don't have all the code.

Isosurface ?
There is no isosurface here ;)






-- 
kurtz le pirate
compagnie de la banquise

Post a reply to this message

On 23/02/2025 13:36, William F Pokorny wrote:
> On 2/23/25 05:17, kurtz le pirate wrote:
>> Do you have any ideas for solving this issue ?
> 
> What version of POV-Ray are you using? There were v3.8 development 
> versions over time with difference issues.


Persistence of Vision(tm) Ray Tracer Version 3.8.0-beta.2.unofficial (
Compiler: Apple LLVM 12.0.5 (clang-1205.0.22.11))


> If not a problematic version of POV-Ray, I'd bet next on something with 
> the mesh, but...?

Yes, me too
But the mesh is simple "concatenation" of triangles.

The max/min values off the mesh are :
Max = < 7.00, 31.00, 7.00>
Min = <-7.00, -1.00, -7.00>

These values are consistent with the calculations and the drawing.

No point of the triangles has a value greater than the cylinder 
containing the mesh



> I tried a simple cylinder scene and things look OK test one each of the 
> v3.7 and v3.8 compiles I have in hand.
> 
> //...
> #declare Cyl00 = cylinder {
>      <0,-0.1,0>, <0,1,0>, 0.2
>      pigment { rgb <0.3,0.5,0.6> }
>      finish { emission 0.2 }
> }
> 
> difference {
>    object { Cyl00 translate <-0.7,0,0> }
>    plane { y,0 }
>    cutaway_textures
> }
> 
> object { Cyl00 }
> //...
> 
> Bill P.

Yes, with simple objects, no issue.

I made others tests. The base object ranges from -1 to 31.
If I try with another y value (say 5) i get the same issue at y = 5.0 
has you can see.

I also added the cylinder object limits.

I'm still trying to figure out what's so special about this mesh ...





-- 
kurtz le pirate
compagnie de la banquise

Post a reply to this message

Attachments:
Download 'issue2.jpg' (62 KB)

Preview of image 'issue2.jpg'

On 2/23/25 09:30, kurtz le pirate wrote:
>> If not a problematic version of POV-Ray, I'd bet next on something 
>> with the mesh, but...?
> 
> Yes, me too
> But the mesh is simple "concatenation" of triangles.
> 
> The max/min values off the mesh are :
> Max = < 7.00, 31.00, 7.00>
> Min = <-7.00, -1.00, -7.00>
> 
> These values are consistent with the calculations and the drawing.
> 
> No point of the triangles has a value greater than the cylinder 
> containing the mesh

I'll take you to mean no point of the triangles has a value >= a surface 
of the cylinder containing the mesh.

And, you've specified an inside_vector <> in your mesh definition? One 
NOT axis aligned (<0,0,1>) as recommended by our documentation at:

   https://wiki.povray.org/content/Reference:Mesh#Solid_Mesh

Use something more random and unlikely to run near parallel with any 
triangle's surface in your mesh (*) - there are some epsilon tolerance 
values when testing whether inside the mesh.

Bill P.

(*)- There is too a narrow / unlikely potential bug when translating a 
mesh with an originally valid inside_vector, which is fixed in the yuqk 
fork.

Post a reply to this message

On 2/23/25 15:27, William F Pokorny wrote:
> If not a problematic version of POV-Ray, I'd bet next on something with 
> the mesh, but...?

Another upfront question is: Are you sure the mesh is really closed?

The 'Solid' part of Constructive Solid Geometry is often important - 
though you can get away with quite a bit in practice.

And, have you tried an intersection{} instead?

intersection {
   object { Screw }
   plane { -y, 0 }
}

Bill P.

Post a reply to this message