I encountered an issue with v3.8 beta 2 using uv_mapping textures on cylinders
while creating a label for a bottle.  I did search through the newsgroups for
any other report of this and didn't find anything that matches my problem.

The original texture is fairly complex and involves using an object pattern with
a text object as the "object" and fully-specified textures for the ink and the
background of the label as the texture list.  However, I was able to simplify it
considerably to the following:

            cylinder {
                <0, 0, 0>,
                <0, 20, 0>,
                5
                texture { uv_mapping pigment { brick color rgb 0 color rgb 1 } }
            }
            cylinder {
                <0, 0, 0>,
                <0, 20, 0>,
                5
                texture { uv_mapping pigment { brick color rgb 0 color rgb 1 } }
                translate <20, 0, 0>
            }

As you can see, the second cylinder is translated after applying the texture,
but if you look at the brick pattern, it appears the uv_mapping is being applied
to the translated object first, because the bricks do not line up.

In my bottle example, the text doesn't show up at all in the translated bottle,
because the entire bottle is outside of the text object's boundaries after it is
translated.

-- Chris R.

Post a reply to this message

Attachments:
Download 'magic.png' (91 KB)

Preview of image 'magic.png'

"Chris R" <car### [at] comcastnet> wrote:
> I encountered an issue with v3.8 beta 2 using uv_mapping textures on cylinders
> while creating a label for a bottle.  I did search through the newsgroups for
> any other report of this and didn't find anything that matches my problem.
>
> The original texture is fairly complex and involves using an object pattern with
> a text object as the "object" and fully-specified textures for the ink and the
> background of the label as the texture list.  However, I was able to simplify it
> considerably to the following:
>
>             cylinder {
>                 <0, 0, 0>,
>                 <0, 20, 0>,
>                 5
>                 texture { uv_mapping pigment { brick color rgb 0 color rgb 1 } }
>             }
>             cylinder {
>                 <0, 0, 0>,
>                 <0, 20, 0>,
>                 5
>                 texture { uv_mapping pigment { brick color rgb 0 color rgb 1 } }
>                 translate <20, 0, 0>
>             }
>
> As you can see, the second cylinder is translated after applying the texture,
> but if you look at the brick pattern, it appears the uv_mapping is being applied
> to the translated object first, because the bricks do not line up.
>
> In my bottle example, the text doesn't show up at all in the translated bottle,
> because the entire bottle is outside of the text object's boundaries after it is
> translated.
>
> -- Chris R.

Just as additional information, adding a "translate <20, 0, 0>" after the
pigment declaration in the second texture corrects the problem.

-- Chris R.

Post a reply to this message

On 8/3/22 10:44, Chris R wrote:
> "Chris R" <car### [at] comcastnet> wrote:
>> I encountered an issue with v3.8 beta 2 using uv_mapping textures on cylinders
>> while creating a label for a bottle.  I did search through the newsgroups for
>> any other report of this and didn't find anything that matches my problem.
>>
>> The original texture is fairly complex and involves using an object pattern with
>> a text object as the "object" and fully-specified textures for the ink and the
>> background of the label as the texture list.  However, I was able to simplify it
>> considerably to the following:
>>
>>              cylinder {
>>                  <0, 0, 0>,
>>                  <0, 20, 0>,
>>                  5
>>                  texture { uv_mapping pigment { brick color rgb 0 color rgb 1 } }
>>              }
>>              cylinder {
>>                  <0, 0, 0>,
>>                  <0, 20, 0>,
>>                  5
>>                  texture { uv_mapping pigment { brick color rgb 0 color rgb 1 } }
>>                  translate <20, 0, 0>
>>              }
>>
>> As you can see, the second cylinder is translated after applying the texture,
>> but if you look at the brick pattern, it appears the uv_mapping is being applied
>> to the translated object first, because the bricks do not line up.
>>
>> In my bottle example, the text doesn't show up at all in the translated bottle,
>> because the entire bottle is outside of the text object's boundaries after it is
>> translated.
>>
>> -- Chris R.
> 
> Just as additional information, adding a "translate <20, 0, 0>" after the
> pigment declaration in the second texture corrects the problem.
> 
> -- Chris R.
> 
> 
IIRC the uv_mapping feature for cylinders and cones(a) is currently 
disabled in recent v3.8 / v4.0 code. I believe you are getting some sort 
of default planar mapping(b).

(a) - And other shape(s) where mapping didn't exist in v3.7.

(b) - Unsure what corrections for transforms and mapping spaces might be 
getting done or not with it. You could roughly test for planar mapping 
by moving the right cylinder in x by 5+1e-6, say.

---
More if interested. As remembered by my old flaky memory...

Cylinders and some other shapes did not previously support uv_mapping in 
v3.6/v3.7 though the keyword was allowed by the parser with no warning 
it's not really working. Jerome added code to do the mapping for 
cylinders, cones and other shape(s).

Christoph, later found a longstanding issue related to unstable mapping 
orientation - and he disabled all the new to v3.8/v4.0 uv_mapping 
updates. The problem noted exists for older mappings too, like the ovus, 
but it had uv mapping in v3.7 and Christoph decided to leave it as is 
for v3.8.

Last I knew, the documentation reflects the uv mapping as it was with 
the new uv_mapping shapes and not the current code state.

Jerome proposed fix for Christoph's concern, which I think is in 
hgpovray38, but I've not looked at it in detail. It wasn't 
adopted/merged in the official code.

Aside: I 'sort of' understand Christoph's concerns and Jerome's 
proposal, but I have additional questions relating to shapes like 
spheres which the parser 'sometimes' flattens to an already transformed 
position/orientation. I'd guess any better uv_mapping specification/code 
would have to track/work with the parser to maintain any specified 
uv_mapping orientation there too.

Aside 2: There are two additional ways to do cylindrical mapping of 
textures via warps and image_maps.

Bill P.

Post a reply to this message

Supplemental Aside #3:

You can also uv-map an object by writing your own function to texture the
object's surface.   If you're into that sort of thing.

http://news.povray.org/povray.binaries.images/thread/%3Cweb.5d5757a84c72a7284eec112d0%40news.povray.org%3E/?ttop=430135
&toff=50

Post a reply to this message

Op 04/08/2022 om 01:35 schreef Bald Eagle:
> Supplemental Aside #3:
> 
> You can also uv-map an object by writing your own function to texture the
> object's surface.   If you're into that sort of thing.
> 
>
http://news.povray.org/povray.binaries.images/thread/%3Cweb.5d5757a84c72a7284eec112d0%40news.povray.org%3E/?ttop=430135
> &toff=50
> 

...which reminds me to ask you (curiosity): how does

#declare U = function (X, Y, Z) {(0.5 + atan2 (N(Z, X,Y,Z), N(X, 
X,Y,Z))/(2*pi))}
#declare V = function (X, Y, Z) {(0.5 + asin(N(Y, X,Y,Z))/pi)}

work? is puzzling, as far as atan2 and asin are concerned.

-- 
Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> ...which reminds me to ask you (curiosity): how does
>
> #declare U = function (X, Y, Z) {(0.5 + atan2 (N(Z, X,Y,Z), N(X,
> X,Y,Z))/(2*pi))}
> #declare V = function (X, Y, Z) {(0.5 + asin(N(Y, X,Y,Z))/pi)}
>
> work? is puzzling, as far as atan2 and asin are concerned.
>
> --
> Thomas

I don't have the file accessible to me ATM, but IIRC, the N() function is
probably just a select () for whichever vector component is specified as the
first argument. (*)

Then the atan2 returns an angle between -pi and pi, based on z and x.
Dividing by tau gives values between -0.5 and 0.5, and then everything is
shifted to between 0 and 1.

asin returns an angle between -pi/2 and pi/2.
Dividing by pi gives values between -0.5 and 0.5, and then everything is shifted
to between 0 and 1.


(*) And the way THAT works, is taking the specified vector components and doing
something like x*(-1) + y*0 + z*(2).  That should give you a -1, a 0, or a 2
depending on which cardinal vector is specified.
select () then returns one of three scalar values depending on what component it
spits out.

Post a reply to this message

Op 4-8-2022 om 12:36 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> ...which reminds me to ask you (curiosity): how does
>>
>> #declare U = function (X, Y, Z) {(0.5 + atan2 (N(Z, X,Y,Z), N(X,
>> X,Y,Z))/(2*pi))}
>> #declare V = function (X, Y, Z) {(0.5 + asin(N(Y, X,Y,Z))/pi)}
>>
>> work? is puzzling, as far as atan2 and asin are concerned.
>>
>> --
>> Thomas
> 
> I don't have the file accessible to me ATM, but IIRC, the N() function is
> probably just a select () for whichever vector component is specified as the
> first argument. (*)
> 
> Then the atan2 returns an angle between -pi and pi, based on z and x.
> Dividing by tau gives values between -0.5 and 0.5, and then everything is
> shifted to between 0 and 1.
> 
> asin returns an angle between -pi/2 and pi/2.
> Dividing by pi gives values between -0.5 and 0.5, and then everything is shifted
> to between 0 and 1.
> 
> 
> (*) And the way THAT works, is taking the specified vector components and doing
> something like x*(-1) + y*0 + z*(2).  That should give you a -1, a 0, or a 2
> depending on which cardinal vector is specified.
> select () then returns one of three scalar values depending on what component it
> spits out.
> 


OK thanks. Sorry for diverting from the original post subject. I'll shut 
up now. :-)

-- 
Thomas

Post a reply to this message

Le 03/08/2022 à 16:36, Chris R a écrit :
> I encountered an issue with v3.8 beta 2 using uv_mapping textures on cylinders
> while creating a label for a bottle.  I did search through the newsgroups for
> any other report of this and didn't find anything that matches my problem.
> 
> The original texture is fairly complex and involves using an object pattern with
> a text object as the "object" and fully-specified textures for the ink and the
> background of the label as the texture list.  However, I was able to simplify it
> considerably to the following:
> 
>              cylinder {
>                  <0, 0, 0>,
>                  <0, 20, 0>,
>                  5
>                  texture { uv_mapping pigment { brick color rgb 0 color rgb 1 } }
>              }
>              cylinder {
>                  <0, 0, 0>,
>                  <0, 20, 0>,
>                  5
>                  texture { uv_mapping pigment { brick color rgb 0 color rgb 1 } }
>                  translate <20, 0, 0>
>              }
> 

Hello,

Any hope to get the full simplified scene of the picture ?
(it's for my experiment, you can send it directly if you do not want to 
bother the newsgroups)

William clearly summarised the sequence of events.

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:

> > I encountered an issue with v3.8 beta 2 using uv_mapping textures on cylinders
> > while creating a label for a bottle.  I did search through the newsgroups for
> > any other report of this and didn't find anything that matches my problem.
> >
> > The original texture is fairly complex and involves using an object pattern with
> > a text object as the "object" and fully-specified textures for the ink and the
> > background of the label as the texture list.  However, I was able to simplify it
> > considerably to the following:
> >
> >              cylinder {
> >                  <0, 0, 0>,
> >                  <0, 20, 0>,
> >                  5
> >                  texture { uv_mapping pigment { brick color rgb 0 color rgb 1 } }
> >              }
> >              cylinder {
> >                  <0, 0, 0>,
> >                  <0, 20, 0>,
> >                  5
> >                  texture { uv_mapping pigment { brick color rgb 0 color rgb 1 } }
> >                  translate <20, 0, 0>
> >              }
> >
>
> Hello,
>
> Any hope to get the full simplified scene of the picture ?
> (it's for my experiment, you can send it directly if you do not want to
> bother the newsgroups)
>
> William clearly summarised the sequence of events.

I simplified it even further in the attached .pov file.

-- Chris R.

Post a reply to this message

Attachments:
Download 'uv_mapping.pov.txt' (1 KB)

Le 04/08/2022 à 20:21, Chris R a écrit :
> Le_Forgeron <jgr### [at] freefr> wrote:

>> Any hope to get the full simplified scene of the picture ?
>> (it's for my experiment, you can send it directly if you do not want to
>> bother the newsgroups)
>>
>> William clearly summarised the sequence of events.
> 
> I simplified it even further in the attached .pov file.
> 
> -- Chris R.

Thanks.

The script frightened me a bit for hgpovray38 until I remembered to 
scale down the texture (by factor of 1/30 or so) to be able to see the 
pattern. Moving the second cylinder is safe.
I also moved the light further away.

Post a reply to this message

Attachments:
Download 'hg.png' (29 KB)

Preview of image 'hg.png'