POV-Ray : Newsgroups : povray.bugreports : uv_mapping bug on cylinders : Re: uv_mapping bug on cylinders Server Time
8 Aug 2022 21:42:14 EDT (-0400)
  Re: uv_mapping bug on cylinders  
From: William F Pokorny
Date: 3 Aug 2022 18:21:00
Message: <62eaf4cc$1@news.povray.org>
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

Copyright 2003-2021 Persistence of Vision Raytracer Pty. Ltd.