The way this would work is, as I understand it, basically the same as blobs,
but, to avoid confusion, I will describe what I have in mind without using blob
terminology.

rounded_object command would followed by a surface count scalar, normally an
integer and a number of element definitions of different types.

One type of element will be an infinite plane with an inside and an outside. It
could be defined either by a vector for a point in the plane and a direction
vector defining the normal and the side, or by three vectors for points in the
plane, with the inside defined by the handedness of these points. There would be
a scalar value to define the radius of the corners

As each ray chugs through design space it will need to know its distance from
each of these planes and on which side it is. Associated with each plane is a
"field" which has the value of 1 at distances greater than the corner radius
from the inside and -1 at distances greater than the same distance outside.
Between these two the strength of the field follows a sine curve, going through
zero at the plane itself. The field values of all the elements are summed. (The
calculation might be faster with cubic; the corners would not be exactly
circular, but would anyone notice or care?)

A simple tetrahedral rounded object can be created with four plane elements. The
ray decides it has encountered a surface when the sum of the field values is
greater than the surface count number, which, in this case is 3. In general, for
convex polyhedra, it would be one less than the number of plane elements.

Other elements would be an infinite cylinder, an infinite cone and a sphere. So,
for example, a finite cylinder would be defined by adding two plane elements
with a surface count of 2. A finite cone needs a single additional plane and a
surface count of 1. A hemisphere would be defined by a sphere and a plane and a
surface count of 1. Two overlapping sphere elements with a surface count of 1
will give the intersection and a value of 0 the union.

These elements could be assigned a negative radius and be subtracted from the
rest of the elements in the rounded object.

I think it may be possible for an already defined rounded object to be used as
an element. The trick would be for the fields of its component elements to be
summed but its contribution to the overall sum to be limited to 1. Like the
other enclosed elements, the radius field could be reversed to subtract the
shape of the pre-defined object element from the rest.

The radii of elements in a rounded object do not have to be the same and I think
that, if the surface count was not an integer it may be possible to swell or
shrink the object by an amount less than the corner radius.

Am I thinking on the right lines?

Post a reply to this message

Le 13/09/2016 à 18:09, John Greenwood a écrit :
> 
> The way this would work is, as I understand it, basically the same as blobs,
> but, to avoid confusion, I will describe what I have in mind without using blob
> terminology.
> 
> rounded_object command would followed by a surface count scalar, normally an
> integer and a number of element definitions of different types.
> 
> One type of element will be an infinite plane with an inside and an outside. It
> could be defined either by a vector for a point in the plane and a direction
> vector defining the normal and the side, or by three vectors for points in the
> plane, with the inside defined by the handedness of these points. There would be
> a scalar value to define the radius of the corners

I would recommend to stick to point+normal, as handedness is unreliable
term.
and the radius might be encoded as the length of the normal.

> 
> As each ray chugs through design space it will need to know its distance from
> each of these planes and on which side it is. Associated with each plane is a
> "field" which has the value of 1 at distances greater than the corner radius
> from the inside and -1 at distances greater than the same distance outside.
> Between these two the strength of the field follows a sine curve, going through
> zero at the plane itself. The field values of all the elements are summed. (The
> calculation might be faster with cubic; the corners would not be exactly
> circular, but would anyone notice or care?)

hmmm interesting, maybe it could already be tested with isosurface (to
validate the concept)

> 
> A simple tetrahedral rounded object can be created with four plane elements. The
> ray decides it has encountered a surface when the sum of the field values is
> greater than the surface count number, which, in this case is 3. In general, for
> convex polyhedra, it would be one less than the number of plane elements.
> 
> Other elements would be an infinite cylinder, an infinite cone and a sphere. So,
> for example, a finite cylinder would be defined by adding two plane elements
> with a surface count of 2. A finite cone needs a single additional plane and a
> surface count of 1. A hemisphere would be defined by a sphere and a plane and a
> surface count of 1. Two overlapping sphere elements with a surface count of 1
> will give the intersection and a value of 0 the union.
> 
> These elements could be assigned a negative radius and be subtracted from the
> rest of the elements in the rounded object.

kind of inversed ? it is not needed for plane (just turn the vector in
opposite direction)
but can be meaningful for cylinder, cone, sphere and other.

infinite cylinder would be specified by a point, a radius and a vector
along the axis.
Once again the length of the vector can be abused to have the rounding
radius value.


> 
> I think it may be possible for an already defined rounded object to be used as
> an element. The trick would be for the fields of its component elements to be
> summed but its contribution to the overall sum to be limited to 1. Like the
> other enclosed elements, the radius field could be reversed to subtract the
> shape of the pre-defined object element from the rest.
> 
> The radii of elements in a rounded object do not have to be the same and I think
> that, if the surface count was not an integer it may be possible to swell or
> shrink the object by an amount less than the corner radius.
> 
> Am I thinking on the right lines?
> 
> 
>

Post a reply to this message

O> As each ray chugs through design space it will need to know its 
distance from
> each of these planes and on which side it is. Associated with each plane is a
> "field" which has the value of 1 at distances greater than the corner radius
> from the inside and -1 at distances greater than the same distance outside.
> Between these two the strength of the field follows a sine curve, going through
> zero at the plane itself. The field values of all the elements are summed. (The
> calculation might be faster with cubic; the corners would not be exactly
> circular, but would anyone notice or care?)
>
> A simple tetrahedral rounded object can be created with four plane elements. The
> ray decides it has encountered a surface when the sum of the field values is
> greater than the surface count number, which, in this case is 3. In general, for
> convex polyhedra, it would be one less than the number of plane elements.

Could you use an isosurface to test out this idea?

It actually sounds similar to distance field rendering which is used a 
lot in real-time raytracing. Once you have the distance fields then it's 
easy to do a "smooth union" between shapes:

http://www.iquilezles.org/www/articles/smin/smin.htm

Note that there are two distinct types of "round" being discussed, it's 
important not to confuse them. The first is the "CAD" type of perfect 
round that is formed by conceptually rolling a sphere (of radius equal 
to the round you want) along the edge. The second is this type of 
"artistic" round that smoothly blends the two shapes, but is not 
necessarily possible to accurately specify the round radius (or it might 
not even be constant throughout the round).

Post a reply to this message

> O> As each ray chugs through design space it will need to know its
> distance from
>> each of these planes and on which side it is. Associated with each
>> plane is a
>> "field" which has the value of 1 at distances greater than the corner
>> radius
>> from the inside and -1 at distances greater than the same distance
>> outside.
>> Between these two the strength of the field follows a sine curve,
>> going through
>> zero at the plane itself. The field values of all the elements are
>> summed. (The
>> calculation might be faster with cubic; the corners would not be exactly
>> circular, but would anyone notice or care?)
>>
>> A simple tetrahedral rounded object can be created with four plane
>> elements. The
>> ray decides it has encountered a surface when the sum of the field
>> values is
>> greater than the surface count number, which, in this case is 3. In
>> general, for
>> convex polyhedra, it would be one less than the number of plane elements.
>
> Could you use an isosurface to test out this idea?
>

You may do a blobbing of the intersection of four planes to get a 
rounded tetrahedron, of six planes for a rounded box,...
Possible, done before and relatively slow.

Post a reply to this message

scott <sco### [at] scottcom> wrote:

> It actually sounds similar to distance field rendering which is used a
> lot in real-time raytracing. Once you have the distance fields then it's
> easy to do a "smooth union" between shapes:
>
> http://www.iquilezles.org/www/articles/smin/smin.htm

Alain wrote:
> You may do a blobbing of the intersection of four planes to get a
> rounded tetrahedron, of six planes for a rounded box,...
> Possible, done before and relatively slow.

I think this means that what I am suggesting is feasible, and indeed already
do-able to a limited extent.

However both the blob definition and isosurfaces are for me non-intuitve.

Take the tetrahedron for example, I will probably know where I want the four
vertices to be, so defining each of the four rounded_object plane elements with
three vectors is simple. Writing it as a set of equasions needs a bit of
pondering, which is what computers are for.

I can see how blob definition has been written in its simplest form by
programmers, but for the user it would be much more convenient to input the
radius of the sphere that would be seen in isolation and the distance the field
extends beyond this. I know these relate to the actual input parameters by very
simple arithmetic, which is also is what computers are for.

Of course calculating field strengths is going to slow things down, but would it
be possible to be able to have a fast mode where this left out and the object
rendered with sharp corners?

I think implementing rounded-object with just planes, cylinders and spheres
would not be that difficult and would give:
- an immediate improvement in usability.
- Individual radii for planes would enable a significant new repertoire of
rounded shapes.
- Rounded objects as elements would extend this
- sphere sweep elements would be amazing.

scott <sco### [at] scottcom> wrote:

> Note that there are two distinct types of "round" being discussed, it's
> important not to confuse them. The first is the "CAD" type of perfect
> round that is formed by conceptually rolling a sphere (of radius equal
> to the round you want) along the edge. The second is this type of
> "artistic" round that smoothly blends the two shapes, but is not
> necessarily possible to accurately specify the round radius (or it might
> not even be constant throughout the round).

My point exactly when I wrote:

> >(The calculation might be faster with cubic; the corners would not be exactly
> > circular, but would anyone notice or care?)

Maybe we could go further and, with an extra optional parameter, change the
profile of the rounding from a rounded bevel to a "V" shape?

Post a reply to this message

>
> I can see how blob definition has been written in its simplest form by
> programmers, but for the user it would be much more convenient to input the
> radius of the sphere that would be seen in isolation and the distance the field
> extends beyond this. I know these relate to the actual input parameters by very
> simple arithmetic, which is also is what computers are for.

This will only work for non-interacting blob elements. Whenever two or 
more elements interact, the location of the surface will get pushed away 
from that location. It can be pushed inward or outward depending on the 
strength of each component. Remember that a blob component can have a 
negative strength.

>
> Of course calculating field strengths is going to slow things down, but would it
> be possible to be able to have a fast mode where this left out and the object
> rendered with sharp corners?

The actual rounded "primitives" are really unions of several shapes.
The rounded box use no less that 7 boxes, 12 cylinders and 8 spheres.
The rounded cylinder and cone use 2 cylinders and 2 torus, or a cylinder 
and 2 spheres.
They have the normal, union, mode and the merge mode for use with 
transparent textures where you don't want the inner surfaces to mess up 
things.

>
> I think implementing rounded-object with just planes, cylinders and spheres
> would not be that difficult and would give:
> - an immediate improvement in usability.
I don't think so.

> - Individual radii for planes would enable a significant new repertoire of
> rounded shapes.
A plane is a plane, a simple surface extending to infinity, it have no 
roundness. In POV-Ray, a plane have the geometric definition of a plane: 
An infinite, infinitely thin, surface dividing space in two: above and 
under.

> - Rounded objects as elements would extend this
> - sphere sweep elements would be amazing.

The sphere_sweep primitive exist and is far from trivial, even for 
linear sweeps. Adding blobbing or rounded edges would be absolutely 
nightmarish.
How would you round the edge of an irregular twisting tube and a plane, 
given that the tube can have a variable curvature,  radius and elevation 
over the plane, can travel under the plane or above.
Except in the most trivial cases, you can't make an isosurface 
equivalent of the sphere_sweep.

>
> scott <sco### [at] scottcom> wrote:
>
>> Note that there are two distinct types of "round" being discussed, it's
>> important not to confuse them. The first is the "CAD" type of perfect
>> round that is formed by conceptually rolling a sphere (of radius equal
>> to the round you want) along the edge. The second is this type of
>> "artistic" round that smoothly blends the two shapes, but is not
>> necessarily possible to accurately specify the round radius (or it might
>> not even be constant throughout the round).
>
> My point exactly when I wrote:
>
>>> (The calculation might be faster with cubic; the corners would not be exactly
>>> circular, but would anyone notice or care?)
>
> Maybe we could go further and, with an extra optional parameter, change the
> profile of the rounding from a rounded bevel to a "V" shape?
>
>
>
>

Post a reply to this message

> scott <sco### [at] scottcom> wrote:
>
>> Note that there are two distinct types of "round" being discussed, it's
>> important not to confuse them. The first is the "CAD" type of perfect
>> round that is formed by conceptually rolling a sphere (of radius equal
>> to the round you want) along the edge. The second is this type of
>> "artistic" round that smoothly blends the two shapes, but is not
>> necessarily possible to accurately specify the round radius (or it might
>> not even be constant throughout the round).
>
> My point exactly when I wrote:
>
>>> (The calculation might be faster with cubic; the corners would not be exactly
>>> circular, but would anyone notice or care?)
>
> Maybe we could go further and, with an extra optional parameter, change the
> profile of the rounding from a rounded bevel to a "V" shape?

I don't think the method you are suggesting is capable of generating 
correct rounds (with constant radius curvature and tangent to both 
faces) nor creating a constant "V" profile (a bevel). But willing to be 
proved wrong, give it a go with some simple shapes and isosurfaces/blobs 
and see what you get. If you're on to something then some working 
example code will go *far* further than just a text description.

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> > scott <sco### [at] scottcom> wrote:
> >
> >> Note that there are two distinct types of "round" being discussed, it's
> >> important not to confuse them. The first is the "CAD" type of perfect
> >> round that is formed by conceptually rolling a sphere (of radius equal
> >> to the round you want) along the edge. The second is this type of
> >> "artistic" round that smoothly blends the two shapes, but is not
> >> necessarily possible to accurately specify the round radius (or it might
> >> not even be constant throughout the round).
> >
> > My point exactly when I wrote:
> >
> >>> (The calculation might be faster with cubic; the corners would not be exactly
> >>> circular, but would anyone notice or care?)
> >
> > Maybe we could go further and, with an extra optional parameter, change the
> > profile of the rounding from a rounded bevel to a "V" shape?
>
> I don't think the method you are suggesting is capable of generating
> correct rounds (with constant radius curvature and tangent to both
> faces) nor creating a constant "V" profile (a bevel). But willing to be
> proved wrong, give it a go with some simple shapes and isosurfaces/blobs
> and see what you get. If you're on to something then some working
> example code will go *far* further than just a text description.

Totally agree, I am working on it.

The aim is for a tangent at both ends with a smooth curve in between. A constant
radius is only needed in CAD to specify the shape of a real thing. Here, if it
looks good. it is good.

Post a reply to this message

Alain <kua### [at] videotronca> wrote:

> Except in the most trivial cases, you can't make an isosurface
> equivalent of the sphere_sweep.

What about:

http://www.econym.demon.co.uk/isotut/splines.htm

?

Post a reply to this message

> > If you're on to something then some working
> > example code will go *far* further than just a text description.
>
> Totally agree, I am working on it.

And here it is:

// This work is licensed under the Creative Commons Attribution 3.0 Unported
License.
// To view a copy of this license, visit
http://creativecommons.org/licenses/by/3.0/
// or send a letter to Creative Commons, 444 Castro Street, Suite 900, Mountain
View,
// California, 94041, USA.

// Demonstration of plane elements for rounded objects

// Vers: 1.00
// Date: 17 Sept 2016
// Auth: John Greenwood

#version 3.7 ;

#include "colors.inc"

camera {location <10,10,10> angle 30 look_at <0,0,0> }

  background { color rgb<0.2, 0.4, 0.8>  }
  light_source {<10,20,5> color White}
  global_settings {assumed_gamma 1.0 }

  #declare Corner_Profile = -.5;   // -.5 gives rounded bevel, 0 almost round,
+.5 Not noticebly sharper
  #declare Corner_round = 1;

  #declare R_plane = function( X,r,s){

select((X>r)-(X<-r),2*(r<0)-1,s*pow(X/r,5)-(2*s+.5)*pow(X/r,3)+(1.5+s)*X/r,1-2*(r<0))
                                     }
  isosurface {
     function {
               R_plane(x+1.5,-Corner_round,Corner_Profile)
              +R_plane(x-1.5,+Corner_round,Corner_Profile)
              +R_plane(y-1.5, Corner_round,Corner_Profile)
              +R_plane(y+1.5,-Corner_round,Corner_Profile)
              +R_plane(z-1.5,+Corner_round,Corner_Profile)
              +R_plane(z+1.5,-Corner_round,Corner_Profile)
              }
     threshold -5


      max_gradient 6
    contained_by { box { -2, 2 } }
 texture {
  pigment {color rgb < 1, 0.9, 0.65>}
  }
  }

/**
// Example 1. Notes: changing the threshold does have the effect of
shrinking/swelling the object. Corner_round = 1.5 Corner_Profile = -.5 gives a
rounded octrahedron
     function {
               R_plane(x+1.5,-Corner_round,Corner_Profile)
              +R_plane(x-1.5,+Corner_round,Corner_Profile)
              +R_plane(y-1.5, Corner_round,Corner_Profile)
              +R_plane(y+1.5,-Corner_round,Corner_Profile)
              +R_plane(z-1.5,+Corner_round,Corner_Profile)
              +R_plane(z+1.5,-Corner_round,Corner_Profile)
              }
     threshold -5
// Example 2. Demonstrates not all the same corner profile
     function {
               R_plane(x-1.5,+.5,0)
              +R_plane(x+1.5,-2,0)
              +R_plane(y-1.5, 1,-.5)
              +R_plane(y+1.5,-1,-.5)
              +R_plane(z-1.5,+1,-.5)
              +R_plane(z+1.5,-1,-.5)
              }
     threshold -5
//Example 3. Five planes, not all othogonal
     function {
               R_plane(x+1.5,-Corner_round,Corner_Profile)
              +R_plane(x-1.5,+Corner_round,Corner_Profile)
              +R_plane(y+1.5,-Corner_round,Corner_Profile)
              +R_plane(y+z-1,+Corner_round,Corner_Profile)
              +R_plane(z+1.5,-Corner_round,Corner_Profile)
              }
     threshold -4
//Example 4. Corner definitions can be variable: Round
     function {
               R_plane(x+1.5,-.5,Corner_Profile)
              +R_plane(x-1.5,+1.5,Corner_Profile)
              +R_plane(y-1.5, Corner_round+.5*x,Corner_Profile)
              +R_plane(y+1.5,-Corner_round-.5*x,Corner_Profile)
              +R_plane(z-1.5,+Corner_round+.5*x,Corner_Profile)
              +R_plane(z+1.5,-Corner_round-.5*x,Corner_Profile)
              }
     threshold -5

//Example 5. Corner definitions can be variable: profile
     function {
               R_plane(x+1.5,-.4,0)
              +R_plane(x-1.5,+.4,0)
              +R_plane(y-1.5, Corner_round,Corner_Profile*x)
              +R_plane(y+1.5,-Corner_round,Corner_Profile*x)
              +R_plane(z-1.5,+Corner_round,Corner_Profile*x)
              +R_plane(z+1.5,-Corner_round,Corner_Profile*x)
              }
     threshold -5

*/

Post a reply to this message