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

Post a reply to this message

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)

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

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

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

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 ray-object
intersection equation uses >, =, and < to determine inside or outside or
right-on.

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 post-coffee and pre-heavy 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

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 short-ish answer for POV-Ray as I understand it today.

---
With univariate polynomial equations (ray-surface 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/regula-falsi solver. 
Sturm 'mostly' for single root isolation, then regula-falsi 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 POV-Ray(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 ray-surface intersection values.

So... Might be we have bisection or solvers-other floating around I've 
not seen - or recognized - for what they are.

Bill P.

(2) - Beyond POV-Ray's implemented root finding methods, you find there 
are a mind-blowing 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 POV-Ray originally had no such resource.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> 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?
>
> 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 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.

This all seems to chasing the same objective as I was in my posting in 2016
http://www.john-greenwood.co.uk/PovRay/Rounded_Objects/Basics.html

I found creating shapes this way was still rather slow and since then started
experimenting with creating ordered meshs using Excel that can be deformed by
cunningly applied equations in Excel to create a prototype mesh2 object body
part that can be customised by further parameters in PovRay.

This work is on hold for now, I shall be 80 next year and have other projects,
so I would be delighted if anyone picked up on any of the stuff I have done
since I found PovRay in 2013 ie:

Rounded corners, Tweek Colours, Crowd.

Post a reply to this message

"John Greenwood" <joh### [at] john-greenwoodcouk> wrote:

> This all seems to chasing the same objective as I was in my posting in 2016
> http://www.john-greenwood.co.uk/PovRay/Rounded_Objects/Basics.html

Of course.  Thus, the "... people have been requesting for quite some time...."
bit.

> I found creating shapes this way was still rather slow and since then started
> experimenting with creating ordered meshs using Excel that can be deformed by
> cunningly applied equations in Excel to create a prototype mesh2 object body
> part that can be customised by further parameters in PovRay.

Well yes, sometimes things can be "slow", however, how long does it take to
learn, understand, code, and render a one-off shape you might want to make?
The idea here was to just make such rounding easily accessible, since it's
effortless to blend/bend objects and click the start render button and let it
go...

The excel mesh idea is interesting - I'm a big fan of anything and everything
spreadsheet.

> This work is on hold for now, I shall be 80 next year and have other projects,
> so I would be delighted if anyone picked up on any of the stuff I have done
> since I found PovRay in 2013 ie:
>
> Rounded corners, Tweek Colours, Crowd.

Crowd?

Post a reply to this message

> "Bald Eagle" <cre### [at] netscapenet> wrote:
>
> This work is on hold for now, I shall be 80 next year and have other projects,
> so I would be delighted if anyone picked up on any of the stuff I have done
> since I found PovRay in 2013 ie:
>

 When I was turned 49 some one asked how old I was. I told them I was 94.
I went old to say: I'm not in good shape for 49. But for 94 I in damn good
shape.

I can't wait until I'm 8 :)

Post a reply to this message