Am 21.12.2015 um 16:24 schrieb Sven Littkowski:
> I would wonder, if a new feature (let's call it "melt" or "fusion")
> could fusion any shapes or shape results (difference, intersection,
> union, etc.) with each other at the connection areas WITHOUT shrinking
> them or changing their own dimensions in any other way (as the blob
> function seems to do).
> 
> melt/fusion
> {
>  shape1
>  shape2 { ... strength STRENGTH }
>  shape3 { ... strength STRENGTH }
>  ...
> }

Unfortunately that's not technically possible with the way geometric
primitives (and even complex shapes) are defined and rendered in POV-Ray.

Each POV-Ray primitive is defined by means of two functions:

- One function determines whether -- and if so, where -- a ray, starting
at a given origin in a given direction, intersects the surface of the
object.

- One function determines whether a given point is inside the object
(with a few primitives being defined to have no inside, only an outside).

This is essentially all you can get out of the primitives; it is also
everything the rendering algorithm can work with.

"Melting" objects together, requires an entirely new fundamental
functionality: You need a function that gives you the distance to the
nearest point on the original primitive's surface. For some primitives
this might be easy to implement; for others it may be damn hard, maybe
even impossible.

Also, the tracing algorithm would need to be entirely different, making
use of that distance function rather than the intersection and inside
functions.

A structure intended to help speed up rendering, the so-called "bounding
hierarchy", would also have to be modified. This data structure speeds
up intersection testing, by first testing whether a given ray intersects
the "bounding box" of a given primitive, before even attempting to do an
actual intersection test on the primitive itself. The "bounding box" is
the (ideally) smallest axis-aligned box that contains the entire primitive.

If "melting" is involved, that bounding hierarchy would have to be
modified, to include not only the primitive itself, but also the maximum
distance at which it can still influence nearby shapes.


Additionally, "melting" is a poorly defined process; what would be the
exact formulae for melting two shapes? How would a third shape influence
the result? What about an arbitrary number of shapes? And how would the
underlying math prevent "bulging" in places where the shapes already are
(almost) coincidental?


Implementing a "melting" feature would certainly be a larger endeavour,
and here's how it would have to be tackled to have a realistic chance of
being implemented:


(1) Someone needs to figure out the math that would have to be used:
Given the "distance metric functions" (i.e. functions that return a
distance-dependent value) of N shapes, we'd need an algorithm to
construct another "distance metric function" for the "melted" surface.

For good rendering performance, the influence of any primitive must be
limited to a given distance beyond its proper surface; this can be
achieved by requiring that the distance metric should reach a finite
constant value at the maximum distance of influence, and remain at that
value up to infinity.

There is a bit of freedom insofar as the "distance metric" does not
necessarily have to be linear; squared distance, invese distance,
inverse squared distance - almost any distance-based metric would be
fair game, provided it is used consistently. As a matter of fact, a
"closeness function" would probably be easier to handle, with the
"infinity value" being zero.

One thing to note is that for primitives with a well-defined inside, the
distance metric would probably have to return different values for
inside and outside; for instance, a metric could return values ranging
from 0 (at maximum distance) to 1 (on the surface) for points outside
the primitive, and values from 1 (on the surface) to 2 (at maximum
distance) for points inside the primitive.


(2) Someone needs to prove that the math works, and results in a toolset
that is easy enough to use.

Such a demonstration can be done without having to modify the POV-Ray
source code, as a suitable tracing algorithm is already implemented: The
isosurface primitive is defined by means of a scalar field function (a
function giving a scalar value for each point in space), with all points
below a certain value defined as being inside the shape and all others
outside.


(3) Someone needs to convince the dev team to add some more or less
sophisticated support for the whole thing into POV-Ray. Such support
might be implemented in various phases (not necessarily in that order):

(a) Either the isosurface primitive or the function engine might be
somehow extended to make use of the fact that the partial functions only
have a limited range of influence.

(b) Predefined distance metric functions might be implemented for all
the inbuilt primitives, and some SDL syntax added to get the distance
metric function for a given geometric shape.

(c) Syntax might be added to automatically generate a "melting"
isosurface from a set of geometric shapes.


Note that, due to the limited manpower available within the POV-Ray
project, you should not expect any "someone" above to be a member of the
POV-Ray dev team.

Post a reply to this message