Am 05.09.2018 um 06:23 schrieb clipka:

> Otherwise, there are probably better names to pick. "uv_orientation", maybe?

... or "uv_seam_direction"?

Post a reply to this message

On 9/5/2018 12:23 AM, clipka wrote:
> I'm looking at the warps' "orientation" parameter right now, and it
> gives me headaches. What is it even? A vector in pigment space to pick a
> different slice of the pigment? A vector in shape space to orient the
> torus/sphere/cylinder?

You're the one who's supposed to know!

:D

Post a reply to this message

Le 04/09/2018 à 22:43, Bald Eagle a écrit :
> Le_Forgeron <jgr### [at] freefr> wrote:
> 
>>> So, one or two keywords to find, meaningful... and short, but not
>>> ambiguous.
>>
>> And the tie is now between:
>> * **direction**, as used in camera and rainbow
>> * **orientation**, as used in warp (cylindrical, spherical, toroidal)
>>
>> Any preferences ?
> 
> Do you want to [re]use other keywords?
> What about axis, or alignment, or maybe as clipka said - half_plane ?
> 

If it can match an existing keyword and its concept, it make:
1. less concept to explain
2. less work to code
3. less keyword to remember
4. less confusion in the end

The hell would be a SDL with every subpart having its own private set of 
keywords, because "it was not exactly the same concept, nor the same 
thing, so it has to be a dedicated keyword."

Imagine cylinder and sphere declaration using keywords:

cylinder{ disc_center_base_position <v>, disc_center_apex_position <w>, 
radius_of_cylinder r }

sphere { center_sphere_position <v>, radius_of_sphere r }

That's not user-friendly.




TBH, I did not even remembered that there was a rainbow in Pov-Ray.

Post a reply to this message

Le 05/09/2018 à 06:23, clipka a écrit :
> Am 04.09.2018 um 19:16 schrieb Le_Forgeron:
>> Le 04/09/2018 à 13:28, Le Forgeron a écrit :
>>>
>>> Oh, I didn't notice uv_mapping was an object modifier, and not a pattern
>>> (texture/pigment/... ) only.
>>
>>> So, one or two keywords to find, meaningful... and short, but not
>>> ambiguous.
>>
>> And the tie is now between:
>> * **direction**, as used in camera and rainbow
>> * **orientation**, as used in warp (cylindrical, spherical, toroidal)
> 
> I'm looking at the warps' "orientation" parameter right now, and it
> gives me headaches. What is it even? A vector in pigment space to pick a
> different slice of the pigment? A vector in shape space to orient the
> torus/sphere/cylinder?

For me it's the dist_exp which is more obscure: it's explained for 0, 
but what are other value ? (btw, a "box" (2D) <0,0> to <1,1> extended to 
infinity along orientation... isn't that a square and a normal to 
select... what ? On second reading, the box is infinite along 
orientation and a square in perpendicular directions.

And what is that "distance" in the text ?

Yet another case of: better open the source to understand.


At least, I understand "planar", but there is no picture for it !
And "cubic", nice cubic !

> 
>> Any preferences ?
> 
> If "orientation" in warps does exactly(!) the same, that would be the
> parameter name to use.
> 
> Otherwise, there are probably better names to pick. "uv_orientation", maybe?
> 

it would rather be u_orientation, or u_something, as v is already set by 
the shape and its symetry. u_zero ?

"second_base_vector_of_half_plane_with_symetry_axis_where_u_is_zero" is 
far too long.

I would like to avoid more than one "_" if possible (so u_zero_direction 
is one word too long). Two words is nice (look_at, point_at), but three 
or more words become painful (yet, I added rational_bezier_patch 
elsewhere, so it's not so wrong, just if it could be avoided).

Oh, and for sphere_sweep, it would be the direction of u=0 for v=0, yet 
later along the sweep it would turn for continuity.

Native speakers, you're welcome !

Post a reply to this message

Am 05.09.2018 um 08:22 schrieb Le Forgeron:

> If it can match an existing keyword and its concept, it make:
> 1. less concept to explain
> 2. less work to code
> 3. less keyword to remember
> 4. less confusion in the end

On the other hand, it needs to be noted that if the name or concept is
somewhat off, it may ADD confusion.

Post a reply to this message

Am 05.09.2018 um 07:27 schrieb Mike Horvath:
> On 9/5/2018 12:23 AM, clipka wrote:
>> I'm looking at the warps' "orientation" parameter right now, and it
>> gives me headaches. What is it even? A vector in pigment space to pick a
>> different slice of the pigment? A vector in shape space to orient the
>> torus/sphere/cylinder?
> 
> You're the one who's supposed to know!

Not invented here, so why should I have any idea how it works? ;)

Post a reply to this message

Am 05.09.2018 um 09:03 schrieb Le Forgeron:

>> If "orientation" in warps does exactly(!) the same, that would be the
>> parameter name to use.
>>
>> Otherwise, there are probably better names to pick. "uv_orientation",
>> maybe?
>>
> 
> it would rather be u_orientation, or u_something, as v is already set by
> the shape and its symetry. u_zero ?

"UV" in the sense of "UV mapping" as the whole concept.

> "second_base_vector_of_half_plane_with_symetry_axis_where_u_is_zero" is
> far too long.

A tad, yes ;)

Post a reply to this message

Am 05.09.2018 um 06:23 schrieb clipka:

>> And the tie is now between:
>> * **direction**, as used in camera and rainbow
>> * **orientation**, as used in warp (cylindrical, spherical, toroidal)
> 
> I'm looking at the warps' "orientation" parameter right now, and it
> gives me headaches. What is it even? A vector in pigment space to pick a
> different slice of the pigment? A vector in shape space to orient the
> torus/sphere/cylinder?

One thing I can say by now is that the `orientation` vector in e.g.
cylindrical `warp` does /not/ change the orientation in shape space;
there, the rotational axis of the pattern always extends along the Y
axis, and the seam is always in the same place as well.

So re-using the same keyword for the scene-space orientation of UV
mapping seams would be prone to adding confusion.


Instead, the `orientation` vector governs what axes correspond to
"height", "angle" and "radius", respectively.

My best bet is that the math was hand-crafted/hacked/botched to get
certain effects for the special cases `orientation x`, `orientation y`
and `orientation z` - namely giving pattern-space orientation zYX, XZy
and XYZ, respectively (`zYX` e.g. meaning that the "angle" corresponds
to negative Z, the "height" to positive Y, and the "radius" to positive
X). The design goal for chosing these specific three orientations may
have been to make the "height", "angle" and "radius" axes
"right-handed", perpendicular and normalized, let the axis aligned with
X have positive orientation, and let the "radius" axis be aligned with
the `orientation` vector.

Not much care seems to have gone into the formula otherwise; most
notably, if the `orientation` vector is not axis-alinged, the effect
does _not_ correspond to a straightforward re-orientation (i.e.
rotation) of the "height", "angle" and "radius" axes in pattern space,
but rather includes anisotropic scaling (and maybe also shearing; I
didn't examine that), even if the `orientation` vector is normalized.


Fun fact: The optional VECTOR parameter of the `planar` warp applies
exactly the same kind of transformangling, although it doesn't use the
keyword.

Post a reply to this message

uv_reference is the winner, works for cylinder, disc, cone, lemon and
sphere_sweep in hgpovray38

cone { -y * 0.5, 0.5, 0.5 * y, 0.25  uv_reference x texture { Verso }

cylinder { -y * 0.5, 0.5 * y, 0.5 uv_reference x  texture { Verso }

lemon {-0.5 * y, .5, 0.5 * y, .25, 1.5 uv_reference x texture { Verso }

ovus { 0.5, 0.25 distance 1 radius 2.5 texture { Verso }

disc { 0, -y, 1, 0.125 uv_reference x texture { Verso }

//
sphere { 0, 0.5 texture { Verso }

torus { 0.65, 0.25 texture { Verso }

box{ -0.5, 0.5  texture { Verso }

sphere_sweep{ cubic_spline 5 ,
  0, .5,
  1*y,0.35
  2*y,0.5
  3*y,0.35
  4*y,0.5
  uv_reference x texture { Verso }

Post a reply to this message

Attachments:
Download 'refimguvmapping.png' (290 KB)

Preview of image 'refimguvmapping.png'

Am 08.09.2018 um 19:18 schrieb Le_Forgeron:
> uv_reference is the winner, works for cylinder, disc, cone, lemon and
> sphere_sweep in hgpovray38

Sounds reasonable enough.

For some nitpicking though, your examples do have a lot of missing
closing braces, and some lack the uv_reference modifier ;)

Post a reply to this message