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