<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Mister Blue and everyone,<br>
<br>
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.<br>
<br>
Let me explain what I have in mind in terms of a "challenge
scenario."<br>
<br>
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:<br>
- No one moves. Everyone is given fixed positions in the scene.<br>
- 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)<br>
- The observers are *not* represented by animated avatars. They
are represented by simple smiley faces or something like that.<br>
- The camera has only 3 or 4 possible positions, and there's a UI
for that.<br>
- There is chat, but anyone can hide it / show it.<br>
- 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.<br>
- The observers can "jump" to see other chess games that are being
played at the moment.<br>
- The chess game has 3D chess pieces. When a player moves a piece,
a short animation shows the movement a couple of times.<br>
... you get the idea...<br>
<br>
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.<br>
<br>
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:<br>
<br>
- How can we specify the environment's UI? HUDs maybe? Could HUDs
be reinterpreted as client-side 2D objects in a web viewer?<br>
<br>
- 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"<br>
<br>
- 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.<br>
<br>
- ...<br>
<br>
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?<br>
<br>
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.<br>
<br>
<br>
On 8/7/2014 7:38 AM, Mister Blue wrote:<br>
</div>
<blockquote
cite="mid:CAJ=JWqx9Vj=r4DprrzCX14X63U5r55SpCrJiNgucsQbTw4s6ow@mail.gmail.com"
type="cite">
<div dir="ltr">Good stuff.
<div><br>
</div>
<div>@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.</div>
<div><br>
</div>
<div>@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. </div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div><span
style="font-family:arial,sans-serif;font-size:13.333333969116211px">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,
...).</span><br>
</div>
<div><span
style="font-family:arial,sans-serif;font-size:13.333333969116211px"><br>
</span></div>
<div><span
style="font-family:arial,sans-serif;font-size:13.333333969116211px">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?</span></div>
<div><span
style="font-family:arial,sans-serif;font-size:13.333333969116211px"><br>
</span></div>
<div><span
style="font-family:arial,sans-serif;font-size:13.333333969116211px">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.</span></div>
<div><span
style="font-family:arial,sans-serif;font-size:13.333333969116211px"><br>
</span></div>
<div><span
style="font-family:arial,sans-serif;font-size:13.333333969116211px">A
first step would be a simple viewer that shows promise and
connects to existing grids. A baby step.</span></div>
<div><br>
</div>
<div class="gmail_extra">-- mb<br>
<br>
<div class="gmail_quote">On Thu, Aug 7, 2014 at 6:49 AM, Frank
Nichols <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:j.frank.nichols@gmail.com" target="_blank">j.frank.nichols@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
<div>"<span
style="font-family:arial,sans-serif;font-size:13px">make
it in a way it can better support functionality for
handicapt people."</span>
<div>
<span
style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div>
</div>
<div><span
style="font-family:arial,sans-serif;font-size:13px">Absolutely
- this will go a long way towards gaining
acceptance! </span></div>
</div>
<div>
<div>
<div class="gmail_extra">
<br>
<br>
<div class="gmail_quote">On Thu, Aug 7, 2014 at 7:16
AM, R.Gunther <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:rigun@rigutech.nl"
target="_blank">rigun@rigutech.nl</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px
0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Afree
with this, i think its just a bit to early for a
viewer.<br>
Its better if possible to adjust opensim to make
it High Fidelity compatible.<br>
And als use there viewer, or write one thats
based on high fidelity code.<br>
If you now write a viewer for opensim you
possible have to many bandages needed later to
adjust it for High Fidelity.<br>
High Fidelity can give a few parts that openmsim
is now missing.
<div><br>
<br>
On 2014-08-07 09:05, Ilan Tochner wrote:<br>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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.<br>
<br>
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.<br>
<br>
Cheers,<br>
<br>
Ilan Tochner<br>
Co-Founder and CEO<br>
Kitely Ltd.<br>
<br>
</blockquote>
<br>
</div>
<div>
<div>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:Opensim-dev@opensimulator.org"
target="_blank">Opensim-dev@opensimulator.org</a><br>
<a moz-do-not-send="true"
href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev"
target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:Opensim-dev@opensimulator.org"
target="_blank">Opensim-dev@opensimulator.org</a><br>
<a moz-do-not-send="true"
href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev"
target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Opensim-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a>
<a class="moz-txt-link-freetext" href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>