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
<[email protected] <mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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
[email protected]
<mailto:[email protected]>
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected] <mailto:[email protected]>
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
