









 
 




 
 


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


 
 




 

