hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 9/22/25 13:44, jr wrote:
> >> ...
> > I'd hoped ... for some "evidence-based" words.
>
> First, let me say I don't really know what you are after. :-)

well, confidentially, that makes two of us.  </grin>


> And, Bill W, I saw your recent post responding to jr's post.

replied to below.


> which introduces a couple concepts. Those two concepts don't map
> directly to anything in the code - though users (including me) commonly
> use those terms(*).
>
> In the code we do track patch objects / shapes in the base object class
> with a flags integer for which the bit used is PATCH_OBJECT. The
> PATCH_OBJECT bit being on, when initially constructed, essentially means
> the shape does not, start, with an inside test which can return true.
>
> Patch class shapes are derived from a helper class called NonsolidObject
> which inherits from the base object class. That helper class currently
> sets an integer value that maps directly to the particular patch type.
> The additional information is never used that I see. Despite the class
> name it is way to track the patch type (TypeOfPatchObject would be a
> better class name I think, but, I lean toward it being deleted from the
> class hierarchy).
>
> Strictly speaking, all we have inside the ray tracer are ray-surface
> intersections. We can link functionality to those surfaces - that's
> it(**). Bill W, I agree shapes can situationally, appear to be solid,
> but it's always conditional in POV-Ray(***).

thank you, very much.  like BW I get much from your explanations; the 'aside's
often offer even "better value for money" :-).

> ...
> (***) - See attached image. Is the sphere solid in this situation? Code
> used:

what a teaser..  :-)

on the 'sor{}'.  I've decided to be "guided by" the 'open' keyword.  that is
accept that it can be described solid while "capped", but for documentation
purposes keep the current moniker; when that page gets updated (along with the
tutorial), we can add (maybe under "Finite Solid Primitives" ?) a sentence or
two on the "difficulties" finding defining words.


> > ... required "infrastructure" ...
> No. As Bill W suggested there might be some brute force ways to approach
> it. Where we have value field defined shapes, it should be we could come
> up with optimizations. Whether we could ever get to something which
> would work well enough for on the fly ray-surface intersections, I'm not
> sure.
> Mechanical engineers surely have software which can determine the
> rotational volume required for 3D things - whether any methods are fast
> enough to run real time (without massive parallelism) I have doubts, but
> who knows. I've not dug.

"on the fly" ?  </grin>  thanks though, I now think that, while we wait for a
new POV-Ray development and or the heat death of the universe, a macro will have
to do to simulate the "sweeping".



@Bald Eagle

> So you're using language to describe something that can simultaneously have two
fundamentally different attributes.

agree, the (English) language gets in the way.  we'll (need to) add a
"clarifying" paragraph.


> If it looks solid, and acts solid, then I would imagine that we could agree that
> it was solid.  If we need to specify "open" to make it (non-keyword) hollow,
> then what was it before we changed it to hollow?

"solid" argument :-).  see above.


> "If there are n points we will have n-3 segments."

_hiding_ in all that "formula stuff", thanks for the reference.


regards ,jr.

Post a reply to this message