Hi Diva/all,
I'm happy to see some interest in this new viewer project. I have my own
viewer projects which I wish to continue focusing on but I'd like to offer
to share some notes on some of the approaches I'm using regarding network
stacks.
First: protocols. I'm using Websockets for scene updates and HTTP for asset
transfers. Websockets are message-oriented and provide a convenient means
of sending variable length messages between endpoints with little
additional support code needed. My primary reasoning for choosing
Websockets at this time is to support browser-based viewers. I've also
developed a custom UDP protocol but with the success I've had with
Websockets I've let that protocol succomb to some bit rot and it's probably
broken at this point. I've looked several times at WebRTC but it seems to
be primarily a peer-to-peer protocol and it's developers don't seem
interested in providing means for non-prowsers to act as peers. I've seen a
few attempts in the past to create server peer support libraries but I've
not (yet) found any I would consider worthy of building a production
protocol on top of. It's been nearly a year since I've researched this and
it's possible something has changed but for now Websockets seem to be
working quite well.
I'm using both a region module approach and a proxy approach. The region
module seems to have the better user experience in terms of movement and
action lag but the proxy approach allows me to connect to any grid,
including SL, and also teleport across the Hypergrid. Both approaches seem
to have merit and I tend to keep them in sync development-wise. The region
module makes heavy use of EventManager events and for any events I may need
which aren't currently available, the module will poll some data structures
in scene on a Heartbeat End event. This isn't the approach I'd like and it
would be better to have all events available but I thought I'd complete the
protocol before submitting any possible pull requests or patches to core.
Another issue with the region module approach is it doesn't work well with
grid services and managing grid presences. I remember Teravus made a few
commits long ago to enable some new login and presence creation methods but
I'm not sure they still exist. He also added some Websocket support to the
HTTP server library but I believe it's been removed or broken in recent
commits. I'm currently using the Fleck library for Websockets. I also have
an asset conversion and serving capability in my region module which serves
images, animations, meshes, terrain, and the like and this functionality is
mirrored in my proxy version. I haven't addressed inventory yet in either
version. I have some crude region crossing code in my region module but
it's a rather kludgy workaround and I'll likely remove it. This is another
area that needs to be worked out with grid services.
I know I've discussed these approaches in IRC in the past and if anyone is
interested I'm willing to share experiences, ideas, and notes. If I see
sufficient commonality between our projects I may be willing to collaborate
on some aspects of a network stack. I should also mention that Mic Bowman
did a lot of similar work with accessing Scene state over a network via a
custom region module and he might be able to provide some useful insights.
I wish all the best of luck with this project! I've had a lot of fun and
I've learned a lot trying to interface various game engines to
OpenSimulator in the past and while I lack experience with Unreal and
cannot reasonably predict anyone's success, I am confident that at minimum
it will be a valuable learning experience for all involved.
-Dahlia
On Sat, Dec 15, 2018 at 8:19 AM Diva Canto <d...@metaverseink.com> wrote:
Parts of my wish list can, of course, be done without a new viewer,
simply by evolving the current Linden-based viewers. The network stack
is an obvious one.
If the current viewer developers and more server-side developers want to
cooperate on a new network stack that is secure and goes through
firewalls, that's a big +1 from me, independent of any other more
ambitious projects that I'm personally more interested in.
The way OpenSim is architected, this can (and should) be done outside of
the core code, simply by developing region modules and/or plugins. Once
that stack is a bit more solid, if it works well, we'll certainly
consider bringing those modules to core. Stuff like that, if it works
well, would be very valuable! And really, it *must* be developed as
modules, without touching the core code of the OpenSim framework. That's
how I would do it myself, and that's how it can be accepted for
inclusion.
Here is a presentation I wrote a few years ago, as a means to explain
myself the architecture of OpenSim:
https://www.ics.uci.edu/~lopes/opensim/OpenSim-Sep-15.pdf
Please look starting at page 9 and, in particular, pages 17-19, where I
have pictures of how to write new client stacks.
I encourage everyone who wants to embark on this to bring the
conversations to opensim-dev. There's a lot of knowledge there about how
to do stuff like that in a way that preserves the architecture of
OpenSim.
The private conversations we have been having are about the more
ambitious vision, not about any particular part of OpenSim, which, at
this point, is sufficiently flexible to support all sorts of
evolutionary extensions. A new network stack is one of those.
+1 on that!
On 12/15/2018 6:09 AM, Mike Dickson wrote:
I'd be willing to look at a UDP replacement + continuing to move things
that should be out of the simulator to CAPS. I've been working on
cutting
over my OpenSim tree to LibreMetaverse to take advantage of the buffer
pools that were added w/Halcyon so it could be done there and ride along
side UDP until things were ready. The eventing model inside OpenSIm also
needs work to support this IMO, the current mechanism is far too fragile
and error prone.
This feels far more promising if there is working being contemplated
than focusing on the VR elements.
Cinder I'll drop you a note with a few more thoughts but I'd be willing
to work on this. Not in core of course since I'm not in it and therefore
not aware of other "conversations" taking place. Happy to help
nonetheless and I can fit something like this in with the rest of the
"fixing" I'm doing with OpenSim.
Mike
-----Original Message-----
From: opensim-dev-boun...@opensimulator.org <
opensim-dev-boun...@opensimulator.org> On Behalf Of Cinder Roxley
Sent: Saturday, December 15, 2018 8:08 AM
To: opensim-dev@opensimulator.org
Subject: Re: [Opensim-dev] Unreal viewer: summoning the coders
On December 15, 2018 at 6:33:13 AM, Ai Austin (ai.ai.aus...@gmail.com)
wrote:
f) Running an app launched via a browser is much more common now and we
already have that with secondlife:// and hop:// protocols - which NEARLY
work as expected and would not need much to fix them working everywhere.
For all intents and purposes, hop:// has been abandoned. While I admit,
it’s much friendlier looking than x-grid-info://, x-grid-info:// complies
with BCP 35 and the URL Living Standard.
Exceptions that still need a little fix are on the Firestorm JIRA (e.g.
grid change on teleport rather grid string for hops staying as home
grid).
That, to me, would be more worthwhile than starting a whole new viewer
track.
This is due to the way hypergrid works. When you teleport, you aren’t
leaving your grid, rather, the destination region is linked to your grid.
However, my solution to this in x-grid-info:// reference source was to
use the OpenSimExtras cap to grok a grid uri from the region the agent is
connected to. This works universally in OpenSim 0.8.x and onward besides
OSGrid where OpenSimExtras doesn’t contain Bluewall’s most recent
additions
to it.
As far as Unreal goes, I wouldn’t be caught in the royalty payments
mess
that all entails.
However, I would love to collaborate on a replacement for LLUDP if
anyone is interested in that. Something like FlatBuffer (and FlatBuffer
over WebRTC on mobile) would make for a good replacement. It would also
be
a step towards some of the silly limitations LLUDP has forced on
OpenSimulator, like the 254 entity limit on terse object updates.
_______________________________________________
Opensim-dev mailing list
Opensim-dev@opensimulator.org
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev@opensimulator.org
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev@opensimulator.org
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev@opensimulator.org
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
