POV-Ray : Newsgroups : povray.advanced-users : Mathematical "Primitive" vs Isosurface : Re: Mathematical "Primitive" vs Isosurface Server Time
28 Sep 2021 19:37:43 EDT (-0400)
  Re: Mathematical "Primitive" vs Isosurface  
From: Bald Eagle
Date: 7 Aug 2019 16:20:00
Message: <web.5d4b31a665080b014eec112d0@news.povray.org>
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?

> 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?

> 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?

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

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?


Smooth Union, Subtraction and Intersection - exact, bound, bound

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



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.

Post a reply to this message

Copyright 2003-2021 Persistence of Vision Raytracer Pty. Ltd.