Difference between revisions of "Talk:Touch Coordinates"
| Line 1: | Line 1: | ||
= General = | |||
What neither proposal addresses is Planar Mapping. I suspect regardless, that implementing this will require changes to the Rendering Pipeline. [[User:Strife Onizuka|Strife Onizuka]] 15:35, 2 April 2007 (PDT) | |||
== Proposal A== | == 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. | ||
| Line 15: | Line 19: | ||
==Proposal B== | ==Proposal B== | ||
I've split the proposal, Proposal B addresses the issues of repeats and resizing | I've split the proposal, Proposal B addresses the issues of repeats and resizing. From my proposal I stripped the link-number since there is already a [[llDetectedLinkNumber]]. I did this because it's easier to handle a vector then a list (less cpu intensive). [[User:Strife Onizuka|Strife Onizuka]] 15:26, 2 April 2007 (PDT) | ||
Revision as of 15:35, 2 April 2007
General
What neither proposal addresses is Planar Mapping. I suspect regardless, that implementing this will require changes to the Rendering Pipeline. Strife Onizuka 15:35, 2 April 2007 (PDT)
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. From my proposal I stripped the link-number since there is already a llDetectedLinkNumber. I did this because it's easier to handle a vector then a list (less cpu intensive). Strife Onizuka 15:26, 2 April 2007 (PDT)