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