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'