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