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

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

I should understand first why I have such noisy sphere. The master branch has changed
a lot of vector operations (for a better C++ like syntax), but the operations would be
the same. Hg-povray branch is "late", more based on stable 3.7 release.

Post a reply to this message

Le 30/05/2016 19:37, Le_Forgeron a écrit :
> Le 30/05/2016 18:46, William F Pokorny a écrit :
>> 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.
> 
> I should understand first why I have such noisy sphere. The master branch has
changed a lot of vector operations (for a better C++ like syntax), but the operations
would be the same. Hg-povray branch is "late", more based on stable 3.7 release.
> 

And you are lucky, I found why it was noisy... it needed a test. Committed & pushed,
should be available now.

Hopefully it's the last bug of it :-)

Post a reply to this message

On 05/30/2016 02:13 PM, Le_Forgeron wrote:
> Le 30/05/2016 19:37, Le_Forgeron a écrit :
>>>
>>> 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.
>>
>> I should understand first why I have such noisy sphere. The master branch has
changed a lot of vector operations (for a better C++ like syntax), but the operations
would be the same. Hg-povray branch is "late", more based on stable 3.7 release.
>>
> And you are lucky, I found why it was noisy... it needed a test. Committed & pushed,
should be available now.
>
> Hopefully it's the last bug of it :-)
>
Yes indeed! Looks great even without sturm. :-)

Bill P.

Post a reply to this message

Am 26.05.2016 um 16:15 schrieb Le_Forgeron:

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

That should never happen. The syntax of an object MUST NOT change
depending on how it is represented internally.

> For lemon, I could replace with another object which would support
> sturm, but is it really needed ? or even wanted ?

You'll have to stick with an ovus-/lemon-specific parsing code, and just
silently ignore "sturm" if you replace the object.

Maybe a smarter way to approach this would be to first completely
construct an ovus/lemon, and in a "post-processing" step replace it with
a fitting sphere.

Post a reply to this message