Difference between revisions of "Talk:LlDetectedTouchUV"

From Second Life Wiki
Jump to navigation Jump to search
(Created page with "If someone would please look at the following with an editor's eye, I'd like to add this clarification to the page. Should there also be an example of how offsets can make the re…")
 
m (Replaced <lsl> with <syntaxhighlight>)
 
(5 intermediate revisions by 2 users not shown)
Line 1: Line 1:
=== Offsets and repeats need to be clarified ===
This topic was recently discussed on Jira at {{JIRA|SVC-8090}}, here is an excerpt.
{{Quote|1=
<h4>Moon Metty added a comment - 06/Aug/12 3:14 PM</h4>
Yes Spootie, UV is very handy for that kind of menu. :)
Strife, maybe this is a start:
llDetectedTouchUV() returns the texture coordinates where an object was clicked.
The result is the same as llDetectedTouchST() transformed by UV-repeats, -offset and -rotation.
Where ST coordinates are always in the interval [0, 1] , UV coordinates are not because of the transformation,
Example:
When we wrap a UV coordinate in [0, 1] , the result represents a location in the texture. This is the fractional part of llDetectedTouchUV().
The integer part (rounded down for positive and negative numbers) represents which repetition of the texture was clicked.
<syntaxhighlight lang="lsl2">
touch_start(integer num_detected)
{
vector UV = llDetectedTouchUV(0); // store the UV coordinates as a vector variable
integer repetition_x = llFloor(UV.x); // round the x coordinate down
integer repetition_y = llFloor(UV.y); // round the y coordinate down
float texture_x = UV.x - repetition_x; // calculate the fractional part of x
float texture_y = UV.y - repetition_y; // calculate the fractional part of y
}
</syntaxhighlight>
----
Planar mapping has never worked well (see {{Jira|MAINT-667}}, {{Jira|VWR-4860}} or search the jira for "planar")
However, no matter how mangled the texture looks, [[llDetectedTouchUV]] still appears to return the correct result, which is nice.
}}
{{Quote|1=
<h4>Spootie added a comment - 06/Aug/12 11:45 PM</h4>
Moon's approach that considers DetectedTouchUV as a transformation of DetectedTouchST is an interesting, if sometimes confusing approach, at least for someone who came to DetectedTouchUV looking for a way to determine simply where on a texture one clicks. I came to think of a texture as a map, irregardless of what part of the map was shown on the face. Strife schooled me here on how detecting which of multiple copies might be useful, and now Moon is schooling me on a different, equally valid paradigm.
You can see an expression of my different approach on the discussion page, signed by Windy Schor. I do like Moon's LSL example better than my own.
Strife's point about future mapping issues makes me lean away from mixing ST into the UV explanation.
Another source of confusion is that a positive fractional offset puts us in a >1 repeat.
Let's take any further discussion to the page itself, since this clearly isn't a bug.
Thank you Moon and Strife for your input.
}}
If someone would please look at the following with an editor's eye, I'd like to add this clarification to the page. Should there also be an example of how offsets can make the results be offset?
If someone would please look at the following with an editor's eye, I'd like to add this clarification to the page. Should there also be an example of how offsets can make the results be offset?


llDetectedTouchUV returns the U,V corresponding to the part of the texture touched, plus any U and V index of tiled repeats. For example, if you set two repeats vertically and one horizontally, with no texture-offset and no texture-rotation, clicking in the middle of the upper half yields <1.5,0.5,0.0> and clicking in the exactly same spot on the lower copy of the texture, i.e. the middle of the bottom half, yields <0.5,0.5,0.0>. Thanks to this feature, one can determine not only where on a texture the touch was detected, but on which repeat of the texture, in case that matters.
llDetectedTouchUV returns the U,V corresponding to the part of the texture touched, plus any U and V index of tiled repeats. For example, if you set two repeats vertically and one horizontally, with no texture-offset and no texture-rotation, clicking in the middle of the upper half yields <1.5,0.5,0.0> and clicking in the exact same spot on the lower copy of the texture, i.e. the middle of the bottom half, yields <0.5,0.5,0.0>. Thanks to this feature, one can determine not only where on a texture the touch was detected, but on which repeat of the texture, in case that matters.


The position touched on the texture, ignoring repeats and/or determining which repeat, is determined thusly:
The position touched on the texture, ignoring repeats and/or determining which repeat, is determined thusly:
<lsl>
<syntaxhighlight lang="lsl2">
vector DTUV=llDetectedTouchUV(index);
vector DTUV=llDetectedTouchUV(index);
vector position_on_texture = <DTUV.x - (float)llFloor(DTUV.x), DTUV.y - (float)llFloor(DTUV.y), 0.0>;
vector position_on_texture = <DTUV.x - (float)llFloor(DTUV.x), DTUV.y - (float)llFloor(DTUV.y), 0.0>;
list which_repeat = [ llFloor(DTUV.x), llFloor(DTUV.y) ];
list which_repeat = [ llFloor(DTUV.x), llFloor(DTUV.y) ];
</lsl>
</syntaxhighlight>
[[User:Windy Schor|Windy Schor]] 18:08, 6 August 2012 (PDT)
[[User:Windy Schor|Windy Schor]] 18:08, 6 August 2012 (PDT)
I like Moons rewording. But I also see where Spootie/Windy is coming from and that wording needs to be incorporated as well. I like Moons wording because it's technically detailed but I like Spooties because it gives a better overview of the usage. Both are critical. -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 09:05, 7 August 2012 (PDT)

Latest revision as of 00:28, 30 May 2023

Offsets and repeats need to be clarified

This topic was recently discussed on Jira at SVC-8090, here is an excerpt.

Moon Metty added a comment - 06/Aug/12 3:14 PM

Yes Spootie, UV is very handy for that kind of menu. :)

Strife, maybe this is a start:

llDetectedTouchUV() returns the texture coordinates where an object was clicked. The result is the same as llDetectedTouchST() transformed by UV-repeats, -offset and -rotation. Where ST coordinates are always in the interval [0, 1] , UV coordinates are not because of the transformation,

Example:

When we wrap a UV coordinate in [0, 1] , the result represents a location in the texture. This is the fractional part of llDetectedTouchUV(). The integer part (rounded down for positive and negative numbers) represents which repetition of the texture was clicked.

touch_start(integer num_detected) 
{
	vector UV = llDetectedTouchUV(0); // store the UV coordinates as a vector variable
	integer repetition_x = llFloor(UV.x); // round the x coordinate down
	integer repetition_y = llFloor(UV.y); // round the y coordinate down
	float texture_x = UV.x - repetition_x; // calculate the fractional part of x
	float texture_y = UV.y - repetition_y; // calculate the fractional part of y
}

Planar mapping has never worked well (see MAINT-667, VWR-4860 or search the jira for "planar")

However, no matter how mangled the texture looks, llDetectedTouchUV still appears to return the correct result, which is nice.

Spootie added a comment - 06/Aug/12 11:45 PM

Moon's approach that considers DetectedTouchUV as a transformation of DetectedTouchST is an interesting, if sometimes confusing approach, at least for someone who came to DetectedTouchUV looking for a way to determine simply where on a texture one clicks. I came to think of a texture as a map, irregardless of what part of the map was shown on the face. Strife schooled me here on how detecting which of multiple copies might be useful, and now Moon is schooling me on a different, equally valid paradigm. You can see an expression of my different approach on the discussion page, signed by Windy Schor. I do like Moon's LSL example better than my own. Strife's point about future mapping issues makes me lean away from mixing ST into the UV explanation. Another source of confusion is that a positive fractional offset puts us in a >1 repeat. Let's take any further discussion to the page itself, since this clearly isn't a bug.

Thank you Moon and Strife for your input.

If someone would please look at the following with an editor's eye, I'd like to add this clarification to the page. Should there also be an example of how offsets can make the results be offset?

llDetectedTouchUV returns the U,V corresponding to the part of the texture touched, plus any U and V index of tiled repeats. For example, if you set two repeats vertically and one horizontally, with no texture-offset and no texture-rotation, clicking in the middle of the upper half yields <1.5,0.5,0.0> and clicking in the exact same spot on the lower copy of the texture, i.e. the middle of the bottom half, yields <0.5,0.5,0.0>. Thanks to this feature, one can determine not only where on a texture the touch was detected, but on which repeat of the texture, in case that matters.

The position touched on the texture, ignoring repeats and/or determining which repeat, is determined thusly:

vector DTUV=llDetectedTouchUV(index);
vector position_on_texture = <DTUV.x - (float)llFloor(DTUV.x), DTUV.y - (float)llFloor(DTUV.y), 0.0>;
list which_repeat = [ llFloor(DTUV.x), llFloor(DTUV.y) ];

Windy Schor 18:08, 6 August 2012 (PDT)

I like Moons rewording. But I also see where Spootie/Windy is coming from and that wording needs to be incorporated as well. I like Moons wording because it's technically detailed but I like Spooties because it gives a better overview of the usage. Both are critical. -- Strife (talk|contribs) 09:05, 7 August 2012 (PDT)