Unreal viewer: summoning the coders

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Unreal viewer: summoning the coders

Diva Canto
Hi everyone,

In case you missed the announcement at OSCC, Melanie has placed her
Unreal-based opensim viewer in GitHub:
https://github.com/opensim/opensim-viewer

This is a very rough prototype, not a finished product by any stretch of
the imagination.

Some of us core devs have been talking for a while about developing a
viewer more or less from scratch. This code _may_ be a good start. If
there's anyone out here with the technical chops, the time, and the will
to contribute, let us know!

Cheers
Diva
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|

Re: Unreal viewer: summoning the coders

Tommy Anderberg
On Mon, 10 Dec 2018 13:48:29 -0800, Diva wrote:
> Some of us core devs have been talking for a while about developing a
> viewer more or less from scratch. This code _may_ be a good start. If
> there's anyone out here with the technical chops, the time, and the will
> to contribute, let us know!

Is there a list of goals for a new viewer?

I ask because I've seen the need for one suggested many times, usually
with two arguments:

1) Current viewers make OpenSim look bad; "my kids laugh at me because
the graphics look like they're from a 15-year old game". (I think this
was said at OSCC, too.)

2) OpenSim needs a web-based viewer; people these days just don't want
to download and install software the old-fashioned way, they just want
to open a browser window and go.

There is also a less commonly seen argument:

3) OpenSim needs a viewer which can be tailored to provide experiences
beyond an SL clone. Viewer developers focusing on SL are unlikely to
spend time on such features, so it's up to OpenSim developers to do it.
Hence https://github.com/diva/OnLook


Argument #1

...looks iffy to me. A new viewer will not automatically make OpenSim
look better. If it is to be compatible with existing worlds (and if not,
who will use it?), it will be displaying the same old assets, and shader
lipstick can only do so much for porcine content. (I believe somebody at
OSCC mentioned dynamic shadows. I scratched my head. We've had those in
OS/SL viewers for almost a decade?)

Existing viewers actually do some things really well; I have yet to see
any client for the growing crop of new VR worlds do what Windlight can
do (Hypatia's comes closest). That would all have to be recreated before
a new viewer can be called an improvement.

Is the idea to introduce new asset types tailored to UE's capabilities?
Then we're moving from argument #1 to argument #3. Existing worlds won't
benefit much in the short term, but they will still have to be supported
if there is to be any uptake at all of the new viewer. Meanwhile, users
of existing viewers will complain that some assets look broken or even
make them crash.


Argument #2

...usually gets shot down with something like "browsers can't do the
job" (that too was heard at OSCC). If we are talking about HTML5 and
Three.js, it might well be true. But have a look at Epic's Zen Garden
demo from March 2017. Is it really obvious that WebAssembly and WebGL 2
can't do the job either?

So, if you really believe that lack of a web-based viewer is keeping
OpenSim back, UE's support for WebAssembly might be a good reason to
consider going down this route. But then one should weigh the effort of
building a whole new viewer against the effort required to get the core
parts of an existing one to compile with Emscripten.

As an aside, I am less convinced now than a few years ago that a web
viewer would really make that much of a difference. It's not like
Fortnite has suffered greatly from the need to download and run a 10 GB
installer before you can start having fun (for some people's definition
of "fun").


Argument #3

... is the one I find most credible. But whether UE provides the best
route to an OpenSim-specific viewer depends on what exactly one is
trying to achieve.

Is better graphics an important criterion, to the point that it warrants
the introduction of UE-specific asset types unsupported by existing viewers?

Is VR support important? UE and Unity both make this very easy to add.

Is easy customization of the UI what really matters? An easily
customizable HTML5 UI around a WebAssembly-driven WebGL canvas could be
a worthy heir to OnLook, but this might be easier to achieve starting
from an existing viewer.


Maybe these questions have all been thrashed out already. If so, a link
to a document summarizing the answers would be welcome.
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|

Re: Unreal viewer: summoning the coders

Diva Canto
It's #3.

Here's my point of view(er). We need a viewer that:

1) Uses secure networking and is able to go through firewalls, so a
completely different network stack.

2) Accepts programmable UIs from the server and therefore is capable of
conveying completely different applications.

3) Uses modern graphics, so a completely different rendering engine.
Would be nice that it would be capable of being compiled for different
platforms such as mobile and game stations.

4) Last but not least, is capable of rendering OpenSim/SL content. We
all like the build tools of SL, they are the easiest 3D authoring tools
out there, and therefore we want to continue to support prims and the
horribly un-optimized content that people create. The current viewers
can support building very well, we should continue to use them for that.

Rendering on the Web browser is not a priority. These days it's pretty
easy and common to install and run native applications by clicking
links. Ppl are starting to get used to it with apps like Zoom,
BlueJeans, etc.

We've been having internal discussions about how to go at it, what
rendering engine(s) to use, etc. Personally, I hate the thought of
committing to one single technology, so a lot of the hesitation [on my
part] has been to figure out how to develop a viewer that doesn't commit
strongly to Unreal, Unity, ... but that could perhaps be made to work
with several rendering engines. Like what we did for Physics on the
server side. It's not easy, and may not even be possible. So starting
with one but keeping it at arms-length distance may be the way to go.

On 12/14/2018 3:07 PM, Tommy Anderberg wrote:

> On Mon, 10 Dec 2018 13:48:29 -0800, Diva wrote:
>> Some of us core devs have been talking for a while about developing a
>> viewer more or less from scratch. This code _may_ be a good start. If
>> there's anyone out here with the technical chops, the time, and the will
>> to contribute, let us know!
>
> Is there a list of goals for a new viewer?
>
> I ask because I've seen the need for one suggested many times, usually
> with two arguments:
>
> 1) Current viewers make OpenSim look bad; "my kids laugh at me because
> the graphics look like they're from a 15-year old game". (I think this
> was said at OSCC, too.)
>
> 2) OpenSim needs a web-based viewer; people these days just don't want
> to download and install software the old-fashioned way, they just want
> to open a browser window and go.
>
> There is also a less commonly seen argument:
>
> 3) OpenSim needs a viewer which can be tailored to provide experiences
> beyond an SL clone. Viewer developers focusing on SL are unlikely to
> spend time on such features, so it's up to OpenSim developers to do it.
> Hence https://github.com/diva/OnLook
>
>
> Argument #1
>
> ...looks iffy to me. A new viewer will not automatically make OpenSim
> look better. If it is to be compatible with existing worlds (and if not,
> who will use it?), it will be displaying the same old assets, and shader
> lipstick can only do so much for porcine content. (I believe somebody at
> OSCC mentioned dynamic shadows. I scratched my head. We've had those in
> OS/SL viewers for almost a decade?)
>
> Existing viewers actually do some things really well; I have yet to see
> any client for the growing crop of new VR worlds do what Windlight can
> do (Hypatia's comes closest). That would all have to be recreated before
> a new viewer can be called an improvement.
>
> Is the idea to introduce new asset types tailored to UE's capabilities?
> Then we're moving from argument #1 to argument #3. Existing worlds won't
> benefit much in the short term, but they will still have to be supported
> if there is to be any uptake at all of the new viewer. Meanwhile, users
> of existing viewers will complain that some assets look broken or even
> make them crash.
>
>
> Argument #2
>
> ...usually gets shot down with something like "browsers can't do the
> job" (that too was heard at OSCC). If we are talking about HTML5 and
> Three.js, it might well be true. But have a look at Epic's Zen Garden
> demo from March 2017. Is it really obvious that WebAssembly and WebGL 2
> can't do the job either?
>
> So, if you really believe that lack of a web-based viewer is keeping
> OpenSim back, UE's support for WebAssembly might be a good reason to
> consider going down this route. But then one should weigh the effort of
> building a whole new viewer against the effort required to get the core
> parts of an existing one to compile with Emscripten.
>
> As an aside, I am less convinced now than a few years ago that a web
> viewer would really make that much of a difference. It's not like
> Fortnite has suffered greatly from the need to download and run a 10 GB
> installer before you can start having fun (for some people's definition
> of "fun").
>
>
> Argument #3
>
> ... is the one I find most credible. But whether UE provides the best
> route to an OpenSim-specific viewer depends on what exactly one is
> trying to achieve.
>
> Is better graphics an important criterion, to the point that it warrants
> the introduction of UE-specific asset types unsupported by existing
> viewers?
>
> Is VR support important? UE and Unity both make this very easy to add.
>
> Is easy customization of the UI what really matters? An easily
> customizable HTML5 UI around a WebAssembly-driven WebGL canvas could be
> a worthy heir to OnLook, but this might be easier to achieve starting
> from an existing viewer.
>
>
> Maybe these questions have all been thrashed out already. If so, a link
> to a document summarizing the answers would be welcome.
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
>

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|

Re: Unreal viewer: summoning the coders

ssm2017
Hello
My hope for the viewers would be to have the ability to :
- use hmd
- have any functionnality made as plugins to enable or install from a
repository (you don't like the chat plugin ? You can install the one made
by someone else).
Thank you Melanie and all devs for giving us a new tool :)

On Sat, Dec 15, 2018, 01:08 Diva Canto <[hidden email] wrote:

> It's #3.
>
> Here's my point of view(er). We need a viewer that:
>
> 1) Uses secure networking and is able to go through firewalls, so a
> completely different network stack.
>
> 2) Accepts programmable UIs from the server and therefore is capable of
> conveying completely different applications.
>
> 3) Uses modern graphics, so a completely different rendering engine.
> Would be nice that it would be capable of being compiled for different
> platforms such as mobile and game stations.
>
> 4) Last but not least, is capable of rendering OpenSim/SL content. We
> all like the build tools of SL, they are the easiest 3D authoring tools
> out there, and therefore we want to continue to support prims and the
> horribly un-optimized content that people create. The current viewers
> can support building very well, we should continue to use them for that.
>
> Rendering on the Web browser is not a priority. These days it's pretty
> easy and common to install and run native applications by clicking
> links. Ppl are starting to get used to it with apps like Zoom,
> BlueJeans, etc.
>
> We've been having internal discussions about how to go at it, what
> rendering engine(s) to use, etc. Personally, I hate the thought of
> committing to one single technology, so a lot of the hesitation [on my
> part] has been to figure out how to develop a viewer that doesn't commit
> strongly to Unreal, Unity, ... but that could perhaps be made to work
> with several rendering engines. Like what we did for Physics on the
> server side. It's not easy, and may not even be possible. So starting
> with one but keeping it at arms-length distance may be the way to go.
>
> On 12/14/2018 3:07 PM, Tommy Anderberg wrote:
> > On Mon, 10 Dec 2018 13:48:29 -0800, Diva wrote:
> >> Some of us core devs have been talking for a while about developing a
> >> viewer more or less from scratch. This code _may_ be a good start. If
> >> there's anyone out here with the technical chops, the time, and the will
> >> to contribute, let us know!
> >
> > Is there a list of goals for a new viewer?
> >
> > I ask because I've seen the need for one suggested many times, usually
> > with two arguments:
> >
> > 1) Current viewers make OpenSim look bad; "my kids laugh at me because
> > the graphics look like they're from a 15-year old game". (I think this
> > was said at OSCC, too.)
> >
> > 2) OpenSim needs a web-based viewer; people these days just don't want
> > to download and install software the old-fashioned way, they just want
> > to open a browser window and go.
> >
> > There is also a less commonly seen argument:
> >
> > 3) OpenSim needs a viewer which can be tailored to provide experiences
> > beyond an SL clone. Viewer developers focusing on SL are unlikely to
> > spend time on such features, so it's up to OpenSim developers to do it.
> > Hence https://github.com/diva/OnLook
> >
> >
> > Argument #1
> >
> > ...looks iffy to me. A new viewer will not automatically make OpenSim
> > look better. If it is to be compatible with existing worlds (and if not,
> > who will use it?), it will be displaying the same old assets, and shader
> > lipstick can only do so much for porcine content. (I believe somebody at
> > OSCC mentioned dynamic shadows. I scratched my head. We've had those in
> > OS/SL viewers for almost a decade?)
> >
> > Existing viewers actually do some things really well; I have yet to see
> > any client for the growing crop of new VR worlds do what Windlight can
> > do (Hypatia's comes closest). That would all have to be recreated before
> > a new viewer can be called an improvement.
> >
> > Is the idea to introduce new asset types tailored to UE's capabilities?
> > Then we're moving from argument #1 to argument #3. Existing worlds won't
> > benefit much in the short term, but they will still have to be supported
> > if there is to be any uptake at all of the new viewer. Meanwhile, users
> > of existing viewers will complain that some assets look broken or even
> > make them crash.
> >
> >
> > Argument #2
> >
> > ...usually gets shot down with something like "browsers can't do the
> > job" (that too was heard at OSCC). If we are talking about HTML5 and
> > Three.js, it might well be true. But have a look at Epic's Zen Garden
> > demo from March 2017. Is it really obvious that WebAssembly and WebGL 2
> > can't do the job either?
> >
> > So, if you really believe that lack of a web-based viewer is keeping
> > OpenSim back, UE's support for WebAssembly might be a good reason to
> > consider going down this route. But then one should weigh the effort of
> > building a whole new viewer against the effort required to get the core
> > parts of an existing one to compile with Emscripten.
> >
> > As an aside, I am less convinced now than a few years ago that a web
> > viewer would really make that much of a difference. It's not like
> > Fortnite has suffered greatly from the need to download and run a 10 GB
> > installer before you can start having fun (for some people's definition
> > of "fun").
> >
> >
> > Argument #3
> >
> > ... is the one I find most credible. But whether UE provides the best
> > route to an OpenSim-specific viewer depends on what exactly one is
> > trying to achieve.
> >
> > Is better graphics an important criterion, to the point that it warrants
> > the introduction of UE-specific asset types unsupported by existing
> > viewers?
> >
> > Is VR support important? UE and Unity both make this very easy to add.
> >
> > Is easy customization of the UI what really matters? An easily
> > customizable HTML5 UI around a WebAssembly-driven WebGL canvas could be
> > a worthy heir to OnLook, but this might be easier to achieve starting
> > from an existing viewer.
> >
> >
> > Maybe these questions have all been thrashed out already. If so, a link
> > to a document summarizing the answers would be welcome.
> > _______________________________________________
> > Opensim-dev mailing list
> > [hidden email]
> > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> >
> >
>
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|

Re: Unreal viewer: summoning the coders

Ai Austin-2
In reply to this post by Diva Canto
For my input on this...

a) With a good graphics card and everything ramped up to Ultra with
shadows and all that on I think SL/OpenSim in a modern viewer
actually still can look very good.

b) Its good the current viewers can crank up and down view distances
and rendering options to help with frame rates where that is important.

c) Its a pity we lost David's CtrlAltStudio based on Firestorm buinow
an old version and things have moved on. It does still work for
Oculus Rift and anaglyph 3D though.

d) A lightweight client for tablet and modern smartphones would be nice.

e) Like Diva, I don't thing  browser based things are needed... WebGL
is truly limiting and for anything decent runs out of memory in
nearly every test I do (for example with Sinespace and my direct
Unity WebGL builds).

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. 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.

g) Things would look a lot more "next gen" if we have Unity style
terrain and water and procedurally generated trees,  flora, etc. But
I assume this is a server side (as well as viewer editor mode) thing.
See my blog post from 2014 on
http://blog.inf.ed.ac.uk/atate/2014/08/04/wishlist-for-next-gen-virtual-world/

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|

Re: Unreal viewer: summoning the coders

Cinder Roxley
In reply to this post by Diva Canto
On December 15, 2018 at 6:33:13 AM, Ai Austin ([hidden email])
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
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|

Re: Unreal viewer: summoning the coders

Mike Dickson
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: [hidden email] <[hidden email]> On Behalf Of Cinder Roxley
Sent: Saturday, December 15, 2018 8:08 AM
To: [hidden email]
Subject: Re: [Opensim-dev] Unreal viewer: summoning the coders

On December 15, 2018 at 6:33:13 AM, Ai Austin ([hidden email])
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
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|

Re: Unreal viewer: summoning the coders

Michel Beauregard
In reply to this post by Diva Canto
extract from DIVA email paragraph 4:

.....and the horribly un-optimized content that people create.

Mainly asset quality  problem that translated in lag and loading failure in our scenes.

A while back I was talking to the creator of the viewer building tool in SL who also happen to be the keeper of SVARGA a SL showcase region done with prim only .  At the time the viewer was defacto the  input filter tool for SL content.

Now a days with content creation external to viewer where would a content upload  filter tool best fit if not in the viewer. The cost of upload is a good indication of what burden is incurred in hosting said content and in SL that cost to some  extent  somehow regulate the content creation quality. SL also imposes upper limits on mesh object creation see next paragraph for details.  Could we use that data or other in our new viewer  to do some kind of control of asset upload quality in our opensim grids.

See for detail http://blog.nalates.net/2015/10/01/second-lifes-limits/#more-15460 where they indicate that not only there is a upper limit on material of 8 and total of triangle count per object of 174,752 for you mesh in SL , which was already documented . But they mention there is also a limit per material of 175,752/8 = 21,969 triangles .  Testing at the time with 0821 none of these limits were applicable to opensim.

GiMiSa

    Le vendredi 14 décembre 2018 19 h 08 min 38 s HNE, Diva Canto <[hidden email]> a écrit :  
 
 It's #3.

Here's my point of view(er). We need a viewer that:

1) Uses secure networking and is able to go through firewalls, so a
completely different network stack.

2) Accepts programmable UIs from the server and therefore is capable of
conveying completely different applications.

3) Uses modern graphics, so a completely different rendering engine.
Would be nice that it would be capable of being compiled for different
platforms such as mobile and game stations.

4) Last but not least, is capable of rendering OpenSim/SL content. We
all like the build tools of SL, they are the easiest 3D authoring tools
out there, and therefore we want to continue to support prims and the
horribly un-optimized content that people create. The current viewers
can support building very well, we should continue to use them for that.

Rendering on the Web browser is not a priority. These days it's pretty
easy and common to install and run native applications by clicking
links. Ppl are starting to get used to it with apps like Zoom,
BlueJeans, etc.

We've been having internal discussions about how to go at it, what
rendering engine(s) to use, etc. Personally, I hate the thought of
committing to one single technology, so a lot of the hesitation [on my
part] has been to figure out how to develop a viewer that doesn't commit
strongly to Unreal, Unity, ... but that could perhaps be made to work
with several rendering engines. Like what we did for Physics on the
server side. It's not easy, and may not even be possible. So starting
with one but keeping it at arms-length distance may be the way to go.


 
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|

Network stack [Re: Unreal viewer: summoning the coders]

Diva Canto
In reply to this post by Mike Dickson
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: [hidden email] <[hidden email]> On Behalf Of Cinder Roxley
> Sent: Saturday, December 15, 2018 8:08 AM
> To: [hidden email]
> Subject: Re: [Opensim-dev] Unreal viewer: summoning the coders
>
> On December 15, 2018 at 6:33:13 AM, Ai Austin ([hidden email])
> 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
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|

Re: Network stack [Re: Unreal viewer: summoning the coders]

Dahlia Trimble
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 <[hidden email]> 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: [hidden email] <
> [hidden email]> On Behalf Of Cinder Roxley
> > Sent: Saturday, December 15, 2018 8:08 AM
> > To: [hidden email]
> > Subject: Re: [Opensim-dev] Unreal viewer: summoning the coders
> >
> > On December 15, 2018 at 6:33:13 AM, Ai Austin ([hidden email])
> > 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
> > [hidden email]
> > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> >
> > _______________________________________________
> > Opensim-dev mailing list
> > [hidden email]
> > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> >
>
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|

Re: Network stack [Re: Unreal viewer: summoning the coders]

Mister Blue
I have also experimented with protocols. I am currently focusing on
gRPC/Protobuf/HTTP2[1] solutions.I built some code around FlatBuffers[2]
but I came to the conclusion that the 'control plain' part of VR protocols
does not use the no-copy feature of FlatBuffers (big things like meshes and
images go by HTTP or other protocols) and that the FlatBuffer data
structures leak into a lot of the app because of now the message data is
stored. The other advantage of Protobuf over Flatbuffer is the wider
language and implementation support.

Implementing a complete protocol in a region module requires identifying
all the correct events from the simulator core. A long term goal (mentioned
in Diva's presentation) is removing the LL protocol implementation from the
simulator core. I'm willing to do what I can to move protocols out of the
core and into modules.

== mb

[1]: https://grpc.io/
[2]: https://google.github.io/flatbuffers/

On Sat, Dec 15, 2018 at 5:23 PM Dahlia Trimble <[hidden email]>
wrote:

> 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 <[hidden email]> 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: [hidden email] <
> > [hidden email]> On Behalf Of Cinder Roxley
> > > Sent: Saturday, December 15, 2018 8:08 AM
> > > To: [hidden email]
> > > Subject: Re: [Opensim-dev] Unreal viewer: summoning the coders
> > >
> > > On December 15, 2018 at 6:33:13 AM, Ai Austin ([hidden email])
> > > 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
> > > [hidden email]
> > > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> > >
> > > _______________________________________________
> > > Opensim-dev mailing list
> > > [hidden email]
> > > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> > >
> >
> > _______________________________________________
> > Opensim-dev mailing list
> > [hidden email]
> > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> >
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|

Re: Network stack [Re: Unreal viewer: summoning the coders]

Diva Canto
Doing a new network stack suffers from a structural problem: it takes
two to tango -- the server and the client. The way our community has
been divided between OpenSim development and LL viewer development
doesn't encourage these kinds of things, unfortunately. That's why many
of the server-side devs tend to experiment with completely new clients
when wanting to experiment with different network stacks. Given how
complex the LL-based viewers are, it's just easier.

I still think it's worth evolving the LL viewer to use a new network
stack, because the LL protocol is an obstacle for corporations. Even if
we go and develop a new client altogether, the LL viewer isn't going
away, it's still amazing for many things, and OpenSim must (and will)
continue to support it. But redoing the network stack of the LL client
will require engagement from LL viewer developers. And knowing what I
know about it, it will likely require a fork that will be incompatible
with Second Life.

(This is unlike OpenSim, which is modular enough to be able to support
pretty much any client. And we will make it even more modular as new
clients require it, as Misterblue states.)

On 12/16/2018 9:02 AM, Mister Blue wrote:

> I have also experimented with protocols. I am currently focusing on
> gRPC/Protobuf/HTTP2[1] solutions.I built some code around FlatBuffers[2]
> but I came to the conclusion that the 'control plain' part of VR protocols
> does not use the no-copy feature of FlatBuffers (big things like meshes and
> images go by HTTP or other protocols) and that the FlatBuffer data
> structures leak into a lot of the app because of now the message data is
> stored. The other advantage of Protobuf over Flatbuffer is the wider
> language and implementation support.
>
> Implementing a complete protocol in a region module requires identifying
> all the correct events from the simulator core. A long term goal (mentioned
> in Diva's presentation) is removing the LL protocol implementation from the
> simulator core. I'm willing to do what I can to move protocols out of the
> core and into modules.
>
> == mb
>
> [1]: https://grpc.io/
> [2]: https://google.github.io/flatbuffers/
>
> On Sat, Dec 15, 2018 at 5:23 PM Dahlia Trimble <[hidden email]>
> wrote:
>
>> 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 <[hidden email]> 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: [hidden email] <
>>> [hidden email]> On Behalf Of Cinder Roxley
>>>> Sent: Saturday, December 15, 2018 8:08 AM
>>>> To: [hidden email]
>>>> Subject: Re: [Opensim-dev] Unreal viewer: summoning the coders
>>>>
>>>> On December 15, 2018 at 6:33:13 AM, Ai Austin ([hidden email])
>>>> 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
>>>> [hidden email]
>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>>
>>>> _______________________________________________
>>>> Opensim-dev mailing list
>>>> [hidden email]
>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>>
>>>
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> [hidden email]
>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>
>> _______________________________________________
>> Opensim-dev mailing list
>> [hidden email]
>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|

Re: Network stack [Re: Unreal viewer: summoning the coders]

Grid Master
I'm just going to throw in my 2 cents,

More modules ??  Really?!?!?!

Opensimulator already suffers in module hell where even certain "core"
features can be turned off by users ..

In my personal opinion if you are going to revamp it to get the most out of
it, then the "Module Hysteria" needs to go away.

Things that should NEVER be turned off, and core things like networking and
other comms should be rolled into the main system and not have to suffer
from "Loading Module" and the ability for someone to screw it up or disable
it.

just my .02

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Sun, Dec 16, 2018 at 1:05 PM Diva Canto <[hidden email]> wrote:

> Doing a new network stack suffers from a structural problem: it takes
> two to tango -- the server and the client. The way our community has
> been divided between OpenSim development and LL viewer development
> doesn't encourage these kinds of things, unfortunately. That's why many
> of the server-side devs tend to experiment with completely new clients
> when wanting to experiment with different network stacks. Given how
> complex the LL-based viewers are, it's just easier.
>
> I still think it's worth evolving the LL viewer to use a new network
> stack, because the LL protocol is an obstacle for corporations. Even if
> we go and develop a new client altogether, the LL viewer isn't going
> away, it's still amazing for many things, and OpenSim must (and will)
> continue to support it. But redoing the network stack of the LL client
> will require engagement from LL viewer developers. And knowing what I
> know about it, it will likely require a fork that will be incompatible
> with Second Life.
>
> (This is unlike OpenSim, which is modular enough to be able to support
> pretty much any client. And we will make it even more modular as new
> clients require it, as Misterblue states.)
>
> On 12/16/2018 9:02 AM, Mister Blue wrote:
> > I have also experimented with protocols. I am currently focusing on
> > gRPC/Protobuf/HTTP2[1] solutions.I built some code around FlatBuffers[2]
> > but I came to the conclusion that the 'control plain' part of VR
> protocols
> > does not use the no-copy feature of FlatBuffers (big things like meshes
> and
> > images go by HTTP or other protocols) and that the FlatBuffer data
> > structures leak into a lot of the app because of now the message data is
> > stored. The other advantage of Protobuf over Flatbuffer is the wider
> > language and implementation support.
> >
> > Implementing a complete protocol in a region module requires identifying
> > all the correct events from the simulator core. A long term goal
> (mentioned
> > in Diva's presentation) is removing the LL protocol implementation from
> the
> > simulator core. I'm willing to do what I can to move protocols out of the
> > core and into modules.
> >
> > == mb
> >
> > [1]: https://grpc.io/
> > [2]: https://google.github.io/flatbuffers/
> >
> > On Sat, Dec 15, 2018 at 5:23 PM Dahlia Trimble <[hidden email]>
> > wrote:
> >
> >> 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 <[hidden email]>
> 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: [hidden email] <
> >>> [hidden email]> On Behalf Of Cinder Roxley
> >>>> Sent: Saturday, December 15, 2018 8:08 AM
> >>>> To: [hidden email]
> >>>> Subject: Re: [Opensim-dev] Unreal viewer: summoning the coders
> >>>>
> >>>> On December 15, 2018 at 6:33:13 AM, Ai Austin ([hidden email]
> )
> >>>> 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
> >>>> [hidden email]
> >>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> >>>>
> >>>> _______________________________________________
> >>>> Opensim-dev mailing list
> >>>> [hidden email]
> >>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> >>>>
> >>>
> >>> _______________________________________________
> >>> Opensim-dev mailing list
> >>> [hidden email]
> >>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> >>>
> >> _______________________________________________
> >> Opensim-dev mailing list
> >> [hidden email]
> >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> >>
> > _______________________________________________
> > Opensim-dev mailing list
> > [hidden email]
> > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> >
>
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|

Re: Unreal viewer: summoning the coders

Rob Lindman
In reply to this post by Cinder Roxley
If people are working on these viewers, especially on matters of URI
handling... it would be nice if there was one (1) ONE with a decent
gridinfo configuration panel. (Preferences -> Opensim -> Made Of Fail)

When attempting to add a test grid... It is exceptionally annoying if
there is some difficulty in adding a new grid. You cannot manually edit
the individual line items for grids in order to adjust the different
pages. It frequently takes a while to fail if there is some difficulty
reaching the /gridinfo file. I wind up with redundant 'lost continent of
hippo' entries. I was trying to figure out what was going on testing on
127.0.0.1 (which for some reason fails 'despite our best efforts'.)

The /gridinfo URI itself is also ridiculous. Check for /gridinfo.xml or
something... I wanted 'mydomain.com' to be all a user had to put into
this panel in order for it to work, instead of mydomain.com:9000 ... And
so, hey, I am running apache, might as well just put a file up there
called /gridinfo, that way I can omit the port number while fulfilling
the /gridinfo requirements... While it was 'fun' to mess around with
mod-rewrite... this whole process shows that the OpenSim / TPV community
didn't put much thought into MAKING IT EASY for people to get on grids.

I ultimately had to open the Firestorm user grids xml file and add one
in manually to access the opensim running on my local system. That's
ridiculous. A typical end user is not going to want to go through that.
I am an opensim / second life enthusiast and this hassle was enough for
me to set the computer on fire. There is no easy way to debug what is
happening here.

If I had to go through all this trouble every time I wanted to connect
to A WEBSITE then I am sorry to say I would simply become Amish and
start milking goats.

A replacement for LLUDP isn't needed. What's needed is for people to
actually think about what they are doing. Try out the software under
different conditions and wonder if a person new to this environment
would REALLY want to contend with the seriously annoying issues that are
basically in the way of anyone adopting OpenSim.



On 2018-12-15 08:07, Cinder Roxley wrote:

> On December 15, 2018 at 6:33:13 AM, Ai Austin ([hidden email])
> 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
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev

---
Rob Lindman
Software Developer
https://roblindman.net/
316-361-6913
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|

Re: Unreal viewer: summoning the coders

Cinder Roxley
On December 20, 2018 at 8:32:52 AM, Rob Lindman ([hidden email]) wrote:

If people are working on these viewers, especially on matters of URI
handling... it would be nice if there was one (1) ONE with a decent
gridinfo configuration panel. (Preferences -> Opensim -> Made Of Fail)

When attempting to add a test grid... It is exceptionally annoying if
there is some difficulty in adding a new grid. You cannot manually edit
the individual line items for grids in order to adjust the different
pages.

These are constant parameters provided by the grid. They aren’t settings an
enduser should need to adjust.

It frequently takes a while to fail if there is some difficulty
reaching the /gridinfo file. I wind up with redundant 'lost continent of
hippo' entries. I was trying to figure out what was going on testing on
127.0.0.1 (which for some reason fails 'despite our best efforts'.)

This is how TCP is designed. You’ll get the same behavior from cURL. The
timeout is prolonged because there are people running grids on extremely
latent DSL connections and the timeout period needs to be that long to
connect. I have encountered regions connected to OSGrid that take nearly
two minutes to establish a connection to.

The /gridinfo URI itself is also ridiculous. Check for /gridinfo.xml or
something... I wanted 'mydomain.com' to be all a user had to put into
this panel in order for it to work, instead of mydomain.com:9000 ... And
so, hey, I am running apache, might as well just put a file up there
called /gridinfo, that way I can omit the port number while fulfilling
the /gridinfo requirements... While it was 'fun' to mess around with
mod-rewrite... this whole process shows that the OpenSim / TPV community
didn't put much thought into MAKING IT EASY for people to get on grids.

OpenSimulator hasn’t registered any port numbers in the Service Name and
Transport Protocol Port Number Registry. Since grid info is served via
http, it is standard to assume port 80. True, most grids host gridinfo on
8002 (already reserved for Teradata ORDBMS) or 9000 (reserved for
CSListener and php-fpm’s default port) but there’s nothing stating they are
the standard port.

I ultimately had to open the Firestorm user grids xml file and add one
in manually to access the opensim running on my local system. That's
ridiculous. A typical end user is not going to want to go through that.
I am an opensim / second life enthusiast and this hassle was enough for
me to set the computer on fire. There is no easy way to debug what is
happening here.

This is a DNS resolution issue with Firestorm. Nobody has ever bothered
reporting it to Firestorm, so they don’t even know it exists.

If I had to go through all this trouble every time I wanted to connect
to A WEBSITE then I am sorry to say I would simply become Amish and
start milking goats.

You’ll get a lot of the same issues trying to set apache+php up on
localhost and connecting via loopback if you have no experience or
documentation to help you.

A replacement for LLUDP isn't needed.

Disagree. LLUDP has many limitations which are mistakenly blamed as viewer
limitations. Not to mention, UDP being the chief reason firewalled clients
can’t connect. The protocol needs changed or at least DEFINED in order for
client and server to communicate.

What's needed is for people to
actually think about what they are doing. Try out the software under
different conditions and wonder if a person new to this environment
would REALLY want to contend with the seriously annoying issues that are
basically in the way of anyone adopting OpenSim.

As far as your example, that’s one of the reasons I created the
x-grid-info:// scheme (and why ArminW created hop:// though it’s
specification morphed) When x-grid-info:// is properly supported, one need
only to click a hyperlink in a web browser to add a grid to the viewer.
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|

Re: Unreal viewer: summoning the coders

Rob Lindman
I am well aware of how these things work, or in this case, fail
miserably. The interface is simply not intuitive. The implementation is
sloppy, frustrating, and half-assed. 6 out of 10 times when I want to
set up a new grid on a viewer there is some form of hassle involved,
whether it's on localhost or in the cloud.

Having to restart the viewer to reload the configuration when something
goes wrong here is a time loop from hell. I have a moderate to
considerable level of experience with technology, and this is idiotic.
No one that doesn't have a serious reason to will go to this level of
effort in order to browse 3d content.

And yes, sometimes you might want to modify an entry. In the case of
local loopback, with DHCP, I get a different IP address sometimes... So
I have to open a firestorm file, among other things, to modify the
entry. How about a reload button? Because once I put that URL in and try
to apply a new grid, if it doesn't go through cleanly, I am restarting
Firestorm. Sometimes I get the wonderful Not Responding. HOW GREAT THIS
IS. Ever accidentally put a trailing / on there? This aspect, which is
the FRONT DOOR to the entire 'metaverse', is an enormous fail.

Whoever came up with the gridinfo component simply didn't think. How
about an ICON or a THUMBNAIL of the grid you want to connect to, so
perhaps there would be a graphical way of looking at a directory of
grids?

No, we're going to put in a crummy text file with no file extension,
XMLRPC 'helpers' and no real detail about the grid, and "we're" going to
pretend that it's all done, nice and tidy, and move on to ruining
something else by ripping out the entire protocol? While you're at it,
let's restructure all of the INI files AGAIN so that migrating to the
new version is a complete hassle. A 10 year development cycle and this
product hasn't even reached a 1.0 version yet. QUIT IT.

The solution is to make the dialog intuitive, add some form of debug
component to track down issues, perhaps some knobs for timeouts -- and
not to reinvent the wheel of the protocols. Reinvent things once the
original things actually work.

If we are reinventing the wheel of protocols, it's time to set OpenSim
on fire, acknowledge it for the failure it is, and switch over to using
A-Frame, Three.JS, Node, and an entirely different stack. I have already
written one of those. So have others...

There are good reasons for leveraging the existing infrastructure.

Perhaps the methodology of OpenSim is never to finish, but simply to
fail, break everything, and start over again? If abandoning the current
infrastructure is on the road map, then please, let me know, because I
do not want to wait another decade for a basic working solution to what
I'm pretty sure is an attainable goal -- a working 'metaverse' built on
the existing infrastructure -- and I'll happily continue in my
estimation that OpenSim development is insane and will never fulfill
such a basic requirement. It would be a relief.

As for x-grid-info, I haven't seen anything with regard to this
implementation. If it's a proposal and it ultimately fixes the issues I
am bringing up here, bring it on. It could be a quasi-solution. However,
at the present time all I can see is that it is a ridiculous,
failure-prone hassle to add grids to the viewer, and a ridiculous,
failure prone hassle to set them up on the server, and from the
perspective of the end user, it's not going to be worth the frustration.
Even when I'm paid to deal with this sort of thing it's not worth it.

Anyway, I know this won't amount to anything. But seriously, I was here
on day one, a decade has gone by, and this is the FRONT DOOR, and it
does not work properly. And you want to redo the plumbing. No.


On 2018-12-20 10:28, Cinder Roxley wrote:

> On December 20, 2018 at 8:32:52 AM, Rob Lindman ([hidden email])
> wrote:
>
> If people are working on these viewers, especially on matters of URI
> handling... it would be nice if there was one (1) ONE with a decent
> gridinfo configuration panel. (Preferences -> Opensim -> Made Of Fail)
>
> When attempting to add a test grid... It is exceptionally annoying if
> there is some difficulty in adding a new grid. You cannot manually edit
> the individual line items for grids in order to adjust the different
> pages.
>
> These are constant parameters provided by the grid. They aren’t
> settings an
> enduser should need to adjust.
>
> It frequently takes a while to fail if there is some difficulty
> reaching the /gridinfo file. I wind up with redundant 'lost continent
> of
> hippo' entries. I was trying to figure out what was going on testing on
> 127.0.0.1 (which for some reason fails 'despite our best efforts'.)
>
> This is how TCP is designed. You’ll get the same behavior from cURL.
> The
> timeout is prolonged because there are people running grids on
> extremely
> latent DSL connections and the timeout period needs to be that long to
> connect. I have encountered regions connected to OSGrid that take
> nearly
> two minutes to establish a connection to.
>
> The /gridinfo URI itself is also ridiculous. Check for /gridinfo.xml or
> something... I wanted 'mydomain.com' to be all a user had to put into
> this panel in order for it to work, instead of mydomain.com:9000 ...
> And
> so, hey, I am running apache, might as well just put a file up there
> called /gridinfo, that way I can omit the port number while fulfilling
> the /gridinfo requirements... While it was 'fun' to mess around with
> mod-rewrite... this whole process shows that the OpenSim / TPV
> community
> didn't put much thought into MAKING IT EASY for people to get on grids.
>
> OpenSimulator hasn’t registered any port numbers in the Service Name
> and
> Transport Protocol Port Number Registry. Since grid info is served via
> http, it is standard to assume port 80. True, most grids host gridinfo
> on
> 8002 (already reserved for Teradata ORDBMS) or 9000 (reserved for
> CSListener and php-fpm’s default port) but there’s nothing stating they
> are
> the standard port.
>
> I ultimately had to open the Firestorm user grids xml file and add one
> in manually to access the opensim running on my local system. That's
> ridiculous. A typical end user is not going to want to go through that.
> I am an opensim / second life enthusiast and this hassle was enough for
> me to set the computer on fire. There is no easy way to debug what is
> happening here.
>
> This is a DNS resolution issue with Firestorm. Nobody has ever bothered
> reporting it to Firestorm, so they don’t even know it exists.
>
> If I had to go through all this trouble every time I wanted to connect
> to A WEBSITE then I am sorry to say I would simply become Amish and
> start milking goats.
>
> You’ll get a lot of the same issues trying to set apache+php up on
> localhost and connecting via loopback if you have no experience or
> documentation to help you.
>
> A replacement for LLUDP isn't needed.
>
> Disagree. LLUDP has many limitations which are mistakenly blamed as
> viewer
> limitations. Not to mention, UDP being the chief reason firewalled
> clients
> can’t connect. The protocol needs changed or at least DEFINED in order
> for
> client and server to communicate.
>
> What's needed is for people to
> actually think about what they are doing. Try out the software under
> different conditions and wonder if a person new to this environment
> would REALLY want to contend with the seriously annoying issues that
> are
> basically in the way of anyone adopting OpenSim.
>
> As far as your example, that’s one of the reasons I created the
> x-grid-info:// scheme (and why ArminW created hop:// though it’s
> specification morphed) When x-grid-info:// is properly supported, one
> need
> only to click a hyperlink in a web browser to add a grid to the viewer.
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev

---
Rob Lindman
Software Developer
https://roblindman.net/
316-361-6913
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|

Re: Unreal viewer: summoning the coders

Melanie-2
I believe you may well not be on the same page as the rest of us. We have no intention to change the Linden Labs based viewers. The viewer developers are a completely distinct team. The grid info dialog used to be different in the days of Hippo, it has since been slimmed down by the Firestorm team. We are the opensim developers, though, and we don't work on the LL based viewers. We are looking to implement a completely new viewer that of course will have a new protocol. the LL protocol has always been a stumbling block for the hypergrid as well as a number of other things. We would not want to base a new viewer on a broken protocol, that, on top of all else, doesn't traverse firewalls. If you have a beef with the way Firestorm is doing things, you will need to complain to them. We don't have any control over it. - Melanie ---- On Thu, 20 Dec 2018 16:36:21 +0000 Rob Lindman <[hidden email]> wrote ---- I am well aware of how these things work, or in this case, fail miserably. The interface is simply not intuitive. The implementation is sloppy, frustrating, and half-assed. 6 out of 10 times when I want to set up a new grid on a viewer there is some form of hassle involved, whether it's on localhost or in the cloud. Having to restart the viewer to reload the configuration when something goes wrong here is a time loop from hell. I have a moderate to considerable level of experience with technology, and this is idiotic. No one that doesn't have a serious reason to will go to this level of effort in order to browse 3d content. And yes, sometimes you might want to modify an entry. In the case of local loopback, with DHCP, I get a different IP address sometimes... So I have to open a firestorm file, among other things, to modify the entry. How about a reload button? Because once I put that URL in and try to apply a new grid, if it doesn't go through cleanly, I am restarting Firestorm. Sometimes I get the wonderful Not Responding. HOW GREAT THIS IS. Ever accidentally put a trailing / on there? This aspect, which is the FRONT DOOR to the entire 'metaverse', is an enormous fail. Whoever came up with the gridinfo component simply didn't think. How about an ICON or a THUMBNAIL of the grid you want to connect to, so perhaps there would be a graphical way of looking at a directory of grids? No, we're going to put in a crummy text file with no file extension, XMLRPC 'helpers' and no real detail about the grid, and "we're" going to pretend that it's all done, nice and tidy, and move on to ruining something else by ripping out the entire protocol? While you're at it, let's restructure all of the INI files AGAIN so that migrating to the new version is a complete hassle. A 10 year development cycle and this product hasn't even reached a 1.0 version yet. QUIT IT. The solution is to make the dialog intuitive, add some form of debug component to track down issues, perhaps some knobs for timeouts -- and not to reinvent the wheel of the protocols. Reinvent things once the original things actually work. If we are reinventing the wheel of protocols, it's time to set OpenSim on fire, acknowledge it for the failure it is, and switch over to using A-Frame, Three.JS, Node, and an entirely different stack. I have already written one of those. So have others... There are good reasons for leveraging the existing infrastructure. Perhaps the methodology of OpenSim is never to finish, but simply to fail, break everything, and start over again? If abandoning the current infrastructure is on the road map, then please, let me know, because I do not want to wait another decade for a basic working solution to what I'm pretty sure is an attainable goal -- a working 'metaverse' built on the existing infrastructure -- and I'll happily continue in my estimation that OpenSim development is insane and will never fulfill such a basic requirement. It would be a relief. As for x-grid-info, I haven't seen anything with regard to this implementation. If it's a proposal and it ultimately fixes the issues I am bringing up here, bring it on. It could be a quasi-solution. However, at the present time all I can see is that it is a ridiculous, failure-prone hassle to add grids to the viewer, and a ridiculous, failure prone hassle to set them up on the server, and from the perspective of the end user, it's not going to be worth the frustration. Even when I'm paid to deal with this sort of thing it's not worth it. Anyway, I know this won't amount to anything. But seriously, I was here on day one, a decade has gone by, and this is the FRONT DOOR, and it does not work properly. And you want to redo the plumbing. No. On 2018-12-20 10:28, Cinder Roxley wrote: > On December 20, 2018 at 8:32:52 AM, Rob Lindman ([hidden email]) > wrote: > > If people are working on these viewers, especially on matters of URI > handling... it would be nice if there was one (1) ONE with a decent > gridinfo configuration panel. (Preferences -> Opensim -> Made Of Fail) > > When attempting to add a test grid... It is exceptionally annoying if > there is some difficulty in adding a new grid. You cannot manually edit > the individual line items for grids in order to adjust the different > pages. > > These are constant parameters provided by the grid. They aren’t > settings an > enduser should need to adjust. > > It frequently takes a while to fail if there is some difficulty > reaching the /gridinfo file. I wind up with redundant 'lost continent > of > hippo' entries. I was trying to figure out what was going on testing on > 127.0.0.1 (which for some reason fails 'despite our best efforts'.) > > This is how TCP is designed. You’ll get the same behavior from cURL. > The > timeout is prolonged because there are people running grids on > extremely > latent DSL connections and the timeout period needs to be that long to > connect. I have encountered regions connected to OSGrid that take > nearly > two minutes to establish a connection to. > > The /gridinfo URI itself is also ridiculous. Check for /gridinfo.xml or > something... I wanted 'mydomain.com' to be all a user had to put into > this panel in order for it to work, instead of mydomain.com:9000 ... > And > so, hey, I am running apache, might as well just put a file up there > called /gridinfo, that way I can omit the port number while fulfilling > the /gridinfo requirements... While it was 'fun' to mess around with > mod-rewrite... this whole process shows that the OpenSim / TPV > community > didn't put much thought into MAKING IT EASY for people to get on grids. > > OpenSimulator hasn’t registered any port numbers in the Service Name > and > Transport Protocol Port Number Registry. Since grid info is served via > http, it is standard to assume port 80. True, most grids host gridinfo > on > 8002 (already reserved for Teradata ORDBMS) or 9000 (reserved for > CSListener and php-fpm’s default port) but there’s nothing stating they > are > the standard port. > > I ultimately had to open the Firestorm user grids xml file and add one > in manually to access the opensim running on my local system. That's > ridiculous. A typical end user is not going to want to go through that. > I am an opensim / second life enthusiast and this hassle was enough for > me to set the computer on fire. There is no easy way to debug what is > happening here. > > This is a DNS resolution issue with Firestorm. Nobody has ever bothered > reporting it to Firestorm, so they don’t even know it exists. > > If I had to go through all this trouble every time I wanted to connect > to A WEBSITE then I am sorry to say I would simply become Amish and > start milking goats. > > You’ll get a lot of the same issues trying to set apache+php up on > localhost and connecting via loopback if you have no experience or > documentation to help you. > > A replacement for LLUDP isn't needed. > > Disagree. LLUDP has many limitations which are mistakenly blamed as > viewer > limitations. Not to mention, UDP being the chief reason firewalled > clients > can’t connect. The protocol needs changed or at least DEFINED in order > for > client and server to communicate. > > What's needed is for people to > actually think about what they are doing. Try out the software under > different conditions and wonder if a person new to this environment > would REALLY want to contend with the seriously annoying issues that > are > basically in the way of anyone adopting OpenSim. > > As far as your example, that’s one of the reasons I created the > x-grid-info:// scheme (and why ArminW created hop:// though it’s > specification morphed) When x-grid-info:// is properly supported, one > need > only to click a hyperlink in a web browser to add a grid to the viewer. > _______________________________________________ > Opensim-dev mailing list > [hidden email] > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev --- Rob Lindman Software Developer https://roblindman.net/ 316-361-6913 _______________________________________________ Opensim-dev mailing list [hidden email] http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|

Re: Unreal viewer: summoning the coders

Rob Lindman
I am aware of who develops what.

Fixes need to be made to /gridinfo on BOTH sides.

/rant


On 2018-12-20 11:58, Melanie wrote:

> I believe you may well not be on the same page as the rest of us. We
> have no intention to change the Linden Labs based viewers. The viewer
> developers are a completely distinct team. The grid info dialog used
> to be different in the days of Hippo, it has since been slimmed down
> by the Firestorm team. We are the opensim developers, though, and we
> don't work on the LL based viewers. We are looking to implement a
> completely new viewer that of course will have a new protocol. the LL
> protocol has always been a stumbling block for the hypergrid as well
> as a number of other things. We would not want to base a new viewer on
> a broken protocol, that, on top of all else, doesn't traverse
> firewalls. If you have a beef with the way Firestorm is doing things,
> you will need to complain to them. We don't have any control over it.
> - Melanie ---- On Thu, 20 Dec 2018 16:36:21 +0000 Rob Lindman
> <[hidden email]> wrote ---- I am well aware of how these things
> work, or in this case, fail miserably. The interface is simply not
> intuitive. The implementation is sloppy, frustrating, and half-assed.
> 6 out of 10 times when I want to set up a new grid on a viewer there
> is some form of hassle involved, whether it's on localhost or in the
> cloud. Having to restart the viewer to reload the configuration when
> something goes wrong here is a time loop from hell. I have a moderate
> to considerable level of experience with technology, and this is
> idiotic. No one that doesn't have a serious reason to will go to this
> level of effort in order to browse 3d content. And yes, sometimes you
> might want to modify an entry. In the case of local loopback, with
> DHCP, I get a different IP address sometimes... So I have to open a
> firestorm file, among other things, to modify the entry. How about a
> reload button? Because once I put that URL in and try to apply a new
> grid, if it doesn't go through cleanly, I am restarting Firestorm.
> Sometimes I get the wonderful Not Responding. HOW GREAT THIS IS. Ever
> accidentally put a trailing / on there? This aspect, which is the
> FRONT DOOR to the entire 'metaverse', is an enormous fail. Whoever
> came up with the gridinfo component simply didn't think. How about an
> ICON or a THUMBNAIL of the grid you want to connect to, so perhaps
> there would be a graphical way of looking at a directory of grids? No,
> we're going to put in a crummy text file with no file extension,
> XMLRPC 'helpers' and no real detail about the grid, and "we're" going
> to pretend that it's all done, nice and tidy, and move on to ruining
> something else by ripping out the entire protocol? While you're at it,
> let's restructure all of the INI files AGAIN so that migrating to the
> new version is a complete hassle. A 10 year development cycle and this
> product hasn't even reached a 1.0 version yet. QUIT IT. The solution
> is to make the dialog intuitive, add some form of debug component to
> track down issues, perhaps some knobs for timeouts -- and not to
> reinvent the wheel of the protocols. Reinvent things once the original
> things actually work. If we are reinventing the wheel of protocols,
> it's time to set OpenSim on fire, acknowledge it for the failure it
> is, and switch over to using A-Frame, Three.JS, Node, and an entirely
> different stack. I have already written one of those. So have
> others... There are good reasons for leveraging the existing
> infrastructure. Perhaps the methodology of OpenSim is never to finish,
> but simply to fail, break everything, and start over again? If
> abandoning the current infrastructure is on the road map, then please,
> let me know, because I do not want to wait another decade for a basic
> working solution to what I'm pretty sure is an attainable goal -- a
> working 'metaverse' built on the existing infrastructure -- and I'll
> happily continue in my estimation that OpenSim development is insane
> and will never fulfill such a basic requirement. It would be a relief.
> As for x-grid-info, I haven't seen anything with regard to this
> implementation. If it's a proposal and it ultimately fixes the issues
> I am bringing up here, bring it on. It could be a quasi-solution.
> However, at the present time all I can see is that it is a ridiculous,
> failure-prone hassle to add grids to the viewer, and a ridiculous,
> failure prone hassle to set them up on the server, and from the
> perspective of the end user, it's not going to be worth the
> frustration. Even when I'm paid to deal with this sort of thing it's
> not worth it. Anyway, I know this won't amount to anything. But
> seriously, I was here on day one, a decade has gone by, and this is
> the FRONT DOOR, and it does not work properly. And you want to redo
> the plumbing. No. On 2018-12-20 10:28, Cinder Roxley wrote: > On
> December 20, 2018 at 8:32:52 AM, Rob Lindman ([hidden email]) >
> wrote: > > If people are working on these viewers, especially on
> matters of URI > handling... it would be nice if there was one (1) ONE
> with a decent > gridinfo configuration panel. (Preferences -> Opensim
> -> Made Of Fail) > > When attempting to add a test grid... It is
> exceptionally annoying if > there is some difficulty in adding a new
> grid. You cannot manually edit > the individual line items for grids
> in order to adjust the different > pages. > > These are constant
> parameters provided by the grid. They aren’t > settings an > enduser
> should need to adjust. > > It frequently takes a while to fail if
> there is some difficulty > reaching the /gridinfo file. I wind up with
> redundant 'lost continent > of > hippo' entries. I was trying to
> figure out what was going on testing on > 127.0.0.1 (which for some
> reason fails 'despite our best efforts'.) > > This is how TCP is
> designed. You’ll get the same behavior from cURL. > The > timeout is
> prolonged because there are people running grids on > extremely >
> latent DSL connections and the timeout period needs to be that long to
> > connect. I have encountered regions connected to OSGrid that take > nearly > two minutes to establish a connection to. > > The /gridinfo URI itself is also ridiculous. Check for /gridinfo.xml or > something... I wanted 'mydomain.com' to be all a user had to put into > this panel in order for it to work, instead of mydomain.com:9000 ... > And > so, hey, I am running apache, might as well just put a file up there > called /gridinfo, that way I can omit the port number while fulfilling > the /gridinfo requirements... While it was 'fun' to mess around with > mod-rewrite... this whole process shows that the OpenSim / TPV > community > didn't put much thought into MAKING IT EASY for people to get on grids. > > OpenSimulator hasn’t registered any port numbers in the Service Name > and > Transport Protocol Port Number Registry. Since grid info is served via > http, it is standard to assume port 80. True, most grids host gridinfo > on > 8002 (already reserved for Teradata ORDBMS
 ) or
9000 (reserved for > CSListener and php-fpm’s default port) but there’s nothing stating they > are > the standard port. > > I ultimately had to open the Firestorm user grids xml file and add one > in manually to access the opensim running on my local system. That's > ridiculous. A typical end user is not going to want to go through that. > I am an opensim / second life enthusiast and this hassle was enough for > me to set the computer on fire. There is no easy way to debug what is > happening here. > > This is a DNS resolution issue with Firestorm. Nobody has ever bothered > reporting it to Firestorm, so they don’t even know it exists. > > If I had to go through all this trouble every time I wanted to connect > to A WEBSITE then I am sorry to say I would simply become Amish and > start milking goats. > > You’ll get a lot of the same issues trying to set apache+php up on > localhost and connecting via loopback if you have no experience or > documentation to help you. >
  > A
replacement for LLUDP isn't needed. > > Disagree. LLUDP has many limitations which are mistakenly blamed as > viewer > limitations. Not to mention, UDP being the chief reason firewalled > clients > can’t connect. The protocol needs changed or at least DEFINED in order > for > client and server to communicate. > > What's needed is for people to > actually think about what they are doing. Try out the software under > different conditions and wonder if a person new to this environment > would REALLY want to contend with the seriously annoying issues that > are > basically in the way of anyone adopting OpenSim. > > As far as your example, that’s one of the reasons I created the > x-grid-info:// scheme (and why ArminW created hop:// though it’s > specification morphed) When x-grid-info:// is properly supported, one > need > only to click a hyperlink in a web browser to add a grid to the viewer. > _______________________________________________ > Opensim-dev mailing list >
[hidden email] > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev --- Rob Lindman Software Developer https://roblindman.net/ 316-361-6913 _______________________________________________ Opensim-dev mailing list [hidden email] http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev

---
Rob Lindman
Software Developer
https://roblindman.net/
316-361-6913
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|

Re: Unreal viewer: summoning the coders

Rob Lindman
In reply to this post by Melanie-2
I am somewhat confused by the representation that the LL protocol
doesn't work with firewalls... It would appear that LL has worked around
this issue:

https://community.secondlife.com/knowledgebase/english/using-second-life-with-a-firewall-r599/

What aspects of the protocol do not work within the firewall context?



On 2018-12-20 11:58, Melanie wrote:

> I believe you may well not be on the same page as the rest of us. We
> have no intention to change the Linden Labs based viewers. The viewer
> developers are a completely distinct team. The grid info dialog used
> to be different in the days of Hippo, it has since been slimmed down
> by the Firestorm team. We are the opensim developers, though, and we
> don't work on the LL based viewers. We are looking to implement a
> completely new viewer that of course will have a new protocol. the LL
> protocol has always been a stumbling block for the hypergrid as well
> as a number of other things. We would not want to base a new viewer on
> a broken protocol, that, on top of all else, doesn't traverse
> firewalls. If you have a beef with the way Firestorm is doing things,
> you will need to complain to them. We don't have any control over it.
> - Melanie ---- On Thu, 20 Dec 2018 16:36:21 +0000 Rob Lindman
> <[hidden email]> wrote ---- I am well aware of how these things
> work, or in this case, fail miserably. The interface is simply not
> intuitive. The implementation is sloppy, frustrating, and half-assed.
> 6 out of 10 times when I want to set up a new grid on a viewer there
> is some form of hassle involved, whether it's on localhost or in the
> cloud. Having to restart the viewer to reload the configuration when
> something goes wrong here is a time loop from hell. I have a moderate
> to considerable level of experience with technology, and this is
> idiotic. No one that doesn't have a serious reason to will go to this
> level of effort in order to browse 3d content. And yes, sometimes you
> might want to modify an entry. In the case of local loopback, with
> DHCP, I get a different IP address sometimes... So I have to open a
> firestorm file, among other things, to modify the entry. How about a
> reload button? Because once I put that URL in and try to apply a new
> grid, if it doesn't go through cleanly, I am restarting Firestorm.
> Sometimes I get the wonderful Not Responding. HOW GREAT THIS IS. Ever
> accidentally put a trailing / on there? This aspect, which is the
> FRONT DOOR to the entire 'metaverse', is an enormous fail. Whoever
> came up with the gridinfo component simply didn't think. How about an
> ICON or a THUMBNAIL of the grid you want to connect to, so perhaps
> there would be a graphical way of looking at a directory of grids? No,
> we're going to put in a crummy text file with no file extension,
> XMLRPC 'helpers' and no real detail about the grid, and "we're" going
> to pretend that it's all done, nice and tidy, and move on to ruining
> something else by ripping out the entire protocol? While you're at it,
> let's restructure all of the INI files AGAIN so that migrating to the
> new version is a complete hassle. A 10 year development cycle and this
> product hasn't even reached a 1.0 version yet. QUIT IT. The solution
> is to make the dialog intuitive, add some form of debug component to
> track down issues, perhaps some knobs for timeouts -- and not to
> reinvent the wheel of the protocols. Reinvent things once the original
> things actually work. If we are reinventing the wheel of protocols,
> it's time to set OpenSim on fire, acknowledge it for the failure it
> is, and switch over to using A-Frame, Three.JS, Node, and an entirely
> different stack. I have already written one of those. So have
> others... There are good reasons for leveraging the existing
> infrastructure. Perhaps the methodology of OpenSim is never to finish,
> but simply to fail, break everything, and start over again? If
> abandoning the current infrastructure is on the road map, then please,
> let me know, because I do not want to wait another decade for a basic
> working solution to what I'm pretty sure is an attainable goal -- a
> working 'metaverse' built on the existing infrastructure -- and I'll
> happily continue in my estimation that OpenSim development is insane
> and will never fulfill such a basic requirement. It would be a relief.
> As for x-grid-info, I haven't seen anything with regard to this
> implementation. If it's a proposal and it ultimately fixes the issues
> I am bringing up here, bring it on. It could be a quasi-solution.
> However, at the present time all I can see is that it is a ridiculous,
> failure-prone hassle to add grids to the viewer, and a ridiculous,
> failure prone hassle to set them up on the server, and from the
> perspective of the end user, it's not going to be worth the
> frustration. Even when I'm paid to deal with this sort of thing it's
> not worth it. Anyway, I know this won't amount to anything. But
> seriously, I was here on day one, a decade has gone by, and this is
> the FRONT DOOR, and it does not work properly. And you want to redo
> the plumbing. No. On 2018-12-20 10:28, Cinder Roxley wrote: > On
> December 20, 2018 at 8:32:52 AM, Rob Lindman ([hidden email]) >
> wrote: > > If people are working on these viewers, especially on
> matters of URI > handling... it would be nice if there was one (1) ONE
> with a decent > gridinfo configuration panel. (Preferences -> Opensim
> -> Made Of Fail) > > When attempting to add a test grid... It is
> exceptionally annoying if > there is some difficulty in adding a new
> grid. You cannot manually edit > the individual line items for grids
> in order to adjust the different > pages. > > These are constant
> parameters provided by the grid. They aren’t > settings an > enduser
> should need to adjust. > > It frequently takes a while to fail if
> there is some difficulty > reaching the /gridinfo file. I wind up with
> redundant 'lost continent > of > hippo' entries. I was trying to
> figure out what was going on testing on > 127.0.0.1 (which for some
> reason fails 'despite our best efforts'.) > > This is how TCP is
> designed. You’ll get the same behavior from cURL. > The > timeout is
> prolonged because there are people running grids on > extremely >
> latent DSL connections and the timeout period needs to be that long to
> > connect. I have encountered regions connected to OSGrid that take > nearly > two minutes to establish a connection to. > > The /gridinfo URI itself is also ridiculous. Check for /gridinfo.xml or > something... I wanted 'mydomain.com' to be all a user had to put into > this panel in order for it to work, instead of mydomain.com:9000 ... > And > so, hey, I am running apache, might as well just put a file up there > called /gridinfo, that way I can omit the port number while fulfilling > the /gridinfo requirements... While it was 'fun' to mess around with > mod-rewrite... this whole process shows that the OpenSim / TPV > community > didn't put much thought into MAKING IT EASY for people to get on grids. > > OpenSimulator hasn’t registered any port numbers in the Service Name > and > Transport Protocol Port Number Registry. Since grid info is served via > http, it is standard to assume port 80. True, most grids host gridinfo > on > 8002 (already reserved for Teradata ORDBMS
 ) or
9000 (reserved for > CSListener and php-fpm’s default port) but there’s nothing stating they > are > the standard port. > > I ultimately had to open the Firestorm user grids xml file and add one > in manually to access the opensim running on my local system. That's > ridiculous. A typical end user is not going to want to go through that. > I am an opensim / second life enthusiast and this hassle was enough for > me to set the computer on fire. There is no easy way to debug what is > happening here. > > This is a DNS resolution issue with Firestorm. Nobody has ever bothered > reporting it to Firestorm, so they don’t even know it exists. > > If I had to go through all this trouble every time I wanted to connect > to A WEBSITE then I am sorry to say I would simply become Amish and > start milking goats. > > You’ll get a lot of the same issues trying to set apache+php up on > localhost and connecting via loopback if you have no experience or > documentation to help you. >
  > A
replacement for LLUDP isn't needed. > > Disagree. LLUDP has many limitations which are mistakenly blamed as > viewer > limitations. Not to mention, UDP being the chief reason firewalled > clients > can’t connect. The protocol needs changed or at least DEFINED in order > for > client and server to communicate. > > What's needed is for people to > actually think about what they are doing. Try out the software under > different conditions and wonder if a person new to this environment > would REALLY want to contend with the seriously annoying issues that > are > basically in the way of anyone adopting OpenSim. > > As far as your example, that’s one of the reasons I created the > x-grid-info:// scheme (and why ArminW created hop:// though it’s > specification morphed) When x-grid-info:// is properly supported, one > need > only to click a hyperlink in a web browser to add a grid to the viewer. > _______________________________________________ > Opensim-dev mailing list >
[hidden email] > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev --- Rob Lindman Software Developer https://roblindman.net/ 316-361-6913 _______________________________________________ Opensim-dev mailing list [hidden email] http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev

---
Rob Lindman
Software Developer
https://roblindman.net/
316-361-6913
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|

Re: Unreal viewer: summoning the coders

Melanie-2
Please use reply, not reply all. I get two copies of the mail if you use reply all. Corporate firewalls generally allow absolutely no UDP traffic. Using the LL protocol in corporate or educational setups means opening up UDP, which they are unwilling to do because they see it as synonymous with allowing illegal file sharing. Go figure. These helper programs in gridinfo are mandated by the way LL set up the protocol, we wouldn't have them if we didn't have to. I don't see what you consider wrong with grid info on the server, unless you are complaining about the name of the link. In that case, you need to try to find the author of the Hippo viewer, because that is the person who invented that. - Melanie ---- On Thu, 20 Dec 2018 17:25:53 +0000 Rob Lindman <[hidden email]> wrote ---- I am somewhat confused by the representation that the LL protocol doesn't work with firewalls... It would appear that LL has worked around this issue: https://community.secondlife.com/knowledgebase/english/using-second-life-with-a-firewall-r599/ What aspects of the protocol do not work within the firewall context? On 2018-12-20 11:58, Melanie wrote: > I believe you may well not be on the same page as the rest of us. We > have no intention to change the Linden Labs based viewers. The viewer > developers are a completely distinct team. The grid info dialog used > to be different in the days of Hippo, it has since been slimmed down > by the Firestorm team. We are the opensim developers, though, and we > don't work on the LL based viewers. We are looking to implement a > completely new viewer that of course will have a new protocol. the LL > protocol has always been a stumbling block for the hypergrid as well > as a number of other things. We would not want to base a new viewer on > a broken protocol, that, on top of all else, doesn't traverse > firewalls. If you have a beef with the way Firestorm is doing things, > you will need to complain to them. We don't have any control over it. > - Melanie ---- On Thu, 20 Dec 2018 16:36:21 +0000 Rob Lindman > <[hidden email]> wrote ---- I am well aware of how these things > work, or in this case, fail miserably. The interface is simply not > intuitive. The implementation is sloppy, frustrating, and half-assed. > 6 out of 10 times when I want to set up a new grid on a viewer there > is some form of hassle involved, whether it's on localhost or in the > cloud. Having to restart the viewer to reload the configuration when > something goes wrong here is a time loop from hell. I have a moderate > to considerable level of experience with technology, and this is > idiotic. No one that doesn't have a serious reason to will go to this > level of effort in order to browse 3d content. And yes, sometimes you > might want to modify an entry. In the case of local loopback, with > DHCP, I get a different IP address sometimes... So I have to open a > firestorm file, among other things, to modify the entry. How about a > reload button? Because once I put that URL in and try to apply a new > grid, if it doesn't go through cleanly, I am restarting Firestorm. > Sometimes I get the wonderful Not Responding. HOW GREAT THIS IS. Ever > accidentally put a trailing / on there? This aspect, which is the > FRONT DOOR to the entire 'metaverse', is an enormous fail. Whoever > came up with the gridinfo component simply didn't think. How about an > ICON or a THUMBNAIL of the grid you want to connect to, so perhaps > there would be a graphical way of looking at a directory of grids? No, > we're going to put in a crummy text file with no file extension, > XMLRPC 'helpers' and no real detail about the grid, and "we're" going > to pretend that it's all done, nice and tidy, and move on to ruining > something else by ripping out the entire protocol? While you're at it, > let's restructure all of the INI files AGAIN so that migrating to the > new version is a complete hassle. A 10 year development cycle and this > product hasn't even reached a 1.0 version yet. QUIT IT. The solution > is to make the dialog intuitive, add some form of debug component to > track down issues, perhaps some knobs for timeouts -- and not to > reinvent the wheel of the protocols. Reinvent things once the original > things actually work. If we are reinventing the wheel of protocols, > it's time to set OpenSim on fire, acknowledge it for the failure it > is, and switch over to using A-Frame, Three.JS, Node, and an entirely > different stack. I have already written one of those. So have > others... There are good reasons for leveraging the existing > infrastructure. Perhaps the methodology of OpenSim is never to finish, > but simply to fail, break everything, and start over again? If > abandoning the current infrastructure is on the road map, then please, > let me know, because I do not want to wait another decade for a basic > working solution to what I'm pretty sure is an attainable goal -- a > working 'metaverse' built on the existing infrastructure -- and I'll > happily continue in my estimation that OpenSim development is insane > and will never fulfill such a basic requirement. It would be a relief. > As for x-grid-info, I haven't seen anything with regard to this > implementation. If it's a proposal and it ultimately fixes the issues > I am bringing up here, bring it on. It could be a quasi-solution. > However, at the present time all I can see is that it is a ridiculous, > failure-prone hassle to add grids to the viewer, and a ridiculous, > failure prone hassle to set them up on the server, and from the > perspective of the end user, it's not going to be worth the > frustration. Even when I'm paid to deal with this sort of thing it's > not worth it. Anyway, I know this won't amount to anything. But > seriously, I was here on day one, a decade has gone by, and this is > the FRONT DOOR, and it does not work properly. And you want to redo > the plumbing. No. On 2018-12-20 10:28, Cinder Roxley wrote: > On > December 20, 2018 at 8:32:52 AM, Rob Lindman ([hidden email]) > > wrote: > > If people are working on these viewers, especially on > matters of URI > handling... it would be nice if there was one (1) ONE > with a decent > gridinfo configuration panel. (Preferences -> Opensim > -> Made Of Fail) > > When attempting to add a test grid... It is > exceptionally annoying if > there is some difficulty in adding a new > grid. You cannot manually edit > the individual line items for grids > in order to adjust the different > pages. > > These are constant > parameters provided by the grid. They aren’t > settings an > enduser > should need to adjust. > > It frequently takes a while to fail if > there is some difficulty > reaching the /gridinfo file. I wind up with > redundant 'lost continent > of > hippo' entries. I was trying to > figure out what was going on testing on > 127.0.0.1 (which for some > reason fails 'despite our best efforts'.) > > This is how TCP is > designed. You’ll get the same behavior from cURL. > The > timeout is > prolonged because there are people running grids on > extremely > > latent DSL connections and the timeout period needs to be that long to > > connect. I have encountered regions connected to OSGrid that take > nearly > two minutes to establish a connection to. > > The /gridinfo URI itself is also ridiculous. Check for /gridinfo.xml or > something... I wanted 'mydomain.com' to be all a user had to put into > this panel in order for it to work, instead of mydomain.com:9000 ... > And > so, hey, I am running apache, might as well just put a file up there > called /gridinfo, that way I can omit the port number while fulfilling > the /gridinfo requirements... While it was 'fun' to mess around with > mod-rewrite... this whole process shows that the OpenSim / TPV > community > didn't put much thought into MAKING IT EASY for people to get on grids. > > OpenSimulator hasn’t registered any port numbers in the Service Name > and > Transport Protocol Port Number Registry. Since grid info is served via > http, it is standard to assume port 80. True, most grids host gridinfo > on > 8002 (already reserved for Teradata ORDBMS ) or 9000 (reserved for > CSListener and php-fpm’s default port) but there’s nothing stating they > are > the standard port. > > I ultimately had to open the Firestorm user grids xml file and add one > in manually to access the opensim running on my local system. That's > ridiculous. A typical end user is not going to want to go through that. > I am an opensim / second life enthusiast and this hassle was enough for > me to set the computer on fire. There is no easy way to debug what is > happening here. > > This is a DNS resolution issue with Firestorm. Nobody has ever bothered > reporting it to Firestorm, so they don’t even know it exists. > > If I had to go through all this trouble every time I wanted to connect > to A WEBSITE then I am sorry to say I would simply become Amish and > start milking goats. > > You’ll get a lot of the same issues trying to set apache+php up on > localhost and connecting via loopback if you have no experience or > documentation to help you. > > A replacement for LLUDP isn't needed. > > Disagree. LLUDP has many limitations which are mistakenly blamed as > viewer > limitations. Not to mention, UDP being the chief reason firewalled > clients > can’t connect. The protocol needs changed or at least DEFINED in order > for > client and server to communicate. > > What's needed is for people to > actually think about what they are doing. Try out the software under > different conditions and wonder if a person new to this environment > would REALLY want to contend with the seriously annoying issues that > are > basically in the way of anyone adopting OpenSim. > > As far as your example, that’s one of the reasons I created the > x-grid-info:// scheme (and why ArminW created hop:// though it’s > specification morphed) When x-grid-info:// is properly supported, one > need > only to click a hyperlink in a web browser to add a grid to the viewer. > _______________________________________________ > Opensim-dev mailing list > [hidden email] > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev --- Rob Lindman Software Developer https://roblindman.net/ 316-361-6913 _______________________________________________ Opensim-dev mailing list [hidden email] http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > [hidden email] > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev --- Rob Lindman Software Developer https://roblindman.net/ 316-361-6913 _______________________________________________ Opensim-dev mailing list [hidden email] http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
12