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.

Post a reply to this message

Attachments:
Download 'lemon.png' (95 KB)

Preview of image 'lemon.png'

Am 08.05.2016 um 21:33 schrieb Le_Forgeron:

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

Not happy at all with the term "lemon" here, because it only fits the
special case R1=R2=0 (which btw is already covered by the torus in 3.7.1)

The term "ogive" would at least be technically fitting for cases where
only one of R1 and R2 is zero; the term "barrel", too, would be fitting
for more cases than "lemon".

Also, I suspect that specifying R3 as the maximum radius may be more
useful for practical purposes -- and am wondering what the uv_mapping
rules might be (I think, ideally they should match those of the "cone"
primitive).

Post a reply to this message

Le 09/05/2016 à 02:43, clipka a écrit :

  and am wondering what the uv_mapping
> rules might be (I think, ideally they should match those of the "cone"
> primitive).
>

Ah, Ah... very funny. ROTFL and far more. Really the best joke ever. 
Even the Green Golf Ball Joke is a bit short on the amount of humour on 
that uv_mapping of "cone" primitive.

That wil make my day.

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> 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.

Hi!
Errors shan't be. The program shall set limit value automatically. But to
report: "WARNING!WARNING!Impossible parameters - are specified to a minimum!"


lemon { 0,0.1,2,2,1 pigment{rgb 1} rotate x*90}

==== [Parsing...] ==========================================================
File '/tmp/Empty.pov' line 15: Possible Parse Error: Inner (last) radius of
 lemon is too small. Minimal would be 2.31012
Fatal error in parser: Uncategorized error.
Render failed


==== [Parsing...] ==========================================================
File '/tmp/Empty.pov' line 15: Possible Parse Error: Inner (last) radius of
 lemon is too small. Minimal would be 1.76952
Fatal error in parser: Uncategorized error.
Render failed

lemon { 0,0.1,5,0.5,1 pigment{rgb 1} rotate x*90}

==== [Parsing...] ==========================================================
File '/tmp/Empty.pov' line 15: Possible Parse Error: Inner (last) radius of
 lemon is too small. Minimal would be 4.34513
Fatal error in parser: Uncategorized error.
Render failed

Post a reply to this message

Am 09.05.2016 um 07:48 schrieb Le_Forgeron:
> Le 09/05/2016 à 02:43, clipka a écrit :
> 
>  and am wondering what the uv_mapping
>> rules might be (I think, ideally they should match those of the "cone"
>> primitive).
>>
> 
> Ah, Ah... very funny. ROTFL and far more. Really the best joke ever.

I concede I didn't have a closer look at the cone implementation; just
intended to make sure as early as possible in the design process that
the UV mapping isn't inconsistent with stuff we already have.

Obviously, yeah, since we don't seem to have UV mapping for the cone in
the first place, that turned out to be a moot point.

Please don't just grab something randomly out of a bag though. What I
see in your sample image looks like a ratio of 1:3:1 for the three
components of the object; since this is arbitrary anyway, I would
suggest a ratio of 1:2:1 instead. Not only does this slightly simplify
the maths the user will have to do, and also makes those operations
mathematically more stable (a floating-point division by any power of 2
is lossless; a divison by 5 never is) -- much more importantly, it is a
far better fit for standard image sizes commonly used for UV mapping
(which tend to be powers of 2; even where image sizes are multiples of
5, they'll typically also be multiples of 4.)

We should also consider whether we want the UV mapping of the main body
to just use a cylindrical mapping (as seems to be the case in your
sample image, though that might of course be an optical illusion), or
whether we want the mapping to be equidistant along what I presume to be
the V coordinate (essentially boiling down to a variation of toroidal
mapping).

Post a reply to this message

Le 09/05/2016 17:34, clipka a écrit :
> Am 09.05.2016 um 07:48 schrieb Le_Forgeron:
>> Le 09/05/2016 à 02:43, clipka a écrit :
>>
>>  and am wondering what the uv_mapping
>>> rules might be (I think, ideally they should match those of the "cone"
>>> primitive).
>>>
>>
>> Ah, Ah... very funny. ROTFL and far more. Really the best joke ever.
> 
> I concede I didn't have a closer look at the cone implementation; just
> intended to make sure as early as possible in the design process that
> the UV mapping isn't inconsistent with stuff we already have.
> 
> Obviously, yeah, since we don't seem to have UV mapping for the cone in
> the first place, that turned out to be a moot point.
> 
> Please don't just grab something randomly out of a bag though. What I
> see in your sample image looks like a ratio of 1:3:1 for the three
> components of the object; since this is arbitrary anyway, I would
> suggest a ratio of 1:2:1 instead. Not only does this slightly simplify
> the maths the user will have to do, and also makes those operations
> mathematically more stable (a floating-point division by any power of 2
> is lossless; a divison by 5 never is) -- much more importantly, it is a
> far better fit for standard image sizes commonly used for UV mapping
> (which tend to be powers of 2; even where image sizes are multiples of
> 5, they'll typically also be multiples of 4.)

I have no experience with image used for uv mapping, so I will trust you on that.
Initially (a code nobody have seen), I used a 10% for each end, but changed it
for a 20%, based on current VAT.
Updating for 25% is not a problem, it just seems a waste of pixels when
most of them get squeeze near the centre of the disc.

Let's listen to other's opinions first.

> 
> We should also consider whether we want the UV mapping of the main body
> to just use a cylindrical mapping (as seems to be the case in your
> sample image, though that might of course be an optical illusion), or
> whether we want the mapping to be equidistant along what I presume to be
> the V coordinate (essentially boiling down to a variation of toroidal
> mapping).
> 

Yep, cylindrical mapping so far for the torus part. I'm just dreaming of the
rocket on the cover (and inside) the "Destination moon" of Tintin (by Hergé).
And it was the easiest to code.

If we want the toroidal mapping, the code would need to store the uv with the
intersection as I have a feeling that the computation could be painful to revert.
Yet, it would be a waste of cycles when uv is not used.

Post a reply to this message

Le 09/05/2016 08:11, LanuHum a écrit :
> Le_Forgeron <jgr### [at] freefr> 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.
> 
> Hi!
> Errors shan't be. The program shall set limit value automatically. But to
> report: "WARNING!WARNING!Impossible parameters - are specified to a minimum!"
> 

Please try the new version.
(Bad input get a PossibleError instead, and object is replaced )

I also changed the uv-mapping to 25%.

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
>
> Please try the new version.
> (Bad input get a PossibleError instead, and object is replaced )
>
> I also changed the uv-mapping to 25%.

There are no errors. :)
But, in the Blender the lemon is unprofitable to be used.
Any this form is created by lathe.
But, I can construct Lathe in a 3D-view, but a lemon I can't.

Post a reply to this message

Attachments:
Download 'lemon.jpg' (63 KB)

Preview of image 'lemon.jpg'

Le 09/05/2016 18:40, Le_Forgeron a écrit :
> I'm just dreaming of the
> rocket on the cover (and inside) the "Destination moon" of Tintin (by Hergé).

4 lemon, 3 discs, 3 spheres, a bit of cut and voilà.

Post a reply to this message

Attachments:
Download 'fusee.png' (50 KB)

Preview of image 'fusee.png'

On 14-5-2016 19:06, Le_Forgeron wrote:
> Le 09/05/2016 18:40, Le_Forgeron a écrit :
>> I'm just dreaming of the
>> rocket on the cover (and inside) the "Destination moon" of Tintin (by Hergé).
>
> 4 lemon, 3 discs, 3 spheres, a bit of cut and voilà.
>

Merci Hergé :-)

-- 
Thomas

Post a reply to this message

Am 14.05.2016 um 19:06 schrieb Le_Forgeron:
> Le 09/05/2016 18:40, Le_Forgeron a écrit :
>> I'm just dreaming of the
>> rocket on the cover (and inside) the "Destination moon" of Tintin (by Hergé).
> 
> 4 lemon, 3 discs, 3 spheres, a bit of cut and voilà.

I love it!

Post a reply to this message

Am 12.05.2016 um 20:06 schrieb LanuHum:

> But, in the Blender the lemon is unprofitable to be used.
> Any this form is created by lathe.

You can't create this exact shape with lathe. All you can get is an
approximation.

Post a reply to this message

Am 2016-05-08 20:43, also sprach clipka:
> Am 08.05.2016 um 21:33 schrieb Le_Forgeron:

> Not happy at all with the term "lemon" here, because it only fits the
> special case R1=R2=0 (which btw is already covered by the torus in 3.7.1)
>
> The term "ogive" would at least be technically fitting for cases where
> only one of R1 and R2 is zero; the term "barrel", too, would be fitting
> for more cases than "lemon".
>

I don't like lemon either; it seems too specific (although I don't know 
why).  I prefer barrel.  Just my humble opinion.


-- 
dik

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 12.05.2016 um 20:06 schrieb LanuHum:
>
> > But, in the Blender the lemon is unprofitable to be used.
> > Any this form is created by lathe.
>
> You can't create this exact shape with lathe.

I won't argue. Accuracy of computation of Bezier curves has enough for creation
of a body of the car.

But, as the exact form of a lemon allows to place on its surface objects for
csg.

Task:
To place five spheres so that centers of spheres lay on a lemon surface.
difference{
lemon{}
sphere{??}
sphere{??}
sphere{??}
sphere{??}
sphere{??}
}

Look attachment

Post a reply to this message

Attachments:
Download 'lemon.jpg' (119 KB)

Preview of image 'lemon.jpg'

Am 18.05.2016 um 20:25 schrieb LanuHum:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 12.05.2016 um 20:06 schrieb LanuHum:
>>
>>> But, in the Blender the lemon is unprofitable to be used.
>>> Any this form is created by lathe.
>>
>> You can't create this exact shape with lathe.
> 
> I won't argue. Accuracy of computation of Bezier curves has enough for creation
> of a body of the car.

I doubt the designers of car bodies use Bezier splines -- their weapon
of choice are NURBS (non-uniform rational B-splines); AFAIK those do
have the capacity to precisely represent circular arcs.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

>
> I doubt the designers of car bodies use Bezier splines -- their weapon
> of choice are NURBS (non-uniform rational B-splines); AFAIK those do
> have the capacity to precisely represent circular arcs.

https://en.wikipedia.org/wiki/B%C3%A9zier_curve

> The mathematical basis for Bézier curves — the Bernstein polynomial — has been >
known since 1912, but its applicabil
ity to graphics was not realized for
> another half century. Bézier curves were widely publicized in 1962 by the
> French engineer Pierre Bézier, who used them to design automobile bodies at
> Renault. The study of these curves was however first developed in 1959 by
> mathematician Paul de Casteljau using de Casteljau's algorithm, a numerically
> stable method to evaluate Bézier curves at Citroën, another French automaker.

Post a reply to this message

Am 19.05.2016 um 16:10 schrieb LanuHum:
> clipka <ano### [at] anonymousorg> wrote:
> 
>>
>> I doubt the designers of car bodies use Bezier splines -- their weapon
>> of choice are NURBS (non-uniform rational B-splines); AFAIK those do
>> have the capacity to precisely represent circular arcs.
> 
> https://en.wikipedia.org/wiki/B%C3%A9zier_curve
> 
[quote from Wikipedia, not clipka]
>> The mathematical basis for Bézier curves — the Bernstein polynomial — has been
>> known since 1912, but its applicability to graphics was not realized for
>> another half century. Bézier curves were widely publicized in 1962 by the
>> French engineer Pierre Bézier, who used them to design automobile bodies at
>> Renault. The study of these curves was however first developed in 1959 by
>> mathematician Paul de Casteljau using de Casteljau's algorithm, a numerically
>> stable method to evaluate Bézier curves at Citroën, another French automaker.

Yes, the /invention/ of Bezier curves was driven by the French
automotive industry.

But as the article also notes, that was around _1960_.

Car body quality requirements have increased quite a lot since then.

Note how the "Applications" section in that article lists computer
graphics, animation and fonts, but /not/ [contemporary] automotive design.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

>
> Yes, the /invention/ of Bezier curves was driven by the French
> automotive industry.
>
> But as the article also notes, that was around _1960_.
>
> Car body quality requirements have increased quite a lot since then.
>
> Note how the "Applications" section in that article lists computer
> graphics, animation and fonts, but /not/ [contemporary] automotive design.

We distracted, but the task remained unresolved.
Task:
To place five spheres so that centers of spheres lay on a lemon surface.
difference{
lemon{}
sphere{??}
sphere{??}
sphere{??}
sphere{??}
sphere{??}
}

http://news.povray.org/povray.binaries.images/attachment/%3Cweb.573cb381370a969c7a3e03fe0%40news.povray.org%3E/lemon.jp
g

WRITTEN_FOR="LANUHUM"
use_bezier_lathe = False
use_lemon = True
#macro Calculate_points_coords_lemon_surface(number_x,number_y,number_z)
//bla-bla-bla...
replace, please, //bla-bla-bla... with the working source code
If it isn't in documentation, then I don't know how to the rocket to attach
wings
:))))))

Post a reply to this message

On 05/19/2016 11:46 AM, LanuHum wrote:
> clipka <ano### [at] anonymousorg> wrote:
>
>>
>> Yes, the /invention/ of Bezier curves was driven by the French
>> automotive industry.
>>
>> But as the article also notes, that was around _1960_.
>>
>> Car body quality requirements have increased quite a lot since then.
>>
>> Note how the "Applications" section in that article lists computer
>> graphics, animation and fonts, but /not/ [contemporary] automotive design.
>
> We distracted, but the task remained unresolved.
> Task:
> To place five spheres so that centers of spheres lay on a lemon surface.
> difference{
> lemon{}
> sphere{??}
> sphere{??}
> sphere{??}
> sphere{??}
> sphere{??}
> }
>
>
http://news.povray.org/povray.binaries.images/attachment/%3Cweb.573cb381370a969c7a3e03fe0%40news.povray.org%3E/lemon.jp
> g
>
> WRITTEN_FOR="LANUHUM"
> use_bezier_lathe = False
> use_lemon = True
> #macro Calculate_points_coords_lemon_surface(number_x,number_y,number_z)
> //bla-bla-bla...
> replace, please, //bla-bla-bla... with the working source code
> If it isn't in documentation, then I don't know how to the rocket to attach
> wings
> :))))))
>
>
>
>
>

The code below uses the new spindle torus & not the lemon, but is 
something like this what you are after?

#declare Torus00=torus { 0.25, 0.5 intersection scale <1,2,1> }
#declare Norm=<0,0,0>;
difference {
     object { Torus00 }
     sphere { trace(Torus00, <1,0,0>,    <-1,0,0>, Norm) , 0.15 }
     sphere { trace(Torus00, <1,0.5,0>,  <-1,0,0>, Norm) , 0.15 }
     sphere { trace(Torus00, <1,-0.5,0>, <-1,0,0>, Norm) , 0.15 }
     pigment { color Niagara }
}

Bill P.

Post a reply to this message

Le 19/05/2016 17:46, LanuHum a écrit :
> clipka <ano### [at] anonymousorg> wrote:
> 
>>
>> Yes, the /invention/ of Bezier curves was driven by the French
>> automotive industry.
>>
>> But as the article also notes, that was around _1960_.
>>
>> Car body quality requirements have increased quite a lot since then.
>>
>> Note how the "Applications" section in that article lists computer
>> graphics, animation and fonts, but /not/ [contemporary] automotive design.
> 
> We distracted, but the task remained unresolved.
> Task:
> To place five spheres so that centers of spheres lay on a lemon surface.
> difference{
> lemon{}
> sphere{??}
> sphere{??}
> sphere{??}
> sphere{??}
> sphere{??}
> }

For lemon { 0, 0, H*y, 0, R }

The 2D circle (of radius R) of the lemon is centred at <-V, H/2>, with
V^2 = R^2 - ((H^2)/4)

easily solved as V = sqrt( R^2 - ((H^2)/4) ).

Assuming you want the spheres in the z=0,x+ demi plane, you just have to satisfy for 
< A, B, C> as the centre:

C = 0

R^2 = (B-(H/2))^2 + (A+V)^2

0 <= B <= H

As I'm tired of equations solving, I let it to wolframalpha solver :

A is sqrt(-2 B^2+2 B H-H^2+4 R^2+sqrt(H^2-4 R^2) sqrt(4 B^2-4 B H+H^2-4 R^2))/sqrt(2)


Have a nice sleep.

Post a reply to this message

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

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