Just unloading some more thoughts for the record.

Prism has always annoyed me, because it only takes 2D vectors, and I wind up
having to do a lot of unnecessary conversions when I'm starting with 3D points,
and wanting to do something with prisms.

Apparently polygon {} already has the inbuilt feature that prism {} _should_
have.

"All points of a polygon are three-dimensional vectors that have to lay on the
same plane. If this is not the case an error occurs. It is common to use
two-dimensional vectors to describe the polygon. POV-Ray assumes that the z
value is zero in this case."
https://wiki.povray.org/content/Reference:Polygon


Exploring Thomas Fester's modeling-with-blobs method, it occurred to me that
blobs should have an _optional_ strength argument, and perhaps a new keyword
such as blob_strength can be included in a blob definition to set a default
strength.

The purpose of that would be to simply allow enclosing some vast collection of
spheres and cylinders in an extant scene to be wrapped by a blob {} statement
and still function - without having to edit every single damned line to include
a strength component.

Part of what I see in other software packages is the sophisticated handling of
data structures such that the user doesn't have to sit there and puzzle out how
to hand-reformat all of their data to fit into some other feature's input.

If I take the sine of a vector, I ought to get a vector with all the components
being the sines of the original vector components.
Same with taking the sine of a matrix.

POV-Ray currently has no "point" primitive, even though that's probably the
fundamental thing we all use that underlies all of the other primitives.
The "where" of everything.

We have center points for spheres, tori, endpoints for cylinders, corner points
for boxes, etc.

But when that data is embedded into a primitive {} statement, it's no longer
accessible to the SDL in any [convenient] way.

Something interesting would be to have an "extraction" feature whereby one could
enclose an object - lets say a simple union of cylinders and spheres - in curly
braces or parentheses, and the keyword operating on that would extract an array
of points and their associated primitive types.

The key idea here is the ability to elaborate on existing work, rather than
having to laboriously and time-consumingly deconstruct, dissect, analyze,
scheme, plan, and reconstruct an otherwise perfectly good data set so that you
can get on with the derivative work that you had in mind in the first place.

Another related idea is the fact that users frequently have a need to keep track
of objects and their positions, and need ways to maneuver them into specific
positions.


If I have two instances of an object, but they are hand-modeled or the result of
measurements or automated scripts - where the second is perhaps rotated and
translated into another specific position relative to the first (but obviously
not a COPY of the first placed with rotate or translate) then it would be useful
to have some 3D fitting algorithm that maps Item1 to Item2 and returns a
transform matrix. (obvious this is complicated and fraught with limitations)

A stumbling block that can be encountered is that all spheres are the same.  In
terms of the fact that they are all just sphere {} objects.  One can not track
any individual sphere.  This used to be an extremely limiting problem in
chemistry - because all atoms of the same type were the same.
Until we discovered isotopes.  They still react the same, but they have
different nuclear properties that we can look at and see that they are
different.
Being able to "tag" specific primitives with "metadata" that they carry with
them would be a useful feature, especially if that data could be queried.

This goes back to using the VISIO paradigm of SmartShapes and SmartSheets, but
one could readily see that if the only metadata associated with an object was
its normal vector, then that could potentially save an enormous amount of
calculation, since the metadata normal vector would be transformed along with
the object it is already attached to.

- BW

Post a reply to this message