POV-Ray : Newsgroups : povray.advanced-users : Mathematical "Primitive" vs Isosurface : Re: Mathematical "Primitive" vs Isosurface Server Time15 Sep 2024 04:59:32 EDT (-0400)
 Re: Mathematical "Primitive" vs Isosurface
 From: Le Forgeron Date: 7 Aug 2019 11:47:08 Message: <5d4af27c\$1@news.povray.org>
```
{
"@context": "https://schema.org",
"@type": "DiscussionForumPosting",
"@id": "#5d4af27c%241%40news.povray.org",
"headline": "Re: Mathematical \"Primitive\" vs Isosurface",
"dateCreated": "2019-08-07T15:47:08+00:00",
"datePublished": "2019-08-07T15:47:08+00:00",
"author": {
"@type": "Person",
"name": "Le Forgeron"
}
}
Le 06/08/2019 à 23:05, Bald Eagle a écrit :
>
> Aside from the obvious user-defined vs implemented in source code,
>
> can someone define and differentiate the difference between a "mathematical
> primitive" like a
>
>      sphere {0, 1}
>
> and an isosurface object such as
>
>      isosurface {function { x*x + y*y + z*z - 1 }} ?
>

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.
The maximal number of roots (intersection with a ray) is known.
Computing all the roots for a path is simple, without intermediate
evaluations.
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)
```