Difference between revisions of "Talk:Touch Coordinates"

From Second Life Wiki
Jump to navigation Jump to search
m
Line 1: Line 1:
== Proposal A==
Might be better implemented as providing the texture U and V. This would keep code simple when a texture spans a few surfaces, and would make the use more clear with spheres, tori, etc.
Might be better implemented as providing the texture U and V. This would keep code simple when a texture spans a few surfaces, and would make the use more clear with spheres, tori, etc.
--[[User:Moshe Sapwood|Moshe Sapwood]] 09:31, 26 January 2007 (PST)
--[[User:Moshe Sapwood|Moshe Sapwood]] 09:31, 26 January 2007 (PST)
Line 10: Line 11:
What about hollow prims? The inside of the prim can have several "sides" so the coordinates would be very unpredictable in both yx and uv. Also UV points may not be helpful if the texture repeats multiple times across the same face. This idea just needs more thought and it should be well accepted in the feature proposal area. If this idea is proposed please post a link. [[User:TxMasterG Ping|TxMasterG Ping]] 20:29, 30 March 2007 (PDT)
What about hollow prims? The inside of the prim can have several "sides" so the coordinates would be very unpredictable in both yx and uv. Also UV points may not be helpful if the texture repeats multiple times across the same face. This idea just needs more thought and it should be well accepted in the feature proposal area. If this idea is proposed please post a link. [[User:TxMasterG Ping|TxMasterG Ping]] 20:29, 30 March 2007 (PDT)


It'd be nice if it had some sort of visual feedback on the screen to show where you're pointing, like in Doom 3. In fact, text field support and reactive buttons would be even nicer, albeit far far more complicated to implement. [[User:Bbot Dmytryk|Bbot Dmytryk]] 23:22, 1 April 2007 (PDT)


It'd be nice if it had some sort of visual feedback on the screen to show where you're pointing, like in Doom 3. In fact, text field support and reactive buttons would be even nicer, albeit far far more complicated to implement. [[User:Bbot Dmytryk|Bbot Dmytryk]] 23:22, 1 April 2007 (PDT)
==Proposal B==
 
I've split the proposal, Proposal B addresses the issues of repeats and resizing. What neither proposal addresses is Planar Mapping. [[User:Strife Onizuka|Strife Onizuka]] 15:26, 2 April 2007 (PDT)

Revision as of 15:26, 2 April 2007

Proposal A

Might be better implemented as providing the texture U and V. This would keep code simple when a texture spans a few surfaces, and would make the use more clear with spheres, tori, etc. --Moshe Sapwood 09:31, 26 January 2007 (PST)

No problem with that, just as long as it's persistent through size changes to relief the script of having to get texture size, offset, prim size and all that and calculate the button positions dynamically all the time. --Fairlight Lake 19:10, 26 January 2007 (CET)

Sure, UVs are normally done ranging 0-1. For the default texture mapping on a cube, the returned result would be identical for face coordinates as in the proposal, and for texture coordinates. --Moshe Sapwood 08:30, 28 January 2007 (PST)

What about hollow prims? The inside of the prim can have several "sides" so the coordinates would be very unpredictable in both yx and uv. Also UV points may not be helpful if the texture repeats multiple times across the same face. This idea just needs more thought and it should be well accepted in the feature proposal area. If this idea is proposed please post a link. TxMasterG Ping 20:29, 30 March 2007 (PDT)

It'd be nice if it had some sort of visual feedback on the screen to show where you're pointing, like in Doom 3. In fact, text field support and reactive buttons would be even nicer, albeit far far more complicated to implement. Bbot Dmytryk 23:22, 1 April 2007 (PDT)

Proposal B

I've split the proposal, Proposal B addresses the issues of repeats and resizing. What neither proposal addresses is Planar Mapping. Strife Onizuka 15:26, 2 April 2007 (PDT)