In working to port Jérôme's new cylinder and cone uv_mapping to the 
3.7.1 master branch, I found the mapping to be upside-down (V flipped) 
to what I expected.

I decided to look at all(1) the uv_mapping, map_type image mapping and 
warp based mapping to see where things stood. I found the torus 
uv_mapping flipped left-right (U flipped) and the just added lemon also 
flipped in V but everything else having a consistent orientation. See 
the attached figure.

A github pull request #131 has been submitted for Jérôme's cone and 
cylinder uv_mapping except flipped to the usual V orientation and as 
shown in the figure.

I'll work on updates & pull requests to align the lemon (B) and torus 
(A) uv_mapping, but I'll wait a day or two should there be other opinions.

Bill P.
(1) - Except the box/cubic mapping.

Post a reply to this message

Attachments:
Download 'mappings.jpg' (110 KB)

Preview of image 'mappings.jpg'

Le 23/10/2016 à 17:05, William F Pokorny a écrit :
> In working to port Jérôme's new cylinder and cone uv_mapping to the
> 3.7.1 master branch, I found the mapping to be upside-down (V flipped)
> to what I expected.
> 
> I decided to look at all(1) the uv_mapping, map_type image mapping and
> warp based mapping to see where things stood. I found the torus
> uv_mapping flipped left-right (U flipped) and the just added lemon also
> flipped in V but everything else having a consistent orientation. See
> the attached figure.
> 
> A github pull request #131 has been submitted for Jérôme's cone and
> cylinder uv_mapping except flipped to the usual V orientation and as
> shown in the figure.
> 
> I'll work on updates & pull requests to align the lemon (B) and torus
> (A) uv_mapping, but I'll wait a day or two should there be other opinions.
> 
> Bill P.
> (1) - Except the box/cubic mapping.
> 
> 
> 
You should also have a look at box uv_mapping... it's strange too.

You can read it from the inside.

I will investigate each object uv_mapping of hgpovray later, and might
change it (in term of flipping).

Target: being able to read the text on an image. The same image, on all
objects

Post a reply to this message

Attachments:
Download 'refimgobject_sphere.png' (533 KB) Download 'refimgobject_box.png' (729 KB) Download 'environment.inc.txt' (4 KB) Download 'clipped_oriented.pov.txt' (3 KB)

Preview of image 'refimgobject_sphere.png'

Preview of image 'refimgobject_box.png'

Am 25.10.2016 um 18:55 schrieb Le_Forgeron:

> You should also have a look at box uv_mapping... it's strange too.
> 
> You can read it from the inside.

Caution: The question whether you can read text from the outside or
inside depends not only on the UV mapping scheme, but also on the
handedness of the coordinate system.

Post a reply to this message

On 10/25/2016 12:55 PM, Le_Forgeron wrote:
> Le 23/10/2016 à 17:05, William F Pokorny a écrit :
> You should also have a look at box uv_mapping... it's strange too.
>
> You can read it from the inside.
>
> I will investigate each object uv_mapping of hgpovray later, and might
> change it (in term of flipping).
>
> Target: being able to read the text on an image. The same image, on all
> objects
>
Yes, I ignored that mapping for being textures by face at least in terms 
of the cubic pattern(1) and I've always thought of the box uv/warp 
{cubic} mapping more in terms of what is needed for each pyramidal 
mapping of a face looking toward the origin. In other words I think 
about this mapping as if we have multiple sub-uv maps per box face.

That said, we could I think, get to where an image/pattern as viewed  on 
a plane would map more naturally onto the box as if wrapped in U like 
other patterns.

I'd say we take starting and ending mid face on the +X face out of 
consideration, but keep the idea of the map starting/ending on the +X 
face to better match our other maps. Are you then thinking of folding 
from +x backward for Y top/bottom using a map something like this?

Ymax
Xmax Zmax Xmin Zmin
Ymin

Suppose a significant amount box-uv/warp{cubic} mapping in scenes. Add 
an alternate box mapping? What is the complexity of another box mapping 
compared to mirroring in U(x) the pattern/image prior to 
box-uv_mapping/warp {cubic}...

Aside: I've used stand alone scripts & more recently a couple 
user_defined cameras for creating box uv/warp{ cubic } image maps(2).

Bill P.

(1) - I admit I've never used the cubic pattern other than by side 
effect in someone's scene file.

(2) - Partly aiming for flat image_map interpolation that works better 
through the box/cubic folds on the open edges of the mapping.

Post a reply to this message

Le 26/10/2016 à 01:20, clipka a écrit :
> Am 25.10.2016 um 18:55 schrieb Le_Forgeron:
> 
>> You should also have a look at box uv_mapping... it's strange too.
>>
>> You can read it from the inside.
> 
> Caution: The question whether you can read text from the outside or
> inside depends not only on the UV mapping scheme, but also on the
> handedness of the coordinate system.
> 

Oh, another parameter in the equation then. Are you sure of that ?

All work and no play makes jack...

Post a reply to this message

On 10/26/2016 4:55 PM, Le_Forgeron wrote:
> All work and no play makes jack...

Rich? ^_^

-- 

Regards
     Stephen

Post a reply to this message

Am 26.10.2016 um 17:43 schrieb William F Pokorny:
> On 10/25/2016 12:55 PM, Le_Forgeron wrote:
>> Le 23/10/2016 à 17:05, William F Pokorny a écrit :
>> You should also have a look at box uv_mapping... it's strange too.
...
> That said, we could I think, get to where an image/pattern as viewed  on
> a plane would map more naturally onto the box as if wrapped in U like
> other patterns.
> 
> I'd say we take starting and ending mid face on the +X face out of
> consideration, but keep the idea of the map starting/ending on the +X
> face to better match our other maps. Are you then thinking of folding
> from +x backward for Y top/bottom using a map something like this?
> 
> Ymax
> Xmax Zmax Xmin Zmin
> Ymin

If we make any changes to the box uv_mapping at all, let's avoid rolling
our own again, and instead pick a format from among those "in the wild".

Potential candidates that spring to my mind are some 360 degree panorama
formats:

- Paul Debevec's "Vertical Cross Cube" format
- Quicktime VR cubic format
- SPi-V cubic format

As far as I can tell, the Quicktime VR format happens to match POV-Ray's
current box UV mapping (remember that in 360 degree panoramas you're
inside the cube), provided POV-Ray's default left-handed coordinate
system is used.

Also, the vertical cross cube format is reasonably compatible with it:
Rotating the texture by 90 degrees counter-clockwise, and compensating
by rotating the box by 90 degrees clockwise, should do the trick.


> Suppose a significant amount box-uv/warp{cubic} mapping in scenes. Add
> an alternate box mapping? What is the complexity of another box mapping
> compared to mirroring in U(x) the pattern/image prior to
> box-uv_mapping/warp {cubic}...

Introducing alternative UV mappings not only to the box primitive but to
all shapes seems to have some merit, as the same internal mechanism
could also be used to solve the problem of left-handed vs. right-handed
coordinate systems.

Post a reply to this message

On 10/27/2016 03:25 AM, clipka wrote:

> Potential candidates that spring to my mind are some 360 degree panorama
> formats:
>
> - Paul Debevec's "Vertical Cross Cube" format
> - Quicktime VR cubic format
> - SPi-V cubic format

    Is there any patent on those formats ?

Post a reply to this message

Am 27.10.2016 um 13:32 schrieb tth:
> On 10/27/2016 03:25 AM, clipka wrote:
> 
>> Potential candidates that spring to my mind are some 360 degree panorama
>> formats:
>>
>> - Paul Debevec's "Vertical Cross Cube" format
>> - Quicktime VR cubic format
>> - SPi-V cubic format
> 
>    Is there any patent on those formats ?

I don't think so; it's pretty low in terms of level of inventiveness, so
probably won't qualify for a patent.

Post a reply to this message

Le 26/10/2016 à 17:55, Le_Forgeron a écrit :
> Le 26/10/2016 à 01:20, clipka a écrit :
>> Am 25.10.2016 um 18:55 schrieb Le_Forgeron:
>>
>>> You should also have a look at box uv_mapping... it's strange too.
>>>
>>> You can read it from the inside.
>>
>> Caution: The question whether you can read text from the outside or
>> inside depends not only on the UV mapping scheme, but also on the
>> handedness of the coordinate system.
>>
> 
> Oh, another parameter in the equation then. Are you sure of that ?
> 
> All work and no play makes jack...
> 

Ok, current state of hgpovray:
(did I forget any object ?)

left handed
===========
bicubic_patch
lathe bezier (start +x, go +z)
lathe cubic (start +x, go +z)
lathe linear (start +x, go +z)
lathe quadratic (start +x, go +z)
sor (start +x, go +z)
sphere (start +x, go +z)
sphere_sweep (b )
sphere_sweep (cubic)
sphere_sweep (linear)

right handed
============
box (wrapping)
cone (start +x, go +y)

problem
=======
cylinder (right handed, start +x, go -y)
lemon (right handed, start +x, go -y)
ovus (right handed, start +x, go +z, bottom ?)
torus (right handed, start -x, go +z)

strange (interior/exterior)
===========================
parametric (left handed, strange)
prism bezier (strange)
prism cubic (strange)
prism linear (strange)
prism quadratic (strange)
mesh (strange)

not mapped, but no problem
==========================
blob
disc
isosurface
julia_fractal
plane
polygon
polynomial
smooth_triangle
superellipsoid
text
triangle
height_field


The historical uv-mapping of the torus is not similar to the sphere, in
regard to the starting axis and handness.

The sphere_sweep is extending the u axis along the sweep, similar to the
torus along the major circle, so should be kept.

the bottom face of prism is not the correct texture for interior vs
exterior (compared to similar topological object like sphere)
(And hg-povray already got a correction for text object on that)

The mesh & parametric are screwed:
* cannot be predicted for interior vs exterior
* parametric with a continuous surface changes interior & exterior in middle
* parametric are not reporting all intersections and hole appears when
clipped or intersected

Post a reply to this message

Attachments:
Download 'refimgobject_parametric.png' (747 KB) Download 'refimgobject_sphere.png' (669 KB) Download 'refimgobject_torus.png' (634 KB)

Preview of image 'refimgobject_parametric.png'

Preview of image 'refimgobject_sphere.png'

Preview of image 'refimgobject_torus.png'