On 05/26/2016 10:15 AM, Le_Forgeron wrote:
> Le 26/05/2016 à 15:24, William F Pokorny a écrit :
>
> On LemonLeft, parsing occurs up to the inner radius, then the message is
> written and the object so far get replaced with a sphere.
> Then parsing continue and find sturm, which is not supported by a sphere.
>
> Notice that the same issue would occurs with current ovus (when the top
> radius is more than twice the bottom radius).
>
> For lemon, I could replace with another object which would support
> sturm, but is it really needed ? or even wanted ?
>
> (My first approach was to stop with an error instead of a warning, was
> it better ?)
>

Suppose if someone is doing an animation or sequence of images, it might 
be convenient to transition into a sphere then continue to shrink that 
sphere.

If so, we are not really doing that today as we seem to be at a 0.5 
radius and then jump to a radius of 0.499999/2 where we'd need to not 
have a discontinuity in result for inner radius moving from 0.5 to 
0.499999.

Changing from the current discontinuous behavior and moving to say a 
polynomial (See attached image) :

// #declare LemonLeft  = lemon {
//    <-1.2,-0.5,0>, 0.0, <-1.2,0.5,0>, 0.0, 0.499999
// }
    #declare LemonLeft  = polynomial { 2,
      xyz(2,0,0):1,
      xyz(0,2,0):1,
      xyz(0,0,2):1,
      xyz(1,0,0):-2*-1.2,
      xyz(0,0,0):pow(-1.2,2)-pow(0.49999,2)
      sturm
    }

allows sturm - but then not open... I suspect if we want this smooth 
transition into a sphere we might be stuck filtering whatever keywords 
the lemon supports but our substitute object does not.

If we are going to jump to the 0.499999/2 radius on substitution as we 
do today, I vote we go back to an error message.

Bill P.

Post a reply to this message

Attachments:
Download 'lemonissue2.jpg' (103 KB)

Preview of image 'lemonissue2.jpg'