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