[sldev] Implementing extensions in the Open Source client only.

[Fairlight]

Sorry, could be done client-side, I meant.


On Sat, 27 Jan 2007 00:02:11 +0100, Fairlight <fairlight at tigress.com>  
wrote:

> Hi!
>
> Well, it would be doable server side, making the client send out  
> soemthing on a special channel.. but that'd be a, pardon my words, pain  
> in the ass way to do it, not the proper way.. the proper way would be to  
> do it just like the other llDetected...() commands, as this would make  
> the most sense.. but the downside of it is that it'd definitively  
> require linden support on implementation...
>
> Woot! It's weekend!
>   Fairlight Lake!
>
>
> On Fri, 26 Jan 2007 23:36:49 +0100, Argent Stonecutter  
> <secret.argent at gmail.com> wrote:
>
>> Sorry about the last digest being mostly my responses, they were  
>> delayed an "crossed in the post".
>>
>> Getting back to the Open Source client... :)
>>
>>> I got a new Feature Request about getting feedback of the touched  
>>> coordinates on a side of a prim. This would enable to save prims on  
>>> HUDs and other control panel-like objects.
>>>
>>> (Think "imagemap" in html.. basically.)
>>>
>>> https://wiki.secondlife.com/wiki/Feature_Request_Touch_Coordinates
>>>
>>> Please discuss there and feel free to add to the pros and cons.
>>
>> Can you think of a way that this could be implemented using the open  
>> source client code only?
>>
>> I don't see a way to do it using the ClickAction message, perhaps the  
>> client could detect clicks on a special tagged texture (shared common  
>> UUID, like the invisiprim UUIDs) and send a formatted message to a well  
>> known channel?
>>
>> I was thinking of special tagged textures like that today for  
>> implementing mirrors, using a variant on the freeze-frame snapshot  
>> mechanism.
>>
>> When a texture with a specific UUID was displayed on a flat face (to  
>> simplify things, you wouldn't allow curved mirrors), each frame the  
>> client would run a rendering pass from the mirrored viewpoint clipped  
>> to the mirror's bounds, and render the resulting texture in place of  
>> the mirror. This should take significantly less time than a full frame  
>> unless the mirror is almost filling the frame... in which case most of  
>> the frame would be masked. The case of multiple mirrors could be  
>> ignored... only the closest mirror to the avatar would be rendered as a  
>> mirror, the rest would show the underlying texture.
>>
>> This could be done without any changes to the sim-side software.
>>
>> What are the downsides of this approach?
>>
>> 1. Getting Linden Labs to pick up the code after it's done. If it's  
>> cool enough that shouldn't be a problem.
>>
>> 2... ?
>> _______________________________________________
>> Click here to unsubscribe or manage your list subscription:
>> /index.html
>
>
>



-- 
                         (`.-,')  
--------------------------------------------
                      .-'     ;               F a i r l i g h t
                  _.-'   , `,-          t h e   w h i t e   l i o n
            _ _.-'     .'  /._
          .' `  _.-.  /  ,'._;)   E-mail:              fairlight at tigress.com
         (       .  )-| (         Homepage: http://www.tigress.com/fairlight
          )`,_ ,'_,'  \_;)  fL    Puppetry          E-Mail: pawpet at pawpet.de
  ('_  _,'.'  (___,))             Puppetry Homepage:    http://www.pawpet.de
   `-:;.-'                        
--------------------------------------------