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

On 23/02/2025 21:27, William F Pokorny wrote:

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

yes

> 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

Ho yes, I tried several inside_vector without further luck.





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

A very good point.
I also think the problem lies here



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

Here, the same things rendered with yuqk* :(






* : look in p.b.programming. I have strange errors with yuqk

-- 
kurtz le pirate
compagnie de la banquise

Post a reply to this message

Attachments:
Download 'screew_yuqk.png' (63 KB)

Preview of image 'screew_yuqk.png'

On 23/02/2025 22:17, William F Pokorny wrote:
> 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 }
> }


I rebuilt yuqk with the right option (THANKS Jr).


I went back to my 3.8 source code, added the right lines for version 
3.8.0-x.yuqk_a5c25dda and re-rendered. As expected, the names of my 
variables are accepted without any problem.

I'm happy.
Attached is a summary of this "magnificent" scene.


Do you see the problem ?
The issue I mentioned earlier has disappeared !


What is the relationship between the "--disable-no-lc-identifiers" and 
the difference  { } opération ?




A new leap into the 5th dimension :(





-- 
kurtz le pirate
compagnie de la banquise

Post a reply to this message

Attachments:
Download 'vis_yuqk_ok.png' (85 KB)

Preview of image 'vis_yuqk_ok.png'

On 2/24/25 10:32, kurtz le pirate wrote:
> Attached is a summary of this "magnificent" scene.
> 
> Do you see the problem ?
> The issue I mentioned earlier has disappeared !
> 
> What is the relationship between the "--disable-no-lc-identifiers" and 
> the difference  { } opération ?
> 
> A new leap into the 5th dimension 🙁
> 

"Don't worry, be happy?"

No idea why behavior might have changed. It' very unlikely to be related 
to "--disable-no-lc-identifiers", but stranger things have happened...

Bill (Already crazy) P.

Post a reply to this message