Gerome, this one primarily goes out to you:

I've just come across the documentation of the "ovus" primitive, and am
a bit puzzled.

The parameters of the top and bottom sphere are clear enough.

However, what I don't understand is how the major and minor radii of the
connecting spindle section are determined; theoretically we should have
an infinite number of different spindles to choose from.

This can be easily demonstrated by examining the extreme cases:

- Given any two spheres, there is always (except in pathological cases)
exactly one cone that fully envelopes both spheres and touches each of
them in a circle; connecting the spheres with the cone section between
the circles of contact obviously gives us a shape with continuous slope;
note that any cone can be interpreted as a spindle degenerated to
infinite size.

- Given any two spheres, there is also always (again except in
pathological cases) exactly one sphere that fully envelops both spheres
and touches each of then in a single point; connecting the spheres with
this outer sphere also obviously gives us a shape with continuous slope;
note that any sphere can also be interpreted as a spindle.

Between these two cases lies an infinite spectrum of possible choices
for the spindle. So how is the spindle chosen, and why that particular one?

Post a reply to this message

Le 03/05/2016 00:37, clipka a écrit :
> Gerome, this one primarily goes out to you:
>
> I've just come across the documentation of the "ovus" primitive, and am
> a bit puzzled.
>
> The parameters of the top and bottom sphere are clear enough.
>
> However, what I don't understand is how the major and minor radii of the
> connecting spindle section are determined; theoretically we should have
> an infinite number of different spindles to choose from.
>

The minor radius of the spindle is twice the biggest radius of the 
circles. (in code : ConnectingRadius).

The major radius of the spindle is implicit, as only the position of the 
center of the circle of the torus is computed. (in 2D)

The choice of the minor radius (biggest circle x 2) is so that when the 
smaller radius would disappear (aka be near 0), the remaining sphere and 
the spindle would merge. (well, in fact, the visible part of the spindle 
would also disappears, without discontinuity)

> This can be easily demonstrated by examining the extreme cases:
>
> - Given any two spheres, there is always (except in pathological cases)
> exactly one cone that fully envelopes both spheres and touches each of
> them in a circle; connecting the spheres with the cone section between
> the circles of contact obviously gives us a shape with continuous slope;
> note that any cone can be interpreted as a spindle degenerated to
> infinite size.
>
> - Given any two spheres, there is also always (again except in
> pathological cases) exactly one sphere that fully envelops both spheres
> and touches each of then in a single point; connecting the spheres with
> this outer sphere also obviously gives us a shape with continuous slope;
> note that any sphere can also be interpreted as a spindle.
>
> Between these two cases lies an infinite spectrum of possible choices
> for the spindle. So how is the spindle chosen, and why that particular one?
>

Post a reply to this message

Am 04.05.2016 um 08:49 schrieb Le_Forgeron:
> Le 03/05/2016 00:37, clipka a écrit :
>> Gerome, this one primarily goes out to you:
>>
>> I've just come across the documentation of the "ovus" primitive, and am
>> a bit puzzled.
>>
>> The parameters of the top and bottom sphere are clear enough.
>>
>> However, what I don't understand is how the major and minor radii of the
>> connecting spindle section are determined; theoretically we should have
>> an infinite number of different spindles to choose from.
>>
> 
> The minor radius of the spindle is twice the biggest radius of the
> circles. (in code : ConnectingRadius).
> 
> The major radius of the spindle is implicit, as only the position of the
> center of the circle of the torus is computed. (in 2D)
> 
> The choice of the minor radius (biggest circle x 2) is so that when the
> smaller radius would disappear (aka be near 0), the remaining sphere and
> the spindle would merge. (well, in fact, the visible part of the spindle
> would also disappears, without discontinuity)

I just pondered about these words for a while, puzzled, until I realized
that there is another parameter we don't have control over: The distance
between the two spheres. According to the docs this is fixed to the
radius of the bottom sphere, right? (Does this also hold true if the
bottom radius is the smaller one?)

I have a few requests:

(1) Can you update the documentation to include...
(1.a) how the radius of the spindle is computed;
(1.b) the fact(?) that the bottom sphere is always placed at <0,0,0>

(2) Do you think you can extend the code to allow for more flexibility
in the shape, by letting us specify the distance between the two spheres
as well as the minor radius of the spindle?

Post a reply to this message

Le 04/05/2016 14:24, clipka a écrit :
> Am 04.05.2016 um 08:49 schrieb Le_Forgeron:
>> Le 03/05/2016 00:37, clipka a écrit :
>>> Gerome, this one primarily goes out to you:
>>>
>>> I've just come across the documentation of the "ovus" primitive, and am
>>> a bit puzzled.
>>>
>>> The parameters of the top and bottom sphere are clear enough.
>>>
>>> However, what I don't understand is how the major and minor radii of the
>>> connecting spindle section are determined; theoretically we should have
>>> an infinite number of different spindles to choose from.
>>>
>>
>> The minor radius of the spindle is twice the biggest radius of the
>> circles. (in code : ConnectingRadius).
>>
>> The major radius of the spindle is implicit, as only the position of the
>> center of the circle of the torus is computed. (in 2D)
>>
>> The choice of the minor radius (biggest circle x 2) is so that when the
>> smaller radius would disappear (aka be near 0), the remaining sphere and
>> the spindle would merge. (well, in fact, the visible part of the spindle
>> would also disappears, without discontinuity)
>
> I just pondered about these words for a while, puzzled, until I realized
> that there is another parameter we don't have control over: The distance
> between the two spheres. According to the docs this is fixed to the
> radius of the bottom sphere, right? (Does this also hold true if the
> bottom radius is the smaller one?)
>
> I have a few requests:
>
> (1) Can you update the documentation to include...
> (1.a) how the radius of the spindle is computed;
> (1.b) the fact(?) that the bottom sphere is always placed at <0,0,0>
>

the documentation is in the wiki, right ? So anyone could update it to 
add these element. I thought 1.b was already in the documentation.


> (2) Do you think you can extend the code to allow for more flexibility
> in the shape, by letting us specify the distance between the two spheres
> as well as the minor radius of the spindle?
>

I would not clobber the actual object with such extension, but I might 
consider a new object (along the line of sor & lathe). The main "beauty" 
of ovus is being similar to torus, and simple.
Can you provide a new name for such new beast ?
(which might be half-way to something similar to the polynomial equation 
of a torus with displaced hole, and maybe more than one hole)
(just to say that it is more complex object)

And may be some suggestion for the syntax ?
About being doable, yes, I can (but there will be additional constraints 
on the values, such a minimal minor radius function of the three other 
distances under which you would get an error)
And do you expect default values for some parameters too ? (yet more 
syntax sugar... )

Post a reply to this message

Am 04.05.2016 um 16:43 schrieb Le_Forgeron:

>> I have a few requests:
>>
>> (1) Can you update the documentation to include...
>> (1.a) how the radius of the spindle is computed;
>> (1.b) the fact(?) that the bottom sphere is always placed at <0,0,0>
> 
> the documentation is in the wiki, right ? So anyone could update it to
> add these element. I thought 1.b was already in the documentation.

Guess what -- I'm a bit busy documenting all the stuff I've added since
3.7.0 ;)
Also, I thought you might have produced the original 2D sketch, and
might be the person most fit to add the minor spindle radius to it.

You're right about 1.b though.


>> (2) Do you think you can extend the code to allow for more flexibility
>> in the shape, by letting us specify the distance between the two spheres
>> as well as the minor radius of the spindle?
> 
> I would not clobber the actual object with such extension, but I might
> consider a new object (along the line of sor & lathe). The main "beauty"
> of ovus is being similar to torus, and simple.
> Can you provide a new name for such new beast ?

I think the ovus primitive is the perfect place to put these extensions;
after all, I'm sure the ability to tweak these parameters will give us
better results when trying to approximate true egg shapes.

Also, my guess would be that such an extended shape would share a lot of
code with the existing one. The only major things that would need to be
changed are the parameters to compute the radii relevant for the
spindle, and the "altitudes" at which the spindle and spheres meet.
(Though I might of course be wrong, as I haven't looked at the actual
implementation yet.)

Not to mention that finding a really good alternative name for the new
beast is non-trivial, while "ovus" would fit perfectly.

> About being doable, yes, I can (but there will be additional constraints
> on the values, such a minimal minor radius function of the three other
> distances under which you would get an error)

Of course such constraint checks would be part of the deal.

> And do you expect default values for some parameters too ? (yet more
> syntax sugar... )

Since I'd advocate to put it into the ovus primitive, of course the
default values would be Bottom_radius for the Y coordinate of the top
sphere, and 2*max(Bottom_radius,Top_radius).

Post a reply to this message

Am 04.05.2016 um 17:42 schrieb clipka:

>> I would not clobber the actual object with such extension, but I might
>> consider a new object (along the line of sor & lathe). The main "beauty"
>> of ovus is being similar to torus, and simple.
>> Can you provide a new name for such new beast ?
> 
> I think the ovus primitive is the perfect place to put these extensions;
> after all, I'm sure the ability to tweak these parameters will give us
> better results when trying to approximate true egg shapes.

BTW, if you're worried that the extensions might seriously impact
performance (which I doubt), you might have a look at the "torus"
primitive, which currently maps to two different C++ objects depending
on the parameters chosen: "Torus" for the standard case, and
"SpindleTorus" for the case of a self-intersecting torus.

Post a reply to this message

Le 04/05/2016 17:47, clipka a écrit :
> Am 04.05.2016 um 17:42 schrieb clipka:
> 
>>> I would not clobber the actual object with such extension, but I might
>>> consider a new object (along the line of sor & lathe). The main "beauty"
>>> of ovus is being similar to torus, and simple.
>>> Can you provide a new name for such new beast ?
>>
>> I think the ovus primitive is the perfect place to put these extensions;
>> after all, I'm sure the ability to tweak these parameters will give us
>> better results when trying to approximate true egg shapes.
> 
> BTW, if you're worried that the extensions might seriously impact
> performance (which I doubt), you might have a look at the "torus"
> primitive, which currently maps to two different C++ objects depending
> on the parameters chosen: "Torus" for the standard case, and
> "SpindleTorus" for the case of a self-intersecting torus.
> 

Actually I was more thinking about other possible extension(s), like "open"
which could remove the spheres (a non-sense for ovus, per definition).

Why would I remove the spheres ? Well... with more parameters, and maybe a more
sexy syntax, it could come as an handy "arm"/"leg"/... object or part, in something
like a sphere_sweep. So to avoid coincident surfaces (and reduces the number of
objects ?),
it could be something like (think "cylinder" vs "torus")

sphere { P1, R1 }
limbs { P1, R1, P2, R2 , SR12 open } // distance between spheres is vlength(P2-P1)
sphere { P2, R2 }
limbs { P2, R2, P3, R3, SR23 open }
sphere { P3, R3 } // and so on

Px are points, Rx are radius, SRxy are spindle radius

And maybe, while we are at it, a function (for SDL) to compute the minimal radius of
the spindle

Post a reply to this message

Le 04/05/2016 18:14, Le_Forgeron a écrit :
> Le 04/05/2016 17:47, clipka a écrit :
>> Am 04.05.2016 um 17:42 schrieb clipka:
>>
>>>> I would not clobber the actual object with such extension, but I might
>>>> consider a new object (along the line of sor & lathe). The main "beauty"
>>>> of ovus is being similar to torus, and simple.
>>>> Can you provide a new name for such new beast ?
>>>
>>> I think the ovus primitive is the perfect place to put these extensions;
>>> after all, I'm sure the ability to tweak these parameters will give us
>>> better results when trying to approximate true egg shapes.
>>
>> BTW, if you're worried that the extensions might seriously impact
>> performance (which I doubt), you might have a look at the "torus"
>> primitive, which currently maps to two different C++ objects depending
>> on the parameters chosen: "Torus" for the standard case, and
>> "SpindleTorus" for the case of a self-intersecting torus.
>>
> 
> Actually I was more thinking about other possible extension(s), like "open"
> which could remove the spheres (a non-sense for ovus, per definition).
> 
> Why would I remove the spheres ? Well... with more parameters, and maybe a more
> sexy syntax, it could come as an handy "arm"/"leg"/... object or part, in something
> like a sphere_sweep. So to avoid coincident surfaces (and reduces the number of
objects ?),
> it could be something like (think "cylinder" vs "torus")
> 
> sphere { P1, R1 }
> limbs { P1, R1, P2, R2 , SR12 open } // distance between spheres is vlength(P2-P1)
> sphere { P2, R2 }
> limbs { P2, R2, P3, R3, SR23 open }
> sphere { P3, R3 } // and so on
> 
> Px are points, Rx are radius, SRxy are spindle radius
> 
> And maybe, while we are at it, a function (for SDL) to compute the minimal radius of
the spindle
> 

I said "limbs", but it might also be some "bead" (olive), "barrel" (especially the
open variation could be
fine to make barrel shape... just that open then would be a misname, unless we drop
the sphere forever and
open behave like "cone")... and some native English speakers are welcome to contribute

what it might looks like (without the spheres at the ends, and not pierced):

http://media.cdnws.com/_i/10753/m840-4466/2220/70/3aut0048olivefilament.jpeg

Post a reply to this message

Am 04.05.2016 um 18:14 schrieb Le_Forgeron:

> Actually I was more thinking about other possible extension(s), like "open"
> which could remove the spheres (a non-sense for ovus, per definition).
> 
> Why would I remove the spheres ? Well... with more parameters, and maybe a more
> sexy syntax, it could come as an handy "arm"/"leg"/... object or part, in something
> like a sphere_sweep. So to avoid coincident surfaces (and reduces the number of
objects ?),
> it could be something like (think "cylinder" vs "torus")

That could be considered an entirely different game: It would no longer
be an ovus, but a mere subsection of a spindle. (*)

As of the current POV-Ray 3.7.1 development releases, I would consider
it more fitting to implement such a shape as a CSG macro, based on a
self-intersecting torus with the "intersection" keyword (a new feature
in POV-Ray 3.7.1), cut to shape using an intersection or clipped_by.

Actually, if the ovus didn't already exist now, I'd say there is no need
for such a dedicated shape (anymore); but since it is around already, it
would be neat to add a bit more flexibility.

(*) On the other hand, it could still be considered an extension to the
ovus, as in "an ovus, but don't give me the spheres because I already
have them"; most notably, the parameterization, as you envision it,
would still be based on the concept of an ovus; also, it would make a
lot of sense in terms of implementation, because all you'd have to do
would be to suppress the spherical portions.

> And maybe, while we are at it, a function (for SDL) to compute the minimal radius of
the spindle

That would /definitely/ a job for an include file -- if it wasn't
pointless anyway: The minimal radius of the spindle is /always/ the
distance between the spheres plus their radii: The value at which it
degenerates to a sphere.

Post a reply to this message

Am 04.05.2016 um 18:46 schrieb Le_Forgeron:

> I said "limbs", but it might also be some "bead" (olive), "barrel" (especially the
open variation could be
> fine to make barrel shape... just that open then would be a misname, unless we drop
the sphere forever and
> open behave like "cone")... and some native English speakers are welcome to
contribute

"ogive" (no, not "olive" ;)) might be a suitable term, though our
ovus-without-spheres object would be a slightly more generalized shape
(even the most generic variant of a true ogive still has one pointed end).

I'd be really reluctant to make the parameterization of such an object
fit a special use case such as limbs; parameterization of primitives
should generally be linked to the underlying mathematical representation
in a straightforward manner, and any use-case-specific parameterization
should be done via macros; that's what they are for.

As another consequence, in the absence of an "open" keyword the ends of
such a shape should not be spherical, but planar.

Post a reply to this message