POV-Ray : Newsgroups : povray.beta-test : Some existing uv_mapping flipped. Porting Cylinder, cone uv_mapping. Server Time
28 Mar 2024 04:42:25 EDT (-0400)
  Some existing uv_mapping flipped. Porting Cylinder, cone uv_mapping. (Message 4 to 13 of 13)  
<<< Previous 3 Messages Goto Initial 10 Messages
From: William F Pokorny
Subject: Re: Some existing uv_mapping flipped. Porting Cylinder, coneuv_mapping.
Date: 26 Oct 2016 11:43:58
Message: <5810cf3e$1@news.povray.org>
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

From: Le Forgeron
Subject: Re: Some existing uv_mapping flipped. Porting Cylinder,coneuv_mapping.
Date: 26 Oct 2016 11:55:21
Message: <5810d1e9$1@news.povray.org>
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

From: Stephen
Subject: Re: Some existing uv_mapping flipped. PortingCylinder,coneuv_mapping.
Date: 26 Oct 2016 12:22:54
Message: <5810d85e$1@news.povray.org>
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

From: clipka
Subject: Re: Some existing uv_mapping flipped. Porting Cylinder,coneuv_mapping.
Date: 26 Oct 2016 21:25:57
Message: <581157a5$1@news.povray.org>
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

From: tth
Subject: Re: Some existing uv_mapping flipped. PortingCylinder,coneuv_mapping.
Date: 27 Oct 2016 07:25:04
Message: <5811e410@news.povray.org>
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

From: clipka
Subject: Re: Some existing uv_mapping flipped. PortingCylinder,coneuv_mapping.
Date: 27 Oct 2016 07:38:57
Message: <5811e751$1@news.povray.org>
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

From: Le Forgeron
Subject: Re: Some existing uv_mapping flipped. PortingCylinder,coneuv_mapping.
Date: 30 Oct 2016 15:53:06
Message: <58164fa2@news.povray.org>
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'
refimgobject_parametric.png

Preview of image 'refimgobject_sphere.png'
refimgobject_sphere.png

Preview of image 'refimgobject_torus.png'
refimgobject_torus.png


 

From: William F Pokorny
Subject: Re: Some existing uv_mapping flipped. PortingCylinder,coneuv_mapping.
Date: 31 Oct 2016 10:25:39
Message: <58175463$1@news.povray.org>
On 10/30/2016 03:52 PM, Le_Forgeron wrote:
> 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
>

Lines up reasonably well with where I think hgpovray is. A few 
questions/comments:

- I'm assuming your information is relative to only the uv_mapping 
mechanism?

- Is the cone and cylindrical behavior really different as you show? The 
underlying code for the cone, cylinder & uv_mapping is identical, right?

- Many objects are listed as not mapped, but I think when we use 
uv_mapping with those we'll get a default planar mapping.

- To keep track, the odd prism behavior has a github issue open against 
it in #65.

- The parametric being unstable doesn't surprise me too much. You've 
grouped the mesh with it in not being able to determine inside vs 
outside. You know about the inside vector I'm sure, so am I correct you 
are talking about the normals & glancing ray issue like github #121 & 
#132 and perhaps the occasional situation where the inside vector has 
the misfortune to align with one or more of the triangles in the mesh? 
Anything additional ?

- I thought you added normal determination and mapping to your new 
hgpovray nurbs surface. If I'm remembering this correctly, did you not 
list it because it is an hgpovray only feature?

-----------

As for the right vs left handed systems part of the review and 
discussion I want to start with the disclaimer I'm far from experienced 
with moving scenes / models between the two conventions. In fact, I 
don't myself do much uv_mapping.

That said, my first reaction to our mapping flipping around in left vs 
right conventions is - of course it does. Further, given POV-Ray's 
ability to flip up, right and direction in the camera, we can scramble 
mappings (and more) working entirely within any left or right handed 
coordinate system with respect to any particular scene view.

Add user_defined cameras and the new hgpovray arrayed multiple cameras, 
where any handedness is by ray at best, not determinable at all in the 
worst case, and I'm more than a little fuzzy on what kinds of map 
improvements with respect to handedness we are chasing?

Are we thinking perhaps about additional parameters to "uv_mapping" et 
al to help with the mapping element of moving from one handed convention 
to another? Are we thinking of other features or are we just trying to 
get to where POV-Ray and its derivatives are consistent?

Thanks for your time.

Bill P.


Post a reply to this message

From: Le Forgeron
Subject: Re: Some existing uv_mapping flipped. PortingCylinder,coneuv_mapping.
Date: 1 Nov 2016 08:25:57
Message: <581889d5$1@news.povray.org>
Le 31/10/2016 à 15:25, William F Pokorny a écrit :
> Lines up reasonably well with where I think hgpovray is. A few
> questions/comments:
> 
> - I'm assuming your information is relative to only the uv_mapping
> mechanism?

Yes

> 
> - Is the cone and cylindrical behavior really different as you show? The
> underlying code for the cone, cylinder & uv_mapping is identical, right?
> 

They share the same base, but a true cone is not a cylinder

> - Many objects are listed as not mapped, but I think when we use
> uv_mapping with those we'll get a default planar mapping.
> 

it's not really a mapping


> - To keep track, the odd prism behavior has a github issue open against
> it in #65.

Nice.


> - I thought you added normal determination and mapping to your new
> hgpovray nurbs surface. If I'm remembering this correctly, did you not
> list it because it is an hgpovray only feature?

Oh, right, I forgot the rational_bezier_patch, which is a viewable object.
Nurbs, on the other hand, is like spline: an abstraction which must be
sampled as mesh to be viewed.


> 
> -----------
> 
> As for the right vs left handed systems part of the review and
> discussion I want to start with the disclaimer I'm far from experienced
> with moving scenes / models between the two conventions. In fact, I
> don't myself do much uv_mapping.
> 
> That said, my first reaction to our mapping flipping around in left vs
> right conventions is - of course it does. Further, given POV-Ray's
> ability to flip up, right and direction in the camera, we can scramble
> mappings (and more) working entirely within any left or right handed
> coordinate system with respect to any particular scene view.
> 
> Add user_defined cameras and the new hgpovray arrayed multiple cameras,
> where any handedness is by ray at best, not determinable at all in the
> worst case, and I'm more than a little fuzzy on what kinds of map
> improvements with respect to handedness we are chasing?

I would go for uniformity. But that is doomed, from box :-)

I'm going to change cylinder, cone, ovus and lemon to join the sphere
(left handed for text reading...),
and I wonder if the torus should be "corrected" or remain a curiosity
like box.


> 
> Are we thinking perhaps about additional parameters to "uv_mapping" et
> al to help with the mapping element of moving from one handed convention
> to another? Are we thinking of other features or are we just trying to
> get to where POV-Ray and its derivatives are consistent?
> 

I won't add any parameter nor options.
you can always transform the texture afterwards. (scale <-1,1,1> and
friends)

> Thanks for your time.
> 
> Bill P.


Post a reply to this message

From: William F Pokorny
Subject: Re: Some existing uv_mapping flipped. PortingCylinder,coneuv_mapping.
Date: 16 Nov 2016 09:42:56
Message: <582c7070@news.povray.org>
On 11/01/2016 08:25 AM, Le_Forgeron wrote:
> Le 31/10/2016 à 15:25, William F Pokorny a écrit :
>
> I'm going to change cylinder, cone, ovus and lemon to join the sphere
> (left handed for text reading...),
> and I wonder if the torus should be "corrected" or remain a curiosity
> like box.
>
I see you've made these changes in hgpovray and left the torus as is.

As for POV-Ray proper Christoph has decided to leave the torus mapping 
as is in the main line POV-Ray versions so we are aligned.

I'll suggest we add a note for the torus that the uv_mapping is reversed 
from all others in U when we update the documentation to add the new 
cone and cylinder mapping. Perhaps save others some confusion.

Thanks,
Bill P.


Post a reply to this message

<<< Previous 3 Messages Goto Initial 10 Messages

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