









 
 




 
 


Aside from the obvious userdefined 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 }} ?
Post a reply to this message


 
 




 
 


Le 06/08/2019 Ã 23:05, Bald Eagle a Ã©critÂ :
>
> Aside from the obvious userdefined 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
nonoptimal 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.
UVmapping might be available. (from coordinate of intersection to
uvvalues)
Post a reply to this message


 
 




 
 


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
> nonoptimal 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 sourcecode 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.
> UVmapping might be available. (from coordinate of intersection to
> uvvalues)
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
pseudoBoolean 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".
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 userdefined
pseudoBoolean 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


 
 




 
 


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
>> nonoptimal 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 sourcecode 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.
>> UVmapping might be available. (from coordinate of intersection to
>> uvvalues)
>
>
> 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
> pseudoBoolean 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 userdefined
> pseudoBoolean 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


 
 




 
 


Le_Forgeron <jgr### [at] freefr> wrote:
> > But, the properties of sphere {} and isosurface {} should be the same  no?
> From the point of view of the code, no.
Yes, the code is always different. I just wondered _how_ different.
> isosurface defines a "potential", a value for every point of space.
> 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.
Mmmmmmmmm..... I will take a look at the source when I have some time to find
it, but I would have to guess that if a sphere is a "mathematical primitive",
then it is based on an equation that defines the surface, and the rayobject
intersection equation uses >, =, and < to determine inside or outside or
righton.
does the "potential" exist only because of the way the code evaluates an
isosurface, and the "potential" for a sphere, while extant, and mathematically
identical is simply inaccessible due to the specialized structure of the code
for rendering primitives?
> 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 never looked at the blob / metaball code or have any knowledge of the
history of its development. Sounds like a messy story. ;D
> 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 ?
I did some thinking about this postcoffee and preheavy lifting. My thoughts
(for proof of concept) were similar  use a macro to define the various
transformation matrices and then multiply them together, and then define
functions for the final x, y, and z transformations before plugging them into
the function for the shape.
So, your idea to do it in a similar way is encouraging. :)
And that's fine for making my head hurt, flexing the mental muscles, and playing
around with the idea to illustrate what may be possible...
But really, the end goal would be to have different types of customizable
Boolean operators in the source code.
Then, it would be a simple matter of something like
smoothunion {box{} sphere {} method 1 strength 0.1}
Post a reply to this message


 
 




 
 


Hello/Hi,
I remember in school my mathematics teacher told me that for the equation of 6th
degrees and above it was impossible to find roots with a perfect method (that
characteristic has been demonstrated). The functions in isosurface primitive can
use any degree equation (the parametric function which indicates that for any
(x,y,z) set, we are on volume surface if it is equal to zero, if the result is
negative we are inside or outside if positive. So in povray, the point is to
find roots (zero equality) for intersections. This said, how can POVRay find
roots of 6th and above degree equations ?
The isosurface uses the Newton's approximation to find roots of the isosurface:
https://en.wikipedia.org/wiki/Newton%27s_method
This last method while not perfect (some equations tend to give almost infinite
results the closer you are from a x value and since Newton's method is an
approximation this can take a very long time to find the root), so to not spend
a very long time testing value for intersections the 'accuracy' parameter of
isosurface can be set to something like 0.0001 for example to abort further
approximation of a single root if Newton's method find a result of 0.0001 or
less (not perfectly 0 I mean).
My english is not perfect, I apologize for any writing error. :D
Post a reply to this message


 
 


From: William F Pokorny
Subject: Re: Mathematical "Primitive" vs Isosurface
Date: 13 Oct 2019 14:00:17
Message: <5da32df1$1@news.povray.org>



 
 


On 10/13/19 5:56 AM, Warren wrote:
> Hello/Hi,
>
> I remember in school my mathematics teacher told me that for the equation of 6th
> degrees and above it was impossible to find roots with a perfect method (that
> characteristic has been demonstrated). The functions in isosurface primitive can
> use any degree equation (the parametric function which indicates that for any
> (x,y,z) set, we are on volume surface if it is equal to zero, if the result is
> negative we are inside or outside if positive. So in povray, the point is to
> find roots (zero equality) for intersections. This said, how can POVRay find
> roots of 6th and above degree equations ?
>
> The isosurface uses the Newton's approximation to find roots of the isosurface:
> https://en.wikipedia.org/wiki/Newton%27s_method
>
> This last method while not perfect (some equations tend to give almost infinite
> results the closer you are from a x value and since Newton's method is an
> approximation this can take a very long time to find the root), so to not spend
> a very long time testing value for intersections the 'accuracy' parameter of
> isosurface can be set to something like 0.0001 for example to abort further
> approximation of a single root if Newton's method find a result of 0.0001 or
> less (not perfectly 0 I mean).
>
> My english is not perfect, I apologize for any writing error. :D
>
>
A shortish answer for POVRay as I understand it today.

With univariate polynomial equations (raysurface intersection/root
equations):
There are fixed solvers for orders one through four.
I've heard there is now a fixed solver method for quintics based on
changing the form of the polynomial via elliptical functions  or
something. I don't understand the method at all, and it's not
implemented. Those in the know don't recommend it computationally over
root isolation and iterative methods.
For orders 2 through 35(1) there is a common sturm/regulafalsi solver.
Sturm 'mostly' for single root isolation, then regulafalsi to get to
the actual root values.
(1)  Practically I'd be surprised if much past order 15 is stable, but
maybe, in special cases.

With functions in general (isosurfaces for example):
There are various iterative solvers based roughly upon sampling of the
function values and it's derivative values (or estimations thereof) at
points along the ray (or at or about some fulcrum).

Aside: I've been playing seriously with solvers and solver techniques
the past couple years. Still, I've not taken detailed looks at all the
solvers that exist in POVRay(2)! In addition to the common solvers,
custom solvers  or parts of certain solver techniques  can be found
throughout the shape code. For example, I don't know what solver
technique(s) the isosurface shape uses by name (Steffenson's?)  though
it's on my list to look at that one it in detail someday. I've not
looked at the parametric's code aside from a problem with the shape code
returning negative raysurface intersection values.
So... Might be we have bisection or solversother floating around I've
not seen  or recognized  for what they are.
Bill P.
(2)  Beyond POVRay's implemented root finding methods, you find there
are a mindblowing number of techniques and tweaks to existing methods
for finding roots. I've found Wikipedia good for the overviews and
pointers for digging into solvers. Amazed when I think how those coding
up POVRay originally had no such resource.
Post a reply to this message


 
 




 

