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 }
 ...
}

where the value of STRENGTH can range from 0.0 (no melting) to x (smooth
melting over x amount of units of the first and this shape). Supported
as shapes are box, sphere, cylinder, superellipsoid, cone, object,
difference, union, intersection, etc.. Like with the blob, a negative
value is also possible and would melt all following shapes into the
first shape (holes with blurry shapes of the other shapes into the first
shape). Most important: in opposition to the Blob, using Melt would NOT
influence the original size of the shapes. That Melt function would be a
helpful addition. But what are other POV-Ray users thinking about such a
Melt function? Please let's start a discussion, I need feedback from you
all before proposing it if the feedback is positive.

Post a reply to this message

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

Hi,

my naive idea for a basic melting was or is, to do this "melting" or
"fusioning" simply by a number of curved bodies. Such a curve body looks
similar to a spline or a quarter of a hollow cylinder. One beside each
other would be added (in my image with a STRENGTH value of 2.0 units).
The curves are at a 90° angle to the body's surface at that point, but
at corners there would be added more of these curve bodies in different
angles until they reach the angle of the next side of the body that is
fusioned into the first body (example; a box - each side has a 90° angle
from the other sides, at the corners, more curve bodies are added in
different angles until the curve body's angle equals then with the angle
of the next side of the box). And finally, all these shapes would be
somehow merged together, to create one body. Each curve body takes at
one end the texture of the body below, and on the other end the texture
of that other body, and has something like a texture_map to merge both
textures, like the Blob.

In some cases, the shape of the curve body could also look like an "S",
if one body is melted close to the side of another body. If you don't
understand what I mean, I can create another graphic about that
particular case.

The problem is, that I am not a programmer for such things. I do
programming, but with Delphi, and very different applications. That is,
why I have only very naive ideas about how to do this melting or
fusioning. I hope, that my idea above could lead to a simplified melting.

Post a reply to this message

Attachments:
Download 'untitled-2.jpg' (152 KB)

Preview of image 'untitled-2.jpg'

Something similar has already been done about 15 years ago in
megapov: http://www-f9.ijs.si/~matevz/docs/MegaPov/megapov.html#isoblob

    As an example, this image was done with isoblobs:
http://jeberger.free.fr/povray/images/arnold.jpg

    IIRC, one reason isoblobs were not added to official povray is that
the same thing can mostly be done with regular isosurfaces, and I think
someone made a set of macros to do just that, but I can't find it
anymore. Or you can start here:
http://news.povray.org/povray.general/thread/%3C3e19c81f@news.povray.org%
3E/
and see if some of the linked threads allow you to do what you want...

        Jerome
-- 
mailto:jeb### [at] freefr
http://jeberger.free.fr
Jabber: jeb### [at] jabberfr

Post a reply to this message

Attachments:
Download 'us-ascii' (1 KB)

Sven Littkowski <jam### [at] yahoocom> wrote:
> Hi,
>
> my naive idea for a basic melting was or is, to do this "melting" or
> "fusioning" simply by a number of curved bodies. Such a curve body looks
> similar to a spline or a quarter of a hollow cylinder. One beside each
> other would be added (in my image with a STRENGTH value of 2.0 units).
> The curves are at a 90° angle to the body's surface at that point, but
> at corners there would be added more of these curve bodies in different
> angles until they reach the angle of the next side of the body that is
> fusioned into the first body (example; a box - each side has a 90° angle
> from the other sides, at the corners, more curve bodies are added in
> different angles until the curve body's angle equals then with the angle
> of the next side of the box). And finally, all these shapes would be
> somehow merged together, to create one body. Each curve body takes at
> one end the texture of the body below, and on the other end the texture
> of that other body, and has something like a texture_map to merge both
> textures, like the Blob.
>
> In some cases, the shape of the curve body could also look like an "S",
> if one body is melted close to the side of another body. If you don't
> understand what I mean, I can create another graphic about that
> particular case.
>
> The problem is, that I am not a programmer for such things. I do
> programming, but with Delphi, and very different applications. That is,
> why I have only very naive ideas about how to do this melting or
> fusioning. I hope, that my idea above could lead to a simplified melting.

See if what you need is in the Object Collection:

http://lib.povray.org/searchcollection/index2.php?objectName=RoundEdge&contributorTag=Cousin%20Ricky

Someone else has implemented isosurface blobs using a more intuitive user
interface than mine, but I don't recall by whom or where it is located.  The
module was discussed in one of these newsgroups, so you might try a search.

Post a reply to this message

Am 21.12.2015 um 18:24 schrieb Sven Littkowski:

> my naive idea for a basic melting was or is, to do this "melting" or
> "fusioning" simply by a number of curved bodies. Such a curve body looks
> similar to a spline or a quarter of a hollow cylinder.

That would be even more of a nightmare to implement; there is no way
you'll be able to automatically compute such insets and cutaways for
each and every possible combination of POV-Ray's primitives.

Of course you are free to prove me wrong, by implementing all the
necessary stuff in SDL macros. But I'm quite sure it simply cannot be done.

As an exercise, I challenge you to solve (that is, give a definition of
the "melting" inset shapes for) the following "simple" cases:

- Two cylinders of different radii R_1 and R_2, intersecting each other
(perpendicular and with intersecting axes, for starters), with a
"melting" inset radius of R_i.

- Three planes intersecting each others (perpendicular, for starters),
with different radii for the "melting" insets between the pairs, R_i_1,
R_i_2 and R_i_3. Of course the corner where the three planes meet is
also expected to be smooth.

This might give you a /basic/ idea of the fundamental challenges involved.


A simple rule of thumb: If you struggle to achieve some geometry using
SDL, expect it to be even more difficult for general cases, and a
nightmare to implement as a native feature in POV-Ray.

Post a reply to this message

Interesting, and good to know. But also, as long as it is not within
POV-Ray (the regular one), i won't be able to use it.

I would like to learn iso surfaces, but have at the moment no understand
about them. But then, looking into the help file of POV-Ray, I see that
iso surfaces are requesting mathematical functions. That is, where I
cannot walk on that trail, as  have achieved a lot of skills in my life,
but the skill of developing mathematical functions is not among them.
Sad for me. I don't know, what I can do. Any advise?

Post a reply to this message

Hi, and big thanks. I downloaded the feature, and will check it out.   :-D

Post a reply to this message

Thanks for the examples and explanation. Yes, I admit, I have many
skills, but I am weak, if it comes to mathematical functions. I hoped
that my way would have been easy, but now I feel like I have to give up.

I like the idea of iso surfaces, but those, too, require the knowledge
of how to develop mathematical functions. Here I fail. All my scenes, I
never even use any WYSIWYG editor, also too difficult for me to learn. I
find it much easier, to hand-write the entire scene, and just by looking
at the number coordinates, I get the idea what the scene is about. My
spaceship is hand-written entirely.

If I had any commercial renderer like 3DS on my computer, I would just
re-create that particular part there and would try to melt together the
items there as I know, this is one of their functions. And then to
export it into a POV-Ray-compatible mesh and use it in my scene. Maybe I
should just give up on my need for rounded corners.

Post a reply to this message

> - Two cylinders of different radii R_1 and R_2, intersecting each other
> (perpendicular and with intersecting axes, for starters), with a
> "melting" inset radius of R_i.
>
> - Three planes intersecting each others (perpendicular, for starters),
> with different radii for the "melting" insets between the pairs, R_i_1,
> R_i_2 and R_i_3. Of course the corner where the three planes meet is
> also expected to be smooth.
>
> This might give you a /basic/ idea of the fundamental challenges involved.

The above are both a piece of cake for CAD software (see images 
attached) - but I hate to imagine the maths/algorithms behind this. 
Hopefully the images backup the idea that this would be *hard* to do in 
the general case.

Post a reply to this message

Attachments:
Download 'croppercapture[46].png' (96 KB) Download 'croppercapture[47].png' (53 KB)

Preview of image 'croppercapture[46].png'

Preview of image 'croppercapture[47].png'