The documentation explains the rendering problem that happens when one
of the surfaces of the minuend in a difference operation is coincident
with one of the surfaces of the subtrahend.

I've been encountering a similar-looking rendering problem even when
there is no such coincidence.  In the scene attached below, I expected
the center of the image to be a green solid surface, not a speckled
"window" into the object's interior.

Question 1:  Is this a bug?

Question 2:  If this is not a bug but a problem in the scene file...
Suppose that Bar and Baz were written by different authors; which one of
them is responsible?  Was the author of Bar supposed to avoid coincident
surfaces, even though he was just unioning some untextured solid objects?
Or conversely, was the author of Baz supposed to perform an audit of the
structural details of the objects that he was differencing, just in case
one of them might have its own subcomponents that have coincidences?

I'm using 3.7, and I get the same result on Linux or Windows.

(See PNG in message with same subject, in povray.binaries.images.)

Post a reply to this message

Attachments:
Download 'us-ascii' (1 KB)

On 30-10-2018 4:58, Robert Munyer wrote:
> The documentation explains the rendering problem that happens when one
> of the surfaces of the minuend in a difference operation is coincident
> with one of the surfaces of the subtrahend.
> 
> I've been encountering a similar-looking rendering problem even when
> there is no such coincidence.  In the scene attached below, I expected
> the center of the image to be a green solid surface, not a speckled
> "window" into the object's interior.
> 
> Question 1:  Is this a bug?

No. It is not imho.

> 
> Question 2:  If this is not a bug but a problem in the scene file...
> Suppose that Bar and Baz were written by different authors; which one of
> them is responsible?  Was the author of Bar supposed to avoid coincident
> surfaces, even though he was just unioning some untextured solid objects?
> Or conversely, was the author of Baz supposed to perform an audit of the
> structural details of the objects that he was differencing, just in case
> one of them might have its own subcomponents that have coincidences?
> 

Bar is the offensive element with a coincident surface at z=0. 
Obviously, Baz is unable to difference that coincident surface from Foo, 
leaving a /hole/ (/not/ a difference surface you may have noticed). My 
experience has always been to avoid coincident surfaces wherever 
possible, especially in complex situations. I leave the technical 
background to my betters. ;-)

-- 
Thomas

Post a reply to this message

Am 30.10.2018 um 04:58 schrieb Robert Munyer:
> The documentation explains the rendering problem that happens when one
> of the surfaces of the minuend in a difference operation is coincident
> with one of the surfaces of the subtrahend.
> 
> I've been encountering a similar-looking rendering problem even when
> there is no such coincidence.  In the scene attached below, I expected
> the center of the image to be a green solid surface, not a speckled
> "window" into the object's interior.
> 
> Question 1:  Is this a bug?

No; it's a known issue that is fundamental to the way POV-Ray does 
constructive solid geometry.

> Question 2:  If this is not a bug but a problem in the scene file...
> Suppose that Bar and Baz were written by different authors; which one of
> them is responsible?  Was the author of Bar supposed to avoid coincident
> surfaces, even though he was just unioning some untextured solid objects?
> Or conversely, was the author of Baz supposed to perform an audit of the
> structural details of the objects that he was differencing, just in case
> one of them might have its own subcomponents that have coincidences?

That's really a legal question, and therefore outside the scope of these 
newsgroups; you better consult a lawyer about this. All I as a layman 
can say is that as far as I am aware, there is nothing intentionally 
inherent in POV-Ray or its terms of use that would imply one or the other.

Post a reply to this message

On 30-10-2018 10:56, clipka wrote:
> Am 30.10.2018 um 04:58 schrieb Robert Munyer:
>> The documentation explains the rendering problem that happens when one
>> of the surfaces of the minuend in a difference operation is coincident
>> with one of the surfaces of the subtrahend.
>>
>> I've been encountering a similar-looking rendering problem even when
>> there is no such coincidence.  In the scene attached below, I expected
>> the center of the image to be a green solid surface, not a speckled
>> "window" into the object's interior.
>>
>> Question 1:  Is this a bug?
> 
> No; it's a known issue that is fundamental to the way POV-Ray does 
> constructive solid geometry.
> 
>> Question 2:  If this is not a bug but a problem in the scene file...
>> Suppose that Bar and Baz were written by different authors; which one of
>> them is responsible?  Was the author of Bar supposed to avoid coincident
>> surfaces, even though he was just unioning some untextured solid objects?
>> Or conversely, was the author of Baz supposed to perform an audit of the
>> structural details of the objects that he was differencing, just in case
>> one of them might have its own subcomponents that have coincidences?
> 
> That's really a legal question, and therefore outside the scope of these 
> newsgroups; you better consult a lawyer about this. All I as a layman 
> can say is that as far as I am aware, there is nothing intentionally 
> inherent in POV-Ray or its terms of use that would imply one or the other.

LOL!
I had not even considered the /legal/ aspect of the question. I would 
consider Bar to be malignant and purposely inducing Baz into problems, 
while Baz has been too stupid or just too lazy to control the received code.

I want to see both in court your honour!

-- 
Thomas

Post a reply to this message

Le 18-10-29 à 23:58, Robert Munyer a écrit :
> The documentation explains the rendering problem that happens when one
> of the surfaces of the minuend in a difference operation is coincident
> with one of the surfaces of the subtrahend.
> 
> I've been encountering a similar-looking rendering problem even when
> there is no such coincidence.  In the scene attached below, I expected
> the center of the image to be a green solid surface, not a speckled
> "window" into the object's interior.
> 
> Question 1:  Is this a bug?
>

Coincident surfaces problems can happen whenever you have two or more 
surfaces that are at the same location.
It can come from two objects that touch each other.
It can show up in unions and merges.

It show more often in differences and intersections because, in the 
other cases, the affected surfaces are hidden unless you have at least 
one transparent object.

Solution : Always make sure that you don't have surfaces that just 
touch. If it happen, move one of the surfaces by a tiny amount.
This will solve your problem :
#declare Bar =
   union {
     // No more surface coincidences _within_ this union.
     box { <-.75, -.75, -2>, <.25, .25, 0.000001> }
     box { <-.25, -.25, -2>, <.75, .75, 0> }
     pigment { Green }
   }

as well as this :
#declare Bar =
   union {
     // No more surface coincidences _within_ this union.
     box { <-.75, -.75, -2>, <.25, .25, -0.000001> }
     box { <-.25, -.25, -2>, <.75, .75, 0> }
     pigment { Green }
   }

Post a reply to this message

I encounter the same problem often, with my river paddle-wheel steamboat
and other projects. Wished this could be solved somehow by the developers.

---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com

Post a reply to this message

Alain wrote:

> Coincident surfaces problems can happen whenever you have two or more
> surfaces that are at the same location.
> It can come from two objects that touch each other.
> It can show up in unions and merges.
>
> It show more often in differences and intersections because, in the
> other cases, the affected surfaces are hidden unless you have at least
> one transparent object.

Thank you, that's very helpful advice.

I'm trying to see if any other CSG-related programs have this problem.
I tried the three other CSG programs that happen to be installed on my
system.  I asked people at the local hackerspace who have other CSG
programs.  None of the other programs seem to have this problem.

Neither I nor any of the others had BRL-CAD, so when I have some time
I will download and try it.  It will be interesting to use a ray tracer
that's even older than POV-Ray!

To be clear...  There are two coincident-surfaces problems that affect
nearly all CSG programs, but this thread is about a different problem.

If two coincident surfaces have opposite orientation (i.e. one of
them is trying to show a surface whose interior side faces the camera,
and the other one is trying to show a surface whose exterior side faces
the camera) most CSG programs will render unintended geometry:

  difference {
    box { -1, 1 pigment { Red } }
    cylinder { -z, z, 0.5 pigment { Green } }
  }

If two coincident surfaces have the same orientation but different
texture, it's impossible to know what the author intended:

  union {
    box { -1, 1 pigment { Red } }
    box { -1, 1 pigment { Yellow } translate y }
  }

This thread is about a different case, in which the coincident surfaces
have the same orientation and the same texture.

> Solution : Always make sure that you don't have surfaces that just
> touch. If it happen, move one of the surfaces by a tiny amount.
>
> This will solve your problem :
> #declare Bar =
>    union {
>      // No more surface coincidences _within_ this union.
>      box { <-.75, -.75, -2>, <.25, .25, 0.000001> }
>      box { <-.25, -.25, -2>, <.75, .75, 0> }
>      pigment { Green }
>    }

Or you can refactor Bar so that it doesn't use CSG internally:

#declare Bar =
  prism {
    -8, 0, 8,
    <-1, -1>, <-1, -3>, < 3, -3>, < 3,  1>,
    < 1,  1>, < 1,  3>, <-3,  3>, <-3, -1>
    scale .25
    rotate 90 * x
    pigment { Green }
  }

Post a reply to this message

Am 03.11.2018 um 14:12 schrieb Robert Munyer:

> I'm trying to see if any other CSG-related programs have this problem.
> I tried the three other CSG programs that happen to be installed on my
> system.  I asked people at the local hackerspace who have other CSG
> programs.  None of the other programs seem to have this problem.

That's probably because CSG-capable programs usually come from the CAD 
modelling world, not the 3D rendering world.

POV-Ray has a bit of a handicap in that it isn't totally committed to 
solid geometry, and instead supports a random mix of patch and solid 
primitives.

As a consequence, it can't just use the "direction" of the surface to 
determine where the volume begins or where it ends; instead, it uses a 
separately defined notion of "insideness" of a given point.

So the case you describe does pretty much fall into POV-Ray's equivalent 
of this one:

> If two coincident surfaces have opposite orientation (i.e. one of
> them is trying to show a surface whose interior side faces the camera,
> and the other one is trying to show a surface whose exterior side faces
> the camera) most CSG programs will render unintended geometry:

Because POV-Ray doesn't distinguish surface orientation in its 
implementation of CSG.


I have toyed with some ideas of how to change that and do make use of 
surface orientation to address the issue at least for certain standard 
cases, but it would require some major changes, and my supply of 
king-size Round Tuits(TM) is running low, as always.

Post a reply to this message

Thank you for posting that explanation.

> I have toyed with some ideas of how to change that and do make use of
> surface orientation to address the issue at least for certain standard
> cases, but it would require some major changes, and my supply of
> king-size Round Tuits(TM) is running low, as always.

Here's something that you could do with a much smaller tuit:

Put a paraphrase of the words that you wrote here (or the words that
Alain wrote here) in the documentation, wherever the current wording
obscures or contradicts what you wrote here.

For example, these words in the documentation:

    In general we have to make the subtracted object a little bit
    larger in a CSG difference. We just have to look for coincident
    surfaces and increase the subtracted object appropriately to get
    rid of those surfaces.

are misleading; their suggested remedy of "increasing the subtracted
object" wouldn't help at all, in the situation being discussed here.

P.S.  I downloaded BRL-CAD, and learned just enough of it to model the
CSG shape from the top of this thread, and ray-trace it, and export it
as STL.  I'll attach a BRL-CAD geometry database (in human-readable .asc
form) below, in case anyone here wants to experiment with it.  baz.c is
the geometric shape, and baz.r is a red plastic object with that shape.

Using the database attached below:

$ PATH=/usr/brlcad/bin:$PATH
$
$ # deserialize the database
$ asc2g pov-csg-problem.asc p-c-p.g
$
$ # ray-trace the object
$ rt -a 0 -e 5.71 -o baz.png -p 30 -E 5.9 p-c-p.g baz.r
 [ output elided ]
$
$ # export the CSG shape as STL
$ g-stl -o baz.stl p-c-p.g baz.c
 {foo.s} - {bar1.s}
 {(foo.s - bar1.s)} - {bar2.s}
44 triangles written
$

Post a reply to this message

Attachments:
Download 'us-ascii' (1 KB)

On 2018-10-30 5:56 AM (-4), clipka wrote:
> Am 30.10.2018 um 04:58 schrieb Robert Munyer:
>>
>> Question 2:  If this is not a bug but a problem in the scene file...
>> Suppose that Bar and Baz were written by different authors; which one of
>> them is responsible?  Was the author of Bar supposed to avoid coincident
>> surfaces, even though he was just unioning some untextured solid objects?
>> Or conversely, was the author of Baz supposed to perform an audit of the
>> structural details of the objects that he was differencing, just in case
>> one of them might have its own subcomponents that have coincidences?

You should see the machinations I went through to avoid coincident 
surfaces in RoundEdge in the Object Collection.  Also in the Object 
Collection, the GemCuts user manual has a warning that setting objects 
(in contrast to gem objects) are not intended for use with transparent 
textures.  The reason is that I made no attempt to eliminate internal 
surfaces, but with that comes a high likelihood of hidden coincident 
surfaces.  Now you have me wondering if I should include a warning not 
to difference that Tiffany solitaire setting from... uh, a clay 
impression?  A Styrofoam box?

> That's really a legal question, and therefore outside the scope of these 
> newsgroups; you better consult a lawyer about this. All I as a layman 
> can say is that as far as I am aware, there is nothing intentionally 
> inherent in POV-Ray or its terms of use that would imply one or the other.

Object Collection submissions are under the LGPL license, and my other 
independent submissions are under the GPL.  I've also submitted 
modifications and supplements to POV-Ray distribution scene files, which 
are covered by Creative Commons.  All these licenses have explicit 
warranty disclaimers.  So, the user's problem, not mine.  :p

Post a reply to this message