[Opensim-dev] thinking about a viewer

Diva Canto diva at metaverseink.com
Sun Aug 10 19:38:23 UTC 2014


Mister Blue and everyone,

I thought a bit more about this. There is an evolutionary path that 
might take us quite a long way, if we could make it happen: we could 
continue to use [a better version of] the LL viewers for authoring (aka 
building) but have a web based viewer for experiencing the final 
environments, including completely different UIs. The advantage of this 
would be to reuse the very simple authoring/building facilities of SL, 
which are SL's key contribution to the world of 3D. Prims are very 
simple, compared to building things in Blender. As others have 
mentioned, it would be a shame to loose that simplicity in the effort to 
produce the next gen viewer.

Let me explain what I have in mind in terms of a "challenge scenario."

Imagine I want to build a multi-user chess tournament environment. The 
environment has 2 players and any number of observers in an audience. 
Here is a rough spec:
- No one moves. Everyone is given fixed positions in the scene.
- The 2 players are represented by animated avatars that are sitting at 
a chess table. The players choose the avatars from a fixed set of 
options when they join. The avatars do their animated avatar thing, 
switching poses every so often. (Imagine in the future this being fed 
from a live feed of the actual person's body language)
- The observers are *not* represented by animated avatars. They are 
represented by simple smiley faces or something like that.
- The camera has only 3 or 4 possible positions, and there's a UI for that.
- There is chat, but anyone can hide it / show it.
- The UI is all related to the tournament and nothing else. There are 
menus/buttons for showing who else is playing at the moment, the 
leaderboard, what was the last move in the game, a 2D fast replay of the 
current game, etc.
- The observers can "jump" to see other chess games that are being 
played at the moment.
- The chess game has 3D chess pieces. When a player moves a piece, a 
short animation shows the movement a couple of times.
... you get the idea...

We all know how to build a chess tournament environment in OpenSim/SL, 
and bits of what we would build would be exactly the same.  Many other 
bits are different between these viewers, though. In particular, the 
representation and implementation of connected users would be completely 
different and the viewers for this environment would be highly 
constrained and have an environment-specific UI.

So here is the challenge: could we build the environment I describe 
above, to be experienced in the Web browser, using a better version of 
the LL viewer? Here are some of the components of this challenge:

- How can we specify the environment's UI? HUDs maybe? Could HUDs be 
reinterpreted as client-side 2D objects in a web viewer?

- None of these connected users are supposed to move or change status 
often, so we can completely omit the verbose AgentUpdates that many game 
clients (including the LL viewer) have, which are responsible for most 
of the server load. But other environments might have moving avatars. 
How can we, as environment designers, specify the many levels of 
interactivity / responsiveness of these environments? In this case, I 
would like to say to the web clients "hey, no agent updates whatsoever 
please"

- How can we specify the representation of the connected users? In the 
case of this chess game, there would be avatars that don't ever change 
as players, as well as simpler objects as audience that also don't 
change. They all could be simple objects, indistinguishable from all 
other scene objects.

  - ...

As I said, this is a challenge, a thought experiment. I think we all 
like some bits of the SL system (the ease of authoring being one of 
them), but hate some other bits (the "fixed" complex application being 
one of them). So could we keep building with the SL system but offer 
completely different views of what we build via another viewer? What 
would we need to add to the current viewers in order to support this 
model? Would this route be easier or more difficult than throwing away 
the LL viewer and build something else more or less from scratch, 
reusing bits and pieces of other systems?

I don't have the answers to these questions, but the thought has 
intrigued me for the past few days, so I thought I'd share.


On 8/7/2014 7:38 AM, Mister Blue wrote:
> Good stuff.
>
> @Gunther: I have toyed with building an OpenSim module that adds an 
> OpenSim region to the HiFi hierarchical object tree. Then I spent a 
> week trying to build the HiFi viewer to conclude that they are 
> creating a new integrated viewer in the same sort of form as the SL 
> viewer. While I like a lot of their grid and object system, I'm not 
> happy with the viewer.
>
> @Tochner: RealXtend contains a lot of good work and it is now wrapped 
> into the Fi-Ware European project which will provide it funding and 
> momentum. Like OpenSim, there are companies using RealXtend and, for 
> smaller worlds, it works pretty well.
>
> You are right that starting from scratch would be a long road. But, 
> since we are in the open-source world and many necessary parts are 
> available to build on.
>
> I've been thinking along the lines of building a browser based 
> renderer using asm.js for performance and borrowing rendering logic 
> from HiFi (they seem to have people who know about rendering arch) and 
> three.js (which has an efficient, generalized renderer) and Radegast. 
> RealXtend has developed a flexible WebSockets transport system 
> (protocol versioning and multi-channels, ...). Add to that a 'space 
> management' system like Sirikata's or the hierarchical tree of HiFi 
> but with a generalization for girds and different authentication 
> systems. I like Macaroons for bearer certificates or passing around 
> permissions. Avatar renderers would come from HiFi and Radegast 
> although I wonder if avatar rendering could be cut out of the LL 
> viewer as a separate LGPL'ed library. The interface to the backend 
> would be cloud-ish -- all REST interfaces that can use all the scaling 
> tech of modern web applications (notifications, CDNs, managed APIs, 
> versioning, ...).
>
> An eventual research project would be the storage and manipulation of 
> objects in spaces. I wonder if only 'digested' objects can be sent to 
> viewers? 'Digested' in the sense that they have been combined, 
> formatted, enhanced for viewing (added light maps or occlusion maps) 
> or merged to build views of that city in the distance. If intermediate 
> processors (between the client and the object stores) can make 'views' 
> for the client, what would they do? What is the 'map/reduce' operation 
> for 3d world objects? Now could procedural rendering fit into this?
>
> Anyway, that's a long way of saying that starting from scratch would 
> be hard. Not only in the amount of work but also in building both new 
> developer and user communities. As @Justin pointed out, I am being 
> very optimistic on the amount of work involved.
>
> A first step would be a simple viewer that shows promise and connects 
> to existing grids. A baby step.
>
> -- mb
>
> On Thu, Aug 7, 2014 at 6:49 AM, Frank Nichols 
> <j.frank.nichols at gmail.com <mailto:j.frank.nichols at gmail.com>> wrote:
>
>     "make it in a way it can better support functionality for
>     handicapt people."
>
>     Absolutely - this will go a long way towards gaining acceptance!
>
>
>     On Thu, Aug 7, 2014 at 7:16 AM, R.Gunther <rigun at rigutech.nl
>     <mailto:rigun at rigutech.nl>> wrote:
>
>         Afree with this, i think its just a bit to early for a viewer.
>         Its better if possible to adjust opensim to make it High
>         Fidelity compatible.
>         And als use there viewer, or write one thats based on high
>         fidelity code.
>         If you now write a viewer for opensim you possible have to
>         many bandages needed later to adjust it for High Fidelity.
>         High Fidelity can give a few parts that openmsim is now missing.
>
>
>         On 2014-08-07 09:05, Ilan Tochner wrote:
>
>             I highly recommend that we avoid trying to start a viewer
>             project from scratch. Doing so without a dedicated group
>             working full time for an extended period of time will
>             result in the viewer project's failure and the growing
>             irrelevance of the OpenSim project that will pend the
>             availability of this modern viewer.
>
>             I suggest we either adopt and extend the realXtend project
>             for our needs (with or without its server architecture) or
>             invest our collective R&D resources towards pushing High
>             Fidelity in the direction we want it to evolve to. These
>             liberally-licensed open source projects have already had
>             many developer-years worth of effort invested in them and
>             are actively developed by more people than are currently
>             contributing to the OpenSim codebase. It would be very
>             unwise IMO to spend years reimplementing the type of
>             viewer they already have working.
>
>             Cheers,
>
>             Ilan Tochner
>             Co-Founder and CEO
>             Kitely Ltd.
>
>
>         _______________________________________________
>         Opensim-dev mailing list
>         Opensim-dev at opensimulator.org
>         <mailto:Opensim-dev at opensimulator.org>
>         http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
>
>
>     _______________________________________________
>     Opensim-dev mailing list
>     Opensim-dev at opensimulator.org <mailto: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/20140810/ec7eb0b8/attachment.html>


More information about the Opensim-dev mailing list