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)




>
http://news.povray.org/povray.general/thread/%3Cweb.57c1c5e4750b03f1a7cafab50%40news.povray.org%3E/?mtop=410897
> 
> http://news.povray.org/povray.binaries.images/thread/%3C418e6d4e@news.povray.org%3E/
> 
> 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.

SPHERE( center, radius )
GLUE()
SPHERE( center, radius, transform )

or something along ?

And the scary details are handled inside the macro ?

Post a reply to this message