Due to recent discussions in the pov4 forum, I decided to document what 
I believe are issues with disc{} shape's CSG results. Ref:

https://news.povray.org/povray.pov4.discussion.general/thread/%3C68c8a619%241%40news.povray.org%3E/

See the attached image and scene files.

The top row a disc{} is being intersected with a sphere{}. In the second 
row a roughly equivalent polygon{} is intersected in the same fashion.

I believe the disc{} results are correct only in the second and last 
columns. The polygon row of intersections I believe is OK(*).

Bill P.

(*) Image results use v3.8 beta 2. The normal in yuqk for the polygon{} 
is flipped so +z is the outside texture.

Post a reply to this message

Attachments:
Download 'discoddnesscsg_v38.png' (52 KB) Download 'discoddnesscsg.pov.txt' (4 KB)

Preview of image 'discoddnesscsg_v38.png'

William F Pokorny <ano### [at] anonymousorg> wrote:

> The top row a disc{} is being intersected with a sphere{}. In the second
> row a roughly equivalent polygon{} is intersected in the same fashion.
>
> I believe the disc{} results are correct only in the second and last
> columns. The polygon row of intersections I believe is OK(*).

So, I need to question the whole top row.
I refer to the disc {} in its form with a hole using the mathematically accurate
term "annulus".

It's interesting that the annulus gets rendered with what appears to be a
bounding box with the sphere texture included.  I'm assuming that's part of the
erroneous behaviour - only the annulus ought to be rendered.

1. If column 2 and 5 both show the sphere, then why doesn't column 1 show the
lower part of the sphere?

(bounding boxes and perhaps some method of showing the inside () results of the
disc might help. VRandInObject or whatever it's called, or media)

2. Confused about why inverse shows so much of the sphere.
Does the disc act like a half-infinite cylinder?
Does inverse now cause it to be  NOT(half-infinite cylinder)?
Because even that doesn't seem like the correct result to me.

3. I guess it's wrong, but consistent with render 1.

4. perhaps this might be correct, if we're considering the disc/annulus to
technically have an inside () ?  Though I would expect for there to not be
anything, since the annulus surface is outside/tangent to the sphere

5.  No idea why you think that's correct, since there's now no overlap, unless
we're somehow considering the annulus to be some form of plane / half-space
object.  But then that leaves me confused about the rest of the renders in that
row.

I am in full agreement about the bottom row.

Suggest:
0. show bounding boxes and insidedness tests for the annulus.
1. apply an inside_texture to the sphere
2. use a sphere with a negative radius
3. use sphere {inverse}
4. use both inverse
5. make the major and minor radii of the annulus equal.

6. refer to my Boolean operations render, and see if that inspires any
additional experiments - my subconscious tells me that using that as a guide to
construct formalisms for what we're doing with objects and CSG (and using very
accurate, formal terminology apart from what we use in SDL) might help us
unravel what our less rigorous discussions may be hiding from us.

https://news.povray.org/povray.documentation.inbuilt/thread/%3Cweb.68573b7934ec28cb1f9dae3025979125%40news.povray.org%3
E/

"Since POV-Ray does not implement regularized Boolean operations (i.e., union,
intersection and difference are done as conventional set operations)"
(bottom of page)
https://pages.mtu.edu/~shene/COURSES/cs3621/LAB/povray/csg.html

P.S. As I was letting Second Coffee percolate into my blood stream this morning,
I was mixing thoughts about scene experiments, and I recently tried to render a
cone (a real, mathematical "double-cone") as an isosurface and had an issue,
until I reformulated how I was doing it to avoid division-by-zero.

Could you (someone) also render a cone {} with one radius positive, and the
other radius the unary inverse?  Use inside_texture and repeat CSG experiments.

Thanks,

- BW

Post a reply to this message

On 9/24/25 09:40, Bald Eagle wrote:
> So, I need to question the whole top row.
> I refer to the disc {} in its form with a hole using the mathematically accurate
> term "annulus".

I think the answer to most (all?) of your questions about the disc is 
the inside test is supposed to be equivalent to a plane{}'s inside test 
using the disc{}'s normal.

In yuqk I'm leaning heavily toward changing the disc{} to a patch object 
with an inside test that always returns false. To fix it, I suspect I'd 
have add internal dual cylinder bounding, but cost wise this will be not 
much different than a CSG difference with two cylinders...

FYI. You are correct the issue in v3.8 beta2 is bounding related. 
Attached an image rendered with yuqk using the '-b' flag to turn 
bounding off. The yuqk fork turns bounding 'completely' off with '-b' 
where v3.7 and v3.8 made code changes which pushed the last level of 
bounding for shapes outside the +-b flag's control(*). The yuqk fork has 
restored the v3.6 and prior behavior - and the restoration is certainly 
helpful here for debugging.

(*) - The change offered a performance optimization in some situations.

---

Ah, I see the cone is doing something weird where the two radii are 
negative. We should probably just not allow negative radii arguments in 
the parser - for any shape.

Bill P.

Aside 1: Long on my todo list is breaking apart the cylinder and cone 
code. Today it's all munged together making both slower and more complex 
than they need be.

Aside 2: clipka fixed something with the cone behavior (my memory 
otherwise fails) in v3.8. I expect v3.7 cone behavior is different in 
some aspect.

Post a reply to this message

Attachments:
Download 'discoddnessnoboundingcsg_yuqk.png' (58 KB) Download 'coneoddnesscsg_v38.png' (63 KB)

Preview of image 'discoddnessnoboundingcsg_yuqk.png'

Preview of image 'coneoddnesscsg_v38.png'

William F Pokorny <ano### [at] anonymousorg> wrote:

Nice renders.  These are a great starting point for a debugging toolkit, as well
as what could be some interesting extra documentation.

> Ah, I see the cone is doing something weird where the two radii are
> negative. We should probably just not allow negative radii arguments in
> the parser - for any shape.

What I meant, if you misunderstood, was to have one side be radius r, and the
other side be radius -r, so that it would make a "double-cone".

> Bill P.
>
> Aside 1: Long on my todo list is breaking apart the cylinder and cone
> code. Today it's all munged together making both slower and more complex
> than they need be.

clipka at one time said that the cylinder is just a cone with 2 equal end radii

> Aside 2: clipka fixed something with the cone behavior (my memory
> otherwise fails) in v3.8. I expect v3.7 cone behavior is different in
> some aspect.

It would be great if someone could hunt down the readme for 3.8 to see if that's
mentioned.  Are there any comments in source?

- bw

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

> In yuqk I'm leaning heavily toward changing the disc{} to a patch object
> with an inside test that always returns false. To fix it, I suspect I'd
> have add internal dual cylinder bounding, but cost wise this will be not
> much different than a CSG difference with two cylinders...

I would say that that makes sense.
As I have discussed with jr, and perhaps brought up in other posts, I would like
to have default values for things like the disc radii and surface normal if they
are not provided.   That might be a parser thing in addition to a .cpp thing.

Useful would be a swept annulus - a tube {}
Simply because it seems to be a common shape and it can be cumbersome if one has
a lot of them to make - especially for a newbie.

One of the things that I have read about in CS courses, and elsewhere, is that
they have that "regularized Boolean" variant, which I think we could immensely
benefit from - given that it would get rid of the residual coincident surface
problem when doing differences.

Alternately, would be some hierarchical CSG logic, whereby the last object
specified in any given CSG operation takes precedence.  I guess it would be sort
of like a z-buffer for CSG.  It's also how I code differences in my editor - the
differencing objects get indented after the parent object.  So, in a coincident
surface contest, the parent object should always lose.

Getting better at reading and interpreting the source, though I don't see the
big picture in terms of information flow.

-bw

Post a reply to this message

On 9/24/25 15:46, Bald Eagle wrote:
> What I meant, if you misunderstood, was to have one side be radius r, and the
> other side be radius -r, so that it would make a "double-cone".

Ah, yes, the double cone looks to work fine.

On the cone fix all I could find was a fix Chris implemented for v3.7 
which wasn't in v3.6. For v3.8 there is some uv mapping stuff added and 
then removed by clipka where others were involved. So... It might just 
be my failing head getting things mixed up. :-)

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 9/24/25 15:46, Bald Eagle wrote:
> > What I meant, if you misunderstood, was to have one side be radius r, and the
> > other side be radius -r, so that it would make a "double-cone".
>
> Ah, yes, the double cone looks to work fine.

Well...  sorta.

I was actually wondering if the normal flipped, which apparently it used to:

https://news.povray.org/povray.general/thread/%3Cweb.58228e15512a2627116828db0%40news.povray.org%3E/?mtop=412640

"Note : a cone can take a negative radius. In this case, you'll get a
double cone. You can try this :
cone{2*x, 2, -2*x, -2 pigment{rgb 1} inside_texture{pigment{rgb<0,0,1>}}}
Yes, the left part IS blue."

And that's why I think that allowing the negative radius should be kept, and
perhaps even enhanced. *

I tried searching for documentation instances for "negative radius" but didn't
find much - but I seem to remember notes to the effect that the normal would be
flipped.  torus?  sphere?

* What I'm currently thinking about is whether there should be some mechanism
for "inside-out" shapes to be functionally equivalent to _inverse_.
So maybe in regular mode, the negative radius just flips the normal, but perhaps
with an additional keyword, any inside-out part would actually be inverted.

Which also had me wondering what other shapes we can cleverly play with using
negative values.

- bw

Post a reply to this message

On 9/24/25 18:12, William F Pokorny wrote:
>> What I meant, if you misunderstood, was to have one side be radius r, 
>> and the
>> other side be radius -r, so that it would make a "double-cone".
> 
> Ah, yes, the double cone looks to work fine.

Blast, it doesn't work for all +- values.  Let me see if I can figure 
out why not.

Started to look at allowing both values to be negative and in testing 
that potential change I found not all +- -+ radii values work for 
getting a double cone.

Saw your other post on normal changes. I've not seen that in v3.8+, but 
who knows. Maybe it worked at some point as you suggested.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

> Blast, it doesn't work for all +- values.  Let me see if I can figure
> out why not.

Whoa.  I did not expect that.
Looks like there's some kind of clipping going on with the bounding.

- bw


#version 3.8;
global_settings {
 assumed_gamma 1.0
}

#declare E = 0.000001;

#declare Zoom = 14; //60;
camera {
 orthographic
 location <0, 0, -10>
 right    x*image_width/Zoom
 up       y*image_height/Zoom
 look_at  <0, 0, 0>
}

light_source {<0, 0, -200> rgb 1}

sky_sphere {pigment {rgb 0}}

#declare XM = 25;
#declare YM = 25;

#for (Y, -1, 1, 0.1)
 #for (X, -1, 1, 0.1)

  cone {-x, Y, x, X
  texture {pigment {rgb <abs(X), abs(Y), abs(X+Y)>} finish {emission 0.2}}
  translate <X*XM, Y*YM, 0>
  }

 #end
#end

text { ttf "arial.ttf", "+r1, -r2", 0.02, 0.0 translate <-1.2*XM,  1*YM, 0>}
text { ttf "arial.ttf", "-r1, -r2", 0.02, 0.0 translate <-1.2*XM, -1*YM, 0>}
text { ttf "arial.ttf", "r1=0, -r2", 0.02, 0.0 translate <-1.2*XM, 0, 0>}
text { ttf "arial.ttf", "+r1, +r2", 0.02, 0.0 translate < 1.1*XM,  1*YM, 0>}
text { ttf "arial.ttf", "-r1, +r2", 0.02, 0.0 translate < 1.1*XM, -1*YM, 0>}
text { ttf "arial.ttf", "-r1, r2=0", 0.02, 0.0 translate <-3, -1.05*YM, 0>}

Post a reply to this message

Attachments:
Download 'cone_test.png' (202 KB)

Preview of image 'cone_test.png'

On 9/24/25 19:26, Bald Eagle wrote:
> Looks like there's some kind of clipping going on with the bounding.

Yep, tried my '-b' yuqk flag and it fixes all the +- -+ cases in your 
test scene where bounding goes wrong(*). Thank you for posting it! :-)

I took a few swings at fixes late last night, but no luck. I'm going to 
code up some parser checks to limit the radii to positive values only 
until I can come back to this issue with more focus.

I have quite a bit yet to do to finish the sor{} changes in yuqk{} and 
that's only the most recent ball I've let hit the ground. :-)

Bill P.

(*) The render was slow without bounding!

Post a reply to this message