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

> > In working on these updates I've run across more checking of the
> > PATCH_OBJECT type. Reasonably sure I'm going to change patch-like
> > objects now BASIC_OBJECT types to PATCH_OBJECT. My bet is this change
> > will make for no functional changes beyond parser checks not allowing
> > patch-like objects in certain operations where they should probably
> > never have been allowed - like manual bounding.

I do understand this.

However, let me just throw this out there for very long-term consideration.

After porting code from software packages like Mathematica, I find it
interesting the degree of flexibility their expressions have.

If there is a way that we can at the very least keep an eye on this potential, I
suggest that we do so.  Perhaps this may only be in code "stubs" or comments.

If something like a disc {} has an inside that POV-Ray can use under the hood,
then the user ought to have access to this as well.  And I would point out that
this may suggest changing the entire way that we approach defining and rendering
the shape.

Consider that I have a disc{}, and want to make future use of it in a way that
is not directly related to _rendering_ the disc.  I may want to do something
like illuminate the space above it with media.  It would be useful to be able to
bound the space above it.

Presumably the disc has an "inside" that is the cylindrical region below it in
the half-plane.  I ought to be able to easily make use of that.  And limit it
with a distance along that normal axis.  As well as the space above it
(trivially done with scale -Normal).  But then also have the disc {inverse} work
as well.


Maybe I want to align a thing with the disc.
Or limit something to with its radius.
or cut a hole in the ceiling above it.
or project it onto an axis or a plane.

It would be nice to be able to "expand" that disc into a cylinder {} of some
sort.  Or a line segment of its projection.
We can either do that with the native shape, or we can add tools to make this
data available in some other form.   I have suggested that we have a point{}
"shape", and being able to union {} those into a line segment would a useful
thing as well.  Because at present we have no way to (easily) apply translate,
rotate, and scale to such constructs.

We have the things - which are imperfectly and incompletely implemented,
but what I'd argue that we need are the tools to better make use of them in a
simple, nimble manner that doesn't require new, average, or even experienced
users to take a course in linear algebra, calculus, or spend 3 hours trying to
to come up with the proper search terms and find valid, relevant, comprehensible
results so that they can accomplish a conceptually simple geometric task.

So, I take no issue with simplification - as a first step towards straightening
out the code base.  However I'm a strong proponent of developing things in such
a manner that they can be expanded upon and used for more than the simplest and
most limited of purposes.

- BW

If we adopt the cylinder shape that I speculate about in the other thread, then
perhaps the end caps can define the entire shape.
We would have two surface normals and two radii, and so would be able to have
cylinders, cones, and not trigger a degenerate cylinder error.

As always, much to think about.

Post a reply to this message