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