POV-Ray : Newsgroups : povray.advanced-users : Mathematical "Primitive" vs Isosurface : Re: Mathematical "Primitive" vs Isosurface Server Time15 Sep 2024 05:45:43 EDT (-0400)
 Re: Mathematical "Primitive" vs Isosurface
 From: Le Forgeron Date: 8 Aug 2019 12:02:58 Message: <5d4c47b2\$1@news.povray.org>
```
{
"@context": "https://schema.org",
"@type": "DiscussionForumPosting",
"@id": "#5d4c47b2%241%40news.povray.org",
"headline": "Re: Mathematical \"Primitive\" vs Isosurface",
"dateCreated": "2019-08-08T16:02:58+00:00",
"datePublished": "2019-08-08T16:02:58+00:00",
"author": {
"@type": "Person",
"name": "Le Forgeron"
}
}
Le 07/08/2019 à 22:16, Bald Eagle a écrit :
>
> Le_Forgeron <jgr### [at] freefr> wrote:
>
>> The generic function need to be evaluated in various points along the
>> ray/path, to solve the root(s).
>> No intrinsic knowledge of the properties of the function is used.
>> The good side is that the evaluation is limited to a container.
>> The bad side is that bounding box optimisation is only a dream.
>> The computation of fancy position uses the provided data.
>> The computation of the function uses a virtual machine, which can be
>> non-optimal for the native CPU.
>
>
>> The native sphere: we can use its properties.
>
> But, the properties of sphere {} and isosurface {} should be the same --- no?
>

From the point of view of the code, no.

isosurface defines a "potential", a value for every point of space.
And finding the intersections with the surface which delimit the
positive from the negative is the jobs of a solver.

sphere {} is only a surface that delimit the separation between inside
and outside. there is no "potential" for every point of space. At best,
you can know if it is inside or outside.

>> The maximal number of roots (intersection with a ray) is known.
>
> So, is the source-code sphere evaluated or defined in a different way than an
> isosurface function of the same sphere?

Yes.

>
>> Computing all the roots for a path is simple, without intermediate
>> evaluations.
>
> Does that mean that there are shortcuts in the source code, whereas for a user
> defined isosurface sphere, those can't be used?
>

Exactly.

>> The computation of fancy position uses a translation to reduce the
>> problem to a sphere at the origin. This might have an impact on native
>> precision when translated back.
>> UV-mapping might be available. (from coordinate of intersection to
>> uv-values)
>
>
> It seems to me that, aside from some issues of speed and accuracy, there are
> largely "the same".
>

Of course, they are mathematically the same. But the way it get computed
is very different.

> If this is the case, then is there anything preventing the implementation of
> pseudo-Boolean operations like "soft minimum" or other variants, that provide a
> smoothing of the hard boundaries?
>
> http://iquilezles.org/www/articles/smin/smin.htm
>
> Smooth Union, Subtraction and Intersection - exact, bound, bound
> http://iquilezles.org/www/articles/distfunctions/distfunctions.htm
>
>
> That would seem to address most of what a lot of people have been requesting for
> quite some time with regard to rounded edges and "fillets".
>

why do I have a feeling of another return of the blob ?
(blob have sphere & cylinder, and they have nothing in common with the
code of native sphere and cylinder)

>
>
>
> I've already implemented about 4 of these, and they seem to produce very nice
> transitions between shapes.   Still need to spend some time exploring some more
> experiments with these, but I'm wondering if some of these could be added in
> source code to manipulate primitives or more complex CSG objects, and -
>
> if it would be possible or advantageous in any way to add a user-defined
> pseudo-Boolean blending operation.  Simply because, having tried to do some very
> detailed and extensive work with isosurfaces, the manner in which the functions
> need to be constructed can be very cumbersome.  With "primitives", object
> modifiers such as translate rotate scale, etc are easy to add in before applying
> the Boolean operator.

Can you use macro to combine the various surfaces ?
With optional argument such as a transformation matrix.