[Opensim-dev] OnLook viewer and opensim support modules

Sun Nov 9 00:55:30 UTC 2014

It's always good to see new project appearing on the horizon and I think
Singularity indeed is the better viewer to implement this in.

However, I would also like to ask to update the Wiki about this, what
exactly works how as soon as things are being crystalised.

That way it's also easier for other people that are looking into doing
something like this for answers when they are getting stuck writing modules
that interact with viewers.

2014-11-07 18:36 GMT+01:00 Diva Canto <diva at metaverseink.com>:

> Cool! That's really where I would like to take OnLook, but leveraging the
> fantastic job that Linden Lab has done with the rendering engine that is
> really hard to reproduce with other technologies (e.g. WebGL) without
> investing a couple of million dollars (and even so...)
>
> There's really two parts to customization: (1) customizing the elements
> that are already customizable viewer-side -- so show/hide things, move
> things around, etc; and (2) allowing arbitrary new UI. The first part is
> relatively safe, and that's what we're focusing as the starting point; the
> second part can potentially be a can of worms, so we need to be careful.
>
>
> On 11/6/2014 11:38 PM, Toni Alatalo wrote:
>
>> Just a note for completeness: we achieved the same goal by client-side
>> scripting. The scene on the server side can refer to scripts that the
>> clients load. The client side api allows creating gui widgets, reading
>> input to control a camera or avatar or whatever etc. I mean in the
>> Naali -> Tundra effort (first with opensimulator as server and later
>> without). That's how all realXtend worlds for example on Meshmoon work
>> (with the native client). Scripts components have an attribute telling
>> whether that script is meant for server, client or both and then a
>> (http) ref to the script source.
>>
>> This is I think actually similar to what web browsers do -- there
>> typically client side scripts define the GUI and view control
>> behaviours etc (think e.g. facebook & gmaps). HTML pointing to JS
>> files.
>>
>> This is not without problems as the security concerns for having the
>> viewer/client execute arbitrary code on your computer as you visit
>> various worlds are complex and severe. Basically requires a sandbox
>> like web browsers have. Which is one of the reasons why at least us at
>> Playsign focus on using the browser based client in normal business --
>> the browser vendors and participating dev communities have done the
>> best the world has for a secure freely programmable environment.
>>
>> In the c++ client we use Qt's qtscript for the client side Javascript
>> -- I believe the slviewer base has qt too (for webviews?) so might be
>> simple to add it there too. But as said then you'd need to worry about
>> the sandboxing. We've ~solved it by limiting the parts of qt that
>> scrips loaded from the net can call (no filesystem or network access).
>>
>> So I think your limited solution can make sense and be a good start
>> with the slviewer base! I mean just defining buttons or a fixed UI/cam
>> mode can be useful yet safe.
>>
>> One option for enabling arbitrary GUIs in the future might be using
>> webviews. You could allow authors to point to a html (with further
>> refs to css and js) and show that as an overlay in the viewer. This
>> way creators could define the looks how they want. Sirikata took this
>> approach many years ago in their c++ viewer. I've also tested it in
>> Naali/Tundra. This tech also allows extending the API that's available
>> to the JS in the webview so that it can call VW viewer / network
>> operations too: for example qt's webview makes it easy to add your own
>> functions (say for moving camera or avatar, or creating a prim). I
>> tested that then too, made a html+js that had a button for creating a
>> new prim, and when that webpage was opened in a Naali webview, the
>> client side button worked to send a LLUDP message to Opensim and it
>> created a prim :) .. The HTML for that test is at
>> https://github.com/realXtend/tundra/blob/develop/bin/
>> pymodules/apitest/webui.html
>> and the viewer side code to create a custom webview with the API for
>> that in https://github.com/realXtend/tundra/blob/develop/bin/
>> pymodules/apitest/webui.py
>>
>> Is kind of wicked to be able to say
>> "connection.SendObjectAddPacket(127, 127, 25);" in html-js in an
>> opensim client :)
>>
>> Anyhow, great to hear about that effort and a practical sounding
>> beginning -- this for info just in case.
>>
>> ~Toni
>>
>>
>> On Fri, Nov 7, 2014 at 7:18 AM, Tom Willans <tom.willans at bessacarr.com>
>> wrote:
>>
>>> It also sounds like the basis for a separation of viewer and interface
>>> via a modular mechanism which would be great. One area opensim could work
>>> upon is having objects in world communicating the client interface and vice
>>> versa.  Would firstly a customisable communication protocol and module
>>> enabling two way communication between the virtual server, it's objects
>>> scripts and avatars themselves? This could be done whilst doing the work
>>> for this viewer whilst laying down an API and architecture usable in other
>>> modules.
>>>
>>> This would enable not only for the server and environment developers to
>>> modify the UI.but for objects, as defined by the inworld virtual world
>>> designers to become part of the interface. This would be a body into which
>>> all sorts of Haptics and sensory devices could be connected. There are
>>> concepts of Enactive interfaces that break away from the human -> interface
>>> -> server to that of being action focused. http://en.m.wikipedia.org/
>>> wiki/Enactive_interfaces
>>>
>>>   For instance if you are using a mobile phone, tablet, HMD or
>>> conventional laptop. It would also enable the client to let the server know
>>> what it's capabilities are?
>>>
>>> Would it be possible to override the server decisions? There is
>>> something about a familiar interface that makes it "transparent" to the
>>> user?   In this case the server environment and Haptics/sensory conduits eg
>>> viewer need to be harmonised. Accessibility with web browsers allow for
>>> user to override CSS defined colours with their own.
>>>
>>> A question I was intending to ask the developers is whether it is
>>> possible for objects to be marked as only visible to a specific user or
>>> group of users? or even only show this object. This would enable in-world
>>> interface objects to be created that are of no interest to those in world
>>> (similar to current 2D HUD objects) and would get in the way of the inworld
>>> experience or objects such as a house to be displayed but the surrounding
>>> blue screen onto which not virtual images could be projected ie augmented
>>> reality.
>>>
>>> Just some thoughts but sounds good.
>>> Tom
>>>
>>> Tom Willans  BSc(Hons)  MBCS  CITP
>>> PhD Student
>>> Serious Games Institute, Coventry University
>>> United Kingdom
>>>
>>> Managing Director Bessacarr Publications Ltd
>>> +44 (0)121 288 0281
>>> email: tom.willans at bessacarr.com
>>> skype: tom.willans
>>> Second Life and OSGrid: Tom Tiros
>>>
>>>
>>>
>>> Sent from my iPad
>>>
>>>  On 7 Nov 2014, at 00:52, Melanie <melanie at t-data.com> wrote:
>>>>
>>>> I'm in favor of this becoming core modules and the viewer mods
>>>> becoming a standard over time. It looks like what is needed to get
>>>> opensim beyond the social virtual world provision.
>>>>
>>>> Melanie
>>>>
>>>>  On 07/11/2014 01:49, Diva Canto wrote:
>>>>> Dear devs,
>>>>>
>>>>> I've been working with a Singularity developer in order to develop a
>>>>> Singularity-based viewer for OpenSim that can show different UI and
>>>>> user
>>>>> controls depending on data sent from the server side. It's a little bit
>>>>> like a Web browser: the browser is to be as generic as possible, the
>>>>> server sends the application, which changes from server to server.
>>>>> These
>>>>> viewers obviously aren't Web browsers, so there's only so much that we
>>>>> can do under this idea. But to the extent that it can be pushed to
>>>>> behave like a web browser, we're pushing it. This allows for opensim
>>>>> providers to offer different/simpler interfaces to their users without
>>>>> requiring a whole new viewer installation.
>>>>>
>>>>> The viewer is called OnLook, and the few changes we already made prove
>>>>> the concept. The code is here:
>>>>> https://github.com/diva/OnLook
>>>>>
>>>>> There are currently two independent options: (1) a special UI, where
>>>>> the
>>>>> server can send what buttons to show in the toolbar; and (2) a
>>>>> camera-only mode that tells the viewer not to render the person's
>>>>> avatar
>>>>> and to provide a camera control model that is more inline with what you
>>>>> have in 3d editors like Sketchup (warning: this second mode is going to
>>>>> make many of you barf! :) This is just the beginning, and much more can
>>>>> be done.
>>>>>
>>>>> In order for this viewer to behave any different than regular
>>>>> Singularity, the sim needs to be extended with modules for supporting
>>>>> these behaviors. In talking to Justin and others on the IRC, there
>>>>> seemed to be support for adding these modules to core opensim, under
>>>>> OpenSim.Region.OptionalModules -- there's already one there made by
>>>>> Melanie that also subscribes to this design philosophy.
>>>>>
>>>>> But before I push it, I wanted to let you know about it, and to make
>>>>> sure there are no issues in having this in core. I need a viewer whose
>>>>> UI and user controls can be programmed server side, that's why I made
>>>>> OnLook. Nothing in it is proprietary, but I also don't want to impose
>>>>> it
>>>>> in core.
>>>>>
>>>>> Cheers
>>>>> Diva
>>>>>
>>>>> _______________________________________________
>>>>> Opensim-dev mailing list
>>>>> Opensim-dev at opensimulator.org
>>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>>>
>>>> _______________________________________________
>>>> Opensim-dev mailing list
>>>> Opensim-dev at opensimulator.org
>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>>
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at opensimulator.org
>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at opensimulator.org
>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>
>>
>>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20141109/487e9f70/attachment.html>