On 05/08/2016 03:33 PM, Le_Forgeron wrote:
> For the time being, only available in hgpovray.
>
> lemon { P1, R1, P2, R2, R3 ... }
>
> similar to cone { P1, R1, P2, R2 ...} but connected with a lemon (inner circle of a
torus) of radius R3.
>
> Options includes : uv_mapping, open and sturm.
>
> All Rx must be positive or null, and there is a complain with error when R3 is too
small.
> The complain gives the minimal value that can be used.
>
> And now that I can sleep a bit, I'm returning to the extension of the ovus.
>

In working with this new object I came across this case:

// P1, R1, P2, R2, R3
#declare LemonLeft  = lemon {
    <-1.2,-0.5,0>, 0.0, <-1.2,0.5,0>, 0.0, 0.499999
}
#declare LemonCenter = lemon {
    <0,-0.5,0>, 0.0, <0,0.5,0>, 0.0, 0.50
}
#declare LemonRight  = lemon {
    <1.2,-0.5,0>, 0.0, <1.2,0.5,0>, 0.0, 0.500001
}

Where the LemonLeft generates this warning message:

File 'lemon.pov' line 176: Possible Parse Error: Inner (last) radius of 
lemon is too small. Minimal would be 0.5. Subtituing a sphere to lemon

recommending the code used in LemonCenter. However the result for 
LemonCenter is quite noisy. An 'epsilon' above is OK.

See attached image.

Bill P.

Post a reply to this message

Attachments:
Download 'lemonissue.jpg' (75 KB)

Preview of image 'lemonissue.jpg'

Le 26/05/2016 à 13:31, William F Pokorny a écrit :
> In working with this new object I came across this case:
>
> // P1, R1, P2, R2, R3
> #declare LemonLeft  = lemon {
>    <-1.2,-0.5,0>, 0.0, <-1.2,0.5,0>, 0.0, 0.499999
> }
> #declare LemonCenter = lemon {
>    <0,-0.5,0>, 0.0, <0,0.5,0>, 0.0, 0.50
> }
> #declare LemonRight  = lemon {
>    <1.2,-0.5,0>, 0.0, <1.2,0.5,0>, 0.0, 0.500001
> }
>
> Where the LemonLeft generates this warning message:
>
> File 'lemon.pov' line 176: Possible Parse Error: Inner (last) radius of
> lemon is too small. Minimal would be 0.5. Subtituing a sphere to lemon
>
> recommending the code used in LemonCenter. However the result for
> LemonCenter is quite noisy. An 'epsilon' above is OK.
>
> See attached image.
>
> Bill P.

can you try to add "sturm" to LemonCenter ? (I'm away from my hgpovray)

#declare LemonCenter = lemon {
     <0,-0.5,0>, 0.0, <0,0.5,0>, 0.0, 0.50 sturm
}

Post a reply to this message

On 05/26/2016 07:50 AM, Le_Forgeron wrote:
> Le 26/05/2016 à 13:31, William F Pokorny a écrit :
>
> can you try to add "sturm" to LemonCenter ? (I'm away from my hgpovray)
>
> #declare LemonCenter = lemon {
>      <0,-0.5,0>, 0.0, <0,0.5,0>, 0.0, 0.50 sturm
> }
>

Using sturm as follows is less noisy, but still noisy :

#declare LemonLeft  = lemon {
    <-1.2,-0.5,0>, 0.0, <-1.2,0.5,0>, 0.0, 0.499999
}
#declare LemonCenter = lemon {
    <0,-0.5,0>, 0.0, <0,0.5,0>, 0.0, 0.50 sturm
}
#declare LemonRight  = lemon {
    <1.2,-0.5,0>, 0.0, <1.2,0.5,0>, 0.0, 0.500001 sturm
}

On my first attempt I did the following:

#declare LemonLeft  = lemon {
    <-1.2,-0.5,0>, 0.0, <-1.2,0.5,0>, 0.0, 0.499999 sturm
}
#declare LemonCenter = lemon {
    <0,-0.5,0>, 0.0, <0,0.5,0>, 0.0, 0.50 sturm
}
#declare LemonRight  = lemon {
    <1.2,-0.5,0>, 0.0, <1.2,0.5,0>, 0.0, 0.500001 sturm
}

which gave me this parse error :

File 'lemon.pov' line 175: Parse Error: Keyword 'sturm' cannot be used 
with this object.

So, I assumed you'd not yet set sturm up for the lemon! Wondering now if 
the code creating the inner radius warning for LemonLeft is itself 
creating the error for sturm use in that case?

Bill P.

Post a reply to this message

Le 26/05/2016 à 15:24, William F Pokorny a écrit :

> File 'lemon.pov' line 175: Parse Error: Keyword 'sturm' cannot be used
> with this object.
>
> So, I assumed you'd not yet set sturm up for the lemon! Wondering now if
> the code creating the inner radius warning for LemonLeft is itself
> creating the error for sturm use in that case?
>
> Bill P.

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 ?)

Post a reply to this message

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'

Le 26/05/2016 18:12, William F Pokorny a écrit :
> 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.

Thanks you for your input, on that point as well as the noisy surface when radius is
exactly the minimal one.
It should be corrected with the new (and hopefully last) change on the lemon.

> 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.

If the vertices are identical, an error message is issued (same as for cylinder/cone)
If the third radius is too small, it is adjusted to the smallest value and a warning
is written, thus allowing sturm and open without problem. So, no more discontinuity,
but no shrinking either.

and for extra benefit, when the third radius is the minimal one, a sphere is used
instead of the torus part, removing the problem of noise on the surface due to
coincident surface.

Post a reply to this message

On 05/29/2016 01:32 PM, Le_Forgeron wrote:
>
> Thanks you for your input, on that point as well as the noisy surface when radius is
exactly the minimal one.
> It should be corrected with the new (and hopefully last) change on the lemon.
>
>> 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.
>
> If the vertices are identical, an error message is issued (same as for
cylinder/cone)
> If the third radius is too small, it is adjusted to the smallest value and a warning
is written, thus allowing sturm and open without problem. So, no more discontinuity,
but no shrinking either.
>
> and for extra benefit, when the third radius is the minimal one, a sphere is used
instead of the torus part, removing the problem of noise on the surface due to
coincident surface.
>

Unfortunately, I am still seeing noise at the 0.5 radius with the 
following code giving us the three rows in the attached image.

//----- Top set
// #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.50000,2)
//   sturm
// }
// #declare LemonCenter  = polynomial { 2,
//   xyz(2,0,0):1,
//   xyz(0,2,0):1,
//   xyz(0,0,2):1,
//   xyz(0,0,0):-pow(0.50000,2)
//   sturm
// }

//----- Middle set
// #declare LemonLeft  = lemon {
//    <-1.2,-0.5,0>, 0.0, <-1.2,0.5,0>, 0.0, 0.499999
// }
// #declare LemonCenter = lemon {
//    <0,-0.5,0>, 0.0, <0,0.5,0>, 0.0, 0.50
// }

//----- Bottom set
    #declare LemonLeft  = lemon {
       <-1.2,-0.5,0>, 0.0, <-1.2,0.5,0>, 0.0, 0.499999 sturm
    }
    #declare LemonCenter = lemon {
       <0,-0.5,0>, 0.0, <0,0.5,0>, 0.0, 0.50 sturm
    }

//----- All sets
#declare LemonRight  = lemon {
    <1.2,-0.5,0>, 0.0, <1.2,0.5,0>, 0.0, 0.500001 sturm
}

Bill P.

Post a reply to this message

Attachments:
Download 'hg_495:52beb76993f0.jpg' (208 KB)

Preview of image 'hg_495:52beb76993f0.jpg'

Le 30/05/2016 16:42, William F Pokorny a écrit :
> On 05/29/2016 01:32 PM, Le_Forgeron wrote:
>>
>> Thanks you for your input, on that point as well as the noisy surface when radius
is exactly the minimal one.
>> It should be corrected with the new (and hopefully last) change on the lemon.
>>
>>> 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.
>>
>> If the vertices are identical, an error message is issued (same as for
cylinder/cone)
>> If the third radius is too small, it is adjusted to the smallest value and a
warning is written, thus allowing sturm and open without problem. So, no more
discontinuity, but no shrinking either.
>>
>> and for extra benefit, when the third radius is the minimal one, a sphere is used
instead of the torus part, removing the problem of noise on the surface due to
coincident surface.
>>
> 
> Unfortunately, I am still seeing noise at the 0.5 radius with the following code
giving us the three rows in the attached image.
> 

I agree there is still something on the surface, when used with a metallic reflection.
But the coincidence surface seems to not be the cause.

If anyone has a clue, feel welcome to share.

Post a reply to this message

Attachments:
Download 'lo.png' (191 KB) Download 'lo.pov.txt' (2 KB)

Preview of image 'lo.png'

Le 30/05/2016 17:57, Le_Forgeron a écrit :
> I agree there is still something on the surface, when used with a metallic
reflection.
> But the coincidence surface seems to not be the cause.
> 
> If anyone has a clue, feel welcome to share.

seems it is tied to the computation when the sphere is used... Puzzling.

Post a reply to this message

On 05/30/2016 12:21 PM, Le_Forgeron wrote:
> Le 30/05/2016 17:57, Le_Forgeron a écrit :
>> I agree there is still something on the surface, when used with a metallic
reflection.
>> But the coincidence surface seems to not be the cause.
>>
>> If anyone has a clue, feel welcome to share.
>
> seems it is tied to the computation when the sphere is used... Puzzling.
>

Interesting. Do you think it might be worth porting the lemon into the 
current gitgub master branch for a test?

I'm not completely up on the differences compared to the Hg-povray 
branch...

Bill P.

Post a reply to this message