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

"Bald Eagle" <cre### [at] netscapenet> wrote:

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

https://www.povray.org/beta/

--------------------------------------------
Changes between 3.7.beta.35 and 3.7.beta.35a
--------------------------------------------

Fixed an axis problem with cones.



And that's all I've found so far.
Haven't downloaded the 3.8 source to dig through that yet.   All I have is 3.7
stable.

- BW

Post a reply to this message

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


> 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'm looking at the following

if (fabs(apex_radius - base_radius) < EPSILON)           // line 757

if (apex_radius < base_radius)                           // line 768

tmpf = base_radius * len / (apex_radius - base_radius);  // line 782

if (((apex_radius - base_radius)*len/tlen) < EPSILON)    // line 788


and wondering if those should should use fabs of each radius for the
calcs/comparisons

Just because I'm getting the impression that once one of the values crosses
zero, the differences sort of double-back on themselves, which might trigger
that whole

 /* What we are dealing with here is really a cylinder */

        Set_Flag(this, CYLINDER_FLAG);

        Compute_Cylinder_Data();

        return;

part, which might wind up clipping one side of the cone.
So it might be partially an algorithmic bug?

What bounding are you disabling in yuqk?
Is it stuff in
https://github.com/POV-Ray/povray/tree/master/source/core/bounding ?

Have you tried manually bounding the cones with a cylinder using the max
(abs(r1), abs(r2)) in SDL?  Curious if that would
a. work
and
b. be faster

- BW

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:

> Have you tried manually bounding the cones with a cylinder using the max
> (abs(r1), abs(r2)) in SDL?

POV-Ray screwed me.

"Unnecessary bounding object removed."

Might be time to fix that or update the bounded_by documentation page.

Post a reply to this message

On 9/24/25 15:07, William F Pokorny 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...

Alright. In yuqk I've turned the disc{} shape into a shape like 
polygon{} having an inside test which always returns false.

---

What I learned is that the polygon{} shape - and now the disc{} shape 
too - are not PATCH_OBJECT type shapes internally, but rather 
BASIC_OBJECT types also using that NonsolidObject class.

I'd earlier missed that the NonsolidObject class overrides the Invert() 
method in the base object class in a way that turns the object modifier 
'inverse' method into a No-OP (disables 'inverse').

So... We have in the code two slightly different ways to set up patch 
like objects. Why? Why? Why! you ask.

The only effective difference I see at the moment is that when the 
patch-like shape is set up as a PATCH_OBJECT type we get warnings we 
don't get when the patch-like shape is set up as a BASIC_OBJECT type. 
Specifically:

   "Parse Warning: Patch objects not allowed in intersection."

and

   "Cannot invert a patch object."

In yuqk, I've changed that first warning so that it is only active for 
yuqk's debug compile because I don't see much value in it - we can do 
those sorts of intersections. Further, I changed the debug compile 
warning message so that it now reads:

"Parse Warning:
Patch object used in difference{} or intersection{} block. If a mesh{} 
or mesh2{} shape consider defining an 'inside_vector' to enable inside 
testing."

The second parse warning has - for release R20 - been moved to 
NonsolidObject::Invert() to generate warnings for all patch-like shapes 
no matter their being set up as BASIC_OBJECT or PATCH_OBJECT.

As for how all this patch-like stuff should ultimately be set up, I need 
think about it for a while (see aside below).

Bill P.


Aside
-----

Why not allow 'inverse' with more (all?) these patch-like 
(NonsolidObject) shapes? In some limited code play things look to work.

It flips the normals, which is useful where both texture{} and 
interior_texture are set up.

The inside region would be limited by the shape's bounding box where 
'inverse' is used.

We could then too use bounded_by{} to do much of what clipped_by{} can 
do, but more efficiently.

The obvious downside, I think, is the behavior is less intuitive / 
obvious to users (me included). Thoughts?

In any case, all has me leaning even more toward changing the default in 
V4.0 to preserving user specified bounding as the default. These days, 
mostly, there is only auto-bounding in scenes. Where a user specifies 
bounded_by{} he probably wants to use that bounding.

Post a reply to this message

On 9/25/25 18:52, Bald Eagle wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> 
>> Have you tried manually bounding the cones with a cylinder using the max
>> (abs(r1), abs(r2)) in SDL?
> 
> POV-Ray screwed me.
> 
> "Unnecessary bounding object removed."
> 
> Might be time to fix that or update the bounded_by documentation page.
> 

You can manually bound, if you use '-ur' / 'remove_bounds=off'.

The '-b' option turns off all general object bounding(*) in the yuqk 
fork. It turns off most, but not all, of that same general bounding in 
v3.7 and v3.8 versions of POV-Ray.

Bill P.

(*) - Bounding methods 1 (slab) and 2 (bsp).

Beyond that bounding, some shapes like blob{} and mesh{} / mesh2{} have 
internal bounding which can sometimes (always?) be turned off with the 
SDL 'hierarchy off' object modifier; Some shapes - like the sor{} - have 
internal bounding that is always there; Some shapes always use a 
contained_by{} shape which both determines bounds and can become part of 
the overall result - a little like a, tucked in the shape, 
intersection{}.

Post a reply to this message

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

> So... We have in the code two slightly different ways to set up patch
> like objects. Why? Why? Why! you ask.

Why, Bill?  :D


> "Parse Warning:
> Patch object used in difference{} or intersection{} block. If a mesh{}
> or mesh2{} shape consider defining an 'inside_vector' to enable inside
> testing."

That's like one of the best POV-Ray warning messages I've ever read.  :)


> We could then too use bounded_by{} to do much of what clipped_by{} can
> do, but more efficiently.

Why more efficiently?

> The obvious downside, I think, is the behavior is less intuitive /
> obvious to users (me included). Thoughts?

Well, that depends on the documentation and examples provided, right?
I'm sure that given everything that gets learned, all of that should be
documented/preserved in a directory specific to that object type.
Scene files, comments, and supplementary documentation files are cheap - but the
preservation of the insights and lessons are invaluable.
Detailed diagrams and even animations are cheaply stored in the distro as .pov
and .ini files.

> In any case, all has me leaning even more toward changing the default in
> V4.0 to preserving user specified bounding as the default. These days,
> mostly, there is only auto-bounding in scenes. Where a user specifies
> bounded_by{} he probably wants to use that bounding.

We would assume so, yes.

Now that you're that deep into the code for disc, which is a simple object,
could you at some point help a few of us POV-bros out and give a general layout
of how POV-Ray .h and .cpp files go about "making" the object?

Perhaps in a dedicated thread?

The faster I'm able to learn to navigate my way through one object, the easier
the rest of them will be.  Even I can't start writing various bug fixes and
features from scratch, I can at least start writing up good, accurate, and truly
helpful documentation and diagrams.

-----

Hugely tangentially related, have you thought about using that as a test object
(simple normal code) for developing things like surface normal pigment
functions, directional gradient pigment functions, and surface curvature pigment
functions?
Applying that to a sphere would allow anisotropic scaling to then start to
really test those out.  I'm sure even mistakes would yield interesting results.


- BW

Post a reply to this message

On 9/30/25 20:41, Bald Eagle wrote:
>> We could then too use bounded_by{} to do much of what clipped_by{} can
>> do, but more efficiently.
> Why more efficiently?

Your question got me thinking - thanks. It's probably less often more 
efficient than I first thought.

The clipped_by{} process is something which runs after ray-surface 
intersections for the object being clipped are determined. Basically, it 
runs one or more shape inside tests for each surface intersection. Those 
found inside are kept, those not are ignored. The inside tests are not 
free to calculate - and they bypass the higher level generic bounding so 
the inside test often get run more than strictly necessary.

What had in mind was something like the sphere solid-not-solid example 
using a difference as a stand in for clipped_by{} where the disc was out 
of scope bounding wise. We'd use only the 'inverse' inside test - within 
the bounding box. Unlike that solid-not-solid example, the inside test 
cost close to nothing - higher compiler optimization levels should 
eliminate even the method / function call.

On letting your question bang around in my skull for a while I had the 
thought - well Bill P, you could just use the inverted disc as the 
clippped_by{} shape. In that case the inside test itself would be faster 
because it is always false. We'd still be losing out on the high level 
bounding by using clipped_by{}.

---

Related. What I'm starting to think a lot about, is trying out some 
no-surfaces-ever / inside-test-only 'non-shapes' as another class of 
objects we could use in CSG operations.

In POV-Ray proper we have the object{} pattern. (In yuqk the object{} 
pattern has been renamed bool_object{} and about a half dozen additional 
forms like dens_object, list_object{} patterns have been added.)

I 'think' there is nothing stopping us from using what are effectively 
scalar value fields (value patterns) as inside tests that can be bounded 
and used more or less 'directly' in CSG to select / ignore portions of 
surfaces. Those CSG surface results could then have spatial object 
modifiers applied, for example, in addition to specific texturing.

---

I saw your suggestion about creating some how to object documentation... 
I think clipka did something like this in a post for what is more or 
less obvious as necessary functions / methods by looking at something 
like disc.cpp. In support of any object is dedicated parsing code for 
the supporting SDL.

It's complicated beyond that rough outline. What you've been doing with 
trying to pull back the layers with the sor{} implementation is just 
what one has to do - pretty much shape by shape because they are all 
implemented somewhat differently.

Maybe, if I do get to trying on or more 'non-shapes' / 'insider'(s), I 
can keep a rough log of what I did to implement one. No promises.

Bill P.

Post a reply to this message