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

On 05/04/2016 03:19 PM, clipka wrote:
> Am 04.05.2016 um 18:14 schrieb Le_Forgeron:
>
...
>
> (*) 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.
>

My thoughts - while probably not following you both completely. Also 
being more interested in getting at the inner citrus shape than having 
more flexible egg/ovus shapes.

I vote for providing access to the citrus shape as an extension to the 
ovus given we have the ovus today - at least as seen by us users. 
Perhaps too we should continue calling it the citrus shape of the ovus 
given it has been introduced as such already. Though certainly other 
names, like those suggested, would be more descriptive for such a shape 
standing apart.

Aside: I played some with this inner shape as an isosurface some while 
back on seeing the ovus introduced. It looked a useful base 
shape/function. However, the sharp points on the end drive up the 
isosurface time considerably, so having other access to this shape would 
be cool.

When we want:

1) the full citrus shape. Would we specify a length directly or do this 
by specifying the distance between the two spheres and both radii as 
zero or nearly zero?

2) the citrus shape clipped equally on both ends - the barrel shape. 
Would we specify a distance between spheres, both radii the same and 
then to drop both spheres from the result?

3) the citrus shape clipped at one end -an ogive or bullet. We'd do 
something like (2), but be able to drop just the larger sphere while the 
other sphere stays with a near zero radius out at the end of the citrus?

4) the citrus shape clipped unequally... Is this doable at all as a 
give-me-the-citrus extension to the ovus? It looks to me like the clip 
to the larger sphere happens perpendicular to the origin of that sphere, 
but the clip to the smaller sphere is somehow calculated & not clear to 
me how?

Bill P.

Post a reply to this message

Am 05.05.2016 um 15:15 schrieb William F Pokorny:

> I vote for providing access to the citrus shape as an extension to the
> ovus given we have the ovus today - at least as seen by us users.
> Perhaps too we should continue calling it the citrus shape of the ovus
> given it has been introduced as such already. Though certainly other
> names, like those suggested, would be more descriptive for such a shape
> standing apart.

I can only assume that the term "citrus" was introduced as a
description, not a technical term, and I strongly discourage its use in
this sense. As a matter of fact, in mathematics the term "citrus" is
already in use for a different shape.

The proper technical term would be "lemon", while I've been using the
term "spindle" instead, owing to the fact that it is the inside surface
of a "spindle torus".


> When we want:
> 
> 1) the full citrus shape. Would we specify a length directly or do this
> by specifying the distance between the two spheres and both radii as
> zero or nearly zero?

For the full shape, you would simply use

    torus { R1, R2 intersection }

with classic torus parameters for R1 and R2 (with R2>R1). Some
trigonometry may be required to compute these from some other
parameterization such as the distance between the tips and the "equator"
radius.

This syntax will be supported in 3.7.1, and has already been available
in dev releases for quite a while (though I think I didn't make much
noise about it).

> 2) the citrus shape clipped equally on both ends - the barrel shape.
> Would we specify a distance between spheres, both radii the same and
> then to drop both spheres from the result?

That depends on what syntax we eventually end up with ;)

> 3) the citrus shape clipped at one end -an ogive or bullet. We'd do
> something like (2), but be able to drop just the larger sphere while the
> other sphere stays with a near zero radius out at the end of the citrus?

I'm quite sure that would be a special case of 2).

> 4) the citrus shape clipped unequally... Is this doable at all as a
> give-me-the-citrus extension to the ovus? It looks to me like the clip
> to the larger sphere happens perpendicular to the origin of that sphere,
> but the clip to the smaller sphere is somehow calculated & not clear to
> me how?

In the current ovus implementation, the transition between the lower
sphere and the lemon actually does /not/ coincide with the equator of
the lower sphere (except for very specific selections of parameters),
even though /some/ of the sample images seem to imply that.

Post a reply to this message

Le 04/05/2016 17:42, clipka a écrit :
>>> (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.
> 
> 

I updated the wiki to drop "citrus", both on text and 3D image.

For the 2D sketch, I would need to remake it from scratch to better illustrate the
point
of the center being elsewhere... as well as the connection being not on the x-axis.

I might actually illustrate that better
with a large picture, I'm afraid.

Post a reply to this message

Maybe it should be called the "rind"    :D

Post a reply to this message

On 5/6/2016 12:22 PM, Bald Eagle wrote:
> Maybe it should be called the "rind"    :D
>
>
I would go for the Scots word "Peerie" as in whip and peerie (a child's 
spinning top).
It can also mean small.


-- 

Regards
     Stephen

Post a reply to this message

On 05/05/2016 11:53 AM, clipka wrote:
> I can only assume that the term "citrus" was introduced as a
> description, not a technical term, and I strongly discourage its use in
> this sense. As a matter of fact, in mathematics the term "citrus" is
> already in use for a different shape.
>
> The proper technical term would be "lemon", while I've been using the
> term "spindle" instead, owing to the fact that it is the inside surface
> of a "spindle torus".

Thanks Christoph. I wrongly assumed it was the citrus surface in use 
with the ovus due the documentation's use of the term. I used for my 
isosurface play the citrus surface equation at:

  http://mathworld.wolfram.com/Lemon.html

not the lemon surface.

Bill P.

Post a reply to this message

Correct me if I'm wrong, but does Wolfram have the 2D cross-sectional diagrams
(on the right) switched for the spindle and horn tori?

http://mathworld.wolfram.com/SpindleTorus.html
http://mathworld.wolfram.com/HornTorus.html

Post a reply to this message

Le 06/05/2016 16:13, Bald Eagle a écrit :
> Correct me if I'm wrong, but does Wolfram have the 2D cross-sectional diagrams
> (on the right) switched for the spindle and horn tori?
>
> http://mathworld.wolfram.com/SpindleTorus.html
> http://mathworld.wolfram.com/HornTorus.html

Yes, you are correct. the slice is correct, but the 3D in the middle are 
switched.

Post a reply to this message

Le 04/05/2016 à 17:42, clipka a écrit :
>> > 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).
>

back to that subject... finding a suitable syntax, backward compatible 
with existing syntax.

So far :

   ovus { Bottom_radius, Top_radius }

0 <= Bottom_radius
0 <= Top_radius <= 2*Bottom_radius

(when TopRadius > 2*BottomRadius, object is replaced by a sphere)

Additional parameters:

   InnerRadius (default to 2 * max( Bottom_radius, Top_radius )

   Distance_between_spheres (default to Bottom_radius )

0 <= Bottom_radius
0 <= Top_radius
0 <= Distance_between_spheres (Bottom is at <0,0,0>,
   but Top is at <0, Distance_between_spheres, 0> instead
   of <0, Bottom_radius, 0>

complex relation for InnerRadius vs its minimal value.

If it was only for one additional parameter the obvious syntax would 
have been:

   ovus { Bottom_radius, Top_radius [, extra_value ] }


Please provide some suggestions about an acceptable syntax.

Post a reply to this message

Am 25.05.2016 um 14:06 schrieb Le_Forgeron:

> If it was only for one additional parameter the obvious syntax would
> have been:
> 
>   ovus { Bottom_radius, Top_radius [, extra_value ] }
> 
> 
> Please provide some suggestions about an acceptable syntax.

How about

    ovus { Bottom_radius, Top_radius [, extra_value1, extra_value2 ] }

? ;)

Post a reply to this message

Le 25/05/2016 20:05, clipka a écrit :
> Am 25.05.2016 um 14:06 schrieb Le_Forgeron:
> 
>> If it was only for one additional parameter the obvious syntax would
>> have been:
>>
>>   ovus { Bottom_radius, Top_radius [, extra_value ] }
>>
>>
>> Please provide some suggestions about an acceptable syntax.
> 
> How about
> 
>     ovus { Bottom_radius, Top_radius [, extra_value1, extra_value2 ] }
> 
> ? ;)
> 
Yes... but which one is or should be the first ? (or which one should be the second,
less used) ?

Post a reply to this message

On 05/25/2016 08:06 AM, Le_Forgeron wrote:
> Le 04/05/2016 à 17:42, clipka a écrit :
>
> Please provide some suggestions about an acceptable syntax.

Forgive me for being slow to understand, but is the 
lemon/barrel/ogive(1) then going to be added as new object and the 
current ovus made at little more flexible - rather than folding all the 
function recently discussed into one object?

Guess, my thinking is if we are doing the new barrel object, we can 
duplicate the new ovus function for which we need syntax by adding 
spheres to the end of the new lemon/barrel/ogive.

Suppose taking it the other way around, if we update the ovus only, 
nothing stops us from chopping off the ends to match the 
lemon/barrel/ogive. Though we'd not have the 'open' mode that way.

(1) - Taking the barrel/ogive to be the improved ovus less the two end 
spheres ?

Bill P.

Post a reply to this message

Le 25/05/2016 21:50, William F Pokorny a écrit :
> On 05/25/2016 08:06 AM, Le_Forgeron wrote:
>> Le 04/05/2016 à 17:42, clipka a écrit :
>>
>> Please provide some suggestions about an acceptable syntax.
> 
> Forgive me for being slow to understand, but is the lemon/barrel/ogive(1) then going
to be added as new object and the current ovus made at little more flexible - rather
than folding all the function recently discussed into one object?
> 
> Guess, my thinking is if we are doing the new barrel object, we can duplicate the
new ovus function for which we need syntax by adding spheres to the end of the new
lemon/barrel/ogive.
> 
> Suppose taking it the other way around, if we update the ovus only, nothing stops us
from chopping off the ends to match the lemon/barrel/ogive. Though we'd not have the
'open' mode that way.
> 
> (1) - Taking the barrel/ogive to be the improved ovus less the two end spheres ?
> 
> Bill P.
> 

It is a bit more complex than that.

lemon is not an ovus without spheres, or rather, to use a manual lemon with additional
spheres to make an ovus, the computation is not simple. (no, you do not just put the
sphere at the vertex of lemon).
 ( And you get coincident surfaces problem too, and internal surfaces, useless
computations... things that are better handled in code than later in SDL. )

The same way that putting spheres at the ends of a conical frustum does not make a
nice segment of linear sphere_sweep.
It's easy with a cylinder, but become more subtle when the radius are different.

lemon is similar to cone, even a bit better: you can get a true lemon (mathematical
object), or a frustum of lemon. With SDL cone, you get a false mathematical cone or a
conical frustum (because a true cone would be infinite along its axis, both ways, and
povray's cone is
actually only a right circular cone, not all cones)

Post a reply to this message

On 05/25/2016 04:28 PM, Le_Forgeron wrote:
> Le 25/05/2016 21:50, William F Pokorny a écrit :
>>
>> (1) - Taking the barrel/ogive to be the improved ovus less the two end spheres ?
>>
>> Bill P.
>>
>
> It is a bit more complex than that.
>
> lemon is not an ovus without spheres, or rather, to use a manual lemon with
additional spheres to make an ovus, the computation is not simple. (no, you do not
just put the sphere at the vertex of lemon).
>   ( And you get coincident surfaces problem too, and internal surfaces, useless
computations... things that are better handled in code than later in SDL. )
>
> The same way that putting spheres at the ends of a conical frustum does not make a
nice segment of linear sphere_sweep.
> It's easy with a cylinder, but become more subtle when the radius are different.
>
> lemon is similar to cone, even a bit better: you can get a true lemon (mathematical
object), or a frustum of lemon. With SDL cone, you get a false mathematical cone or a
conical frustum (because a true cone would be infinite along its axis, both ways, and
povray's cone is
> actually only a right circular cone, not all cones)
>

Thanks for the detailed explanation.

If we will then have both an improved ovus and a new lemon/barrel/ogive 
object in 3.7.1, I would suggest adding the two new arguments for the 
ovus in the same order the equivalent information is given to the lemon 
in your mercurial "Hg-povray" code. Namely:

ovus { Bottom_radius, Top_radius [, sphere_to_sphere, inner_radius ] }

Bill P.

Post a reply to this message

Le 16-05-25 14:30, Le_Forgeron a écrit :
> Le 25/05/2016 20:05, clipka a écrit :
>> Am 25.05.2016 um 14:06 schrieb Le_Forgeron:
>>
>>> If it was only for one additional parameter the obvious syntax would
>>> have been:
>>>
>>>    ovus { Bottom_radius, Top_radius [, extra_value ] }
>>>
>>>
>>> Please provide some suggestions about an acceptable syntax.
>>
>> How about
>>
>>      ovus { Bottom_radius, Top_radius [, extra_value1, extra_value2 ] }
>>
>> ? ;)
>>
> Yes... but which one is or should be the first ? (or which one should be the second,
less used) ?
>

Both must be associated with a keyword.
It can be something like offset for the placement of the second sphere 
and link_radius or spindle_radius for the other one.


Alain

Post a reply to this message

Am 25.05.2016 um 20:30 schrieb Le_Forgeron:
> Le 25/05/2016 20:05, clipka a écrit :
>> Am 25.05.2016 um 14:06 schrieb Le_Forgeron:
>>
>>> If it was only for one additional parameter the obvious syntax would
>>> have been:
>>>
>>>   ovus { Bottom_radius, Top_radius [, extra_value ] }
>>>
>>>
>>> Please provide some suggestions about an acceptable syntax.
>>
>> How about
>>
>>     ovus { Bottom_radius, Top_radius [, extra_value1, extra_value2 ] }
>>
>> ? ;)
>>
> Yes... but which one is or should be the first ? (or which one should be the second,
less used) ?

It doesn't matter if you make it mandatory to either supply exactly two
parameters (the Bottom_radius and Top_radius) or exactly four (all the
parameters).

Post a reply to this message

Am 26.05.2016 um 15:52 schrieb Alain:
> Le 16-05-25 14:30, Le_Forgeron a écrit :
>> Le 25/05/2016 20:05, clipka a écrit :
>>> Am 25.05.2016 um 14:06 schrieb Le_Forgeron:
>>>
>>>> If it was only for one additional parameter the obvious syntax would
>>>> have been:
>>>>
>>>>    ovus { Bottom_radius, Top_radius [, extra_value ] }
>>>>
>>>>
>>>> Please provide some suggestions about an acceptable syntax.
>>>
>>> How about
>>>
>>>      ovus { Bottom_radius, Top_radius [, extra_value1, extra_value2 ] }
>>>
>>> ? ;)
>>>
>> Yes... but which one is or should be the first ? (or which one should
>> be the second, less used) ?
>>
> 
> Both must be associated with a keyword.

"must"?

No. There's no objective requirement for that.

"should"?

Personally I disagree, but fair enough.

Post a reply to this message